[70524] in North American Network Operators' Group
Re: Barracuda Networks Spam Firewall
daemon@ATHENA.MIT.EDU (Valdis.Kletnieks@vt.edu)
Tue May 18 13:38:04 2004
To: "Majdi S. Abbas" <msa@samurai.sfo.dead-dog.com>
Cc: "Jared B. Reimer" <jared@theriver.com>, nanog@merit.edu
In-Reply-To: Your message of "Tue, 18 May 2004 10:11:20 PDT."
<20040518171120.GA26762@samurai.sfo.dead-dog.com>
From: Valdis.Kletnieks@vt.edu
Date: Tue, 18 May 2004 13:37:22 -0400
Errors-To: owner-nanog-outgoing@merit.edu
--==_Exmh_126540443P
Content-Type: text/plain; charset=us-ascii
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).
--==_Exmh_126540443P
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001
iD8DBQFAqknRcC3lWbTT17ARAlTjAJ40Ub32Y6mHkNdc/n8P7YYvJJ5CMACdG9q/
lFtsibQxgVRQcqx5xvWn6xA=
=3ZsF
-----END PGP SIGNATURE-----
--==_Exmh_126540443P--
