|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Barracuda Networks Spam Firewall
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:
pgp00021.pgp
|