[Cialug] postfix issue

[david l goodrich]

On Fri, Nov 17, 2006 at 12:34:15PM -0600, Jeff Davis wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> david l goodrich wrote:
> >> the mail server has a whopping 200 MB ram, it's a xen domu at
> >> panix.com.  it is entirely unsuited to running postfix,
> >> cyrus-imapd AND amavisd-new.
> You said this was running on a box in another state through a VPN.
> It just piqued my curiosity.
> (Is your concern over the size because of bandwidth issues?)

well, i'm not really /concerned/ about bandwidth, but the pipe
speed vs. mail size has been observed to cause problems.
example, someone sent 1.7M worth of pictures to one of my users.

the sending server would send DATA, and spit the 1.7M at the mail
server, which would then open a connection to the anti-spam
server, send 1.7M.  the anti-spam server would recieve this
message, automatically pass it since it's over amavisd-new's 64k
threshhold, and send 1.7M /back/ to the mail server.  ONLY after
that would the mail server send a 2xx back to the sending server.

Except since we've just tried to push 3.4M of data along the VPN,
postfix got impatient and sent a 4xx defer back to the sending
server. 

The mail's still in postfix's queue, though, so it delivers it.

The sending server got a 4xx, so it tries again.

rinse and repeat.  there were ten copies of the email in their
inbox before i figured out what happened.


> 
> 
> >> defer_if_permit is nice, but remember, the mail server has
> >> already returned 2xx to the client.  i implemented this, but i
> >> just send 'ok' if the amavisd-new server is down.  there's not
> >> much else i can do at that point.
> I'm not sure how you're going to get around that
> 2xx except by not accepting the message.
> 
> Postfix can reject based on file size, but that
> doesn't seem to be your goal.  You're accepting
> an email and *then* based on size, determining if
> it gets scanned by amavis.

right, that's the opposite of my goal.  i'm making the same
assumption amavisd-new makes - messages over 64k just aren't
spam.

> 
> >> thanks, i didn't know about that one.
> >> that may be the better route, actually, to knock the time down to
> >> 60 or something, and disregard the size checks.  if it's too big
> >> it'll trip the timeout.  if it's set up as an smtpd_proxy_filter
> >> instead of  via smtpd_end_of_data_restrictions it'll check to see
> >> if the anti-spam server is up, and defer the message if it's not.
> I would expect that anything large enough to get caught by the lower
> timeout would get deferred and then you may end up with a queue with
> a bunch of emails that have large attachments.

dang, that's the exact same problem as above, just faster.  
  --waldo


> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFXgCnUVPJ6ufy+vIRAhUwAKC6zPvfmwTtWkfT4R4k4vpos9qQ2gCfUQK5
> qUNPGD9aV1+RnxoDCvNWKz0=
> =48WZ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Cialug mailing list
> Cialug at cialug.org
> http://cialug.org/mailman/listinfo/cialug
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://cialug.org/pipermail/cialug/attachments/20061117/41193afc/attachment.pgp