nanog mailing list archives

Re: Barracuda Networks Spam Firewall


From: Valdis.Kletnieks () vt edu
Date: Tue, 18 May 2004 13:37:22 -0400

On Tue, 18 May 2004 10:11:20 PDT, "Majdi S. Abbas" said:
      Quite frankly, I'm at a loss as to why anyone would wish to accept
and queue mail that they cannot deliver.  Queuing everything just allocates
disk unnecessarily and results in a lot of delayed bounce backscatter, 
almost always directed at a third party (in the common case of spoofed from: 
headers).

Well.. you're somewhat right - *IF* the mail gateway is able to make the
determination quickly and definitively, reacting as soon as you see the RCPT TO:
is a good idea.  However, that can be a big 'if' in some configurations...

Traditionally, "accept and queue" was a reasonable way for a gateway
mail relay to function (and if you think about it, it's usually the ONLY way
for an off-site secondary MX to function).  You'd accept and queue everything,
and then forward it to an internal machine that actually knew what mailboxes
were valid addresses.  If you don't do that, then you have to make your
authentication system visible to machines on your DMZ, which has it's
own touchy implications....

For high-volume sites, there are also firewall state issues - if you're getting
100K messages/hour, and each one has to be open for 5 seconds because of
authentication issues on the RCPT TO:, you'll average 138 open connections.
If you accept, queue, and deal with it later, you can get it down to 1 second
and then you only average 27 open connections (numbers for illustration
purposes only). 

Attachment: _bin
Description:


Current thread: