Barracuda Networks Spam Firewall

Tue May 18 17:37:22 UTC 2004

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). 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20040518/87f704ba/attachment.sig>