[unisog] Barracuda effectiveness (vs Puremessage)

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Mon Jul 16 20:36:00 GMT 2007


On Mon, 16 Jul 2007 15:47:33 EDT, shawnl at up.net said:

> + Don't try to do use ldap for user verification.  Really slowed things down
> and killed our ldap servers.

On the flip side, you *really* want to think about what to do if you *don't*
do userid verification.  If you get hit by a ditionary-attack spam run, and
the spam engine fails to flag it, you have some big problems:

1) If you send a '250 OK' accepting the mail before verifying the userid,
you're RFC-obligated to send a bounce back if the mail fails later due to
a '550 user unknown'.

1a) If the domain is bogus/not accepting mail, the bounce sits in your
queue until it times out.  And you can't tell if it's a "not accepting"
unless you try to do a callback verify, which is evil itself.

1b) If the return address is in fact valid, you're about to become known as
a "blowback spammer" yourself, because you're spamming the valid-but-forged
purported source address.

2) Quietly discarding isn't a good solution either - especially if you quietly
discard a *valid* bounce.

You're much better off being able to send the 550 rejection in-band, at the
time of the original connection.   Even if you need to do a nightly dump of
"valid addresses in the LDAP" and cache it locally, that's still better than
actually accepting the mail.  It has the added benefit that you *know* that you
can 550 for an invalid recipient the instant you see the RCPT TO:, no matter
*what* else your filters do/don't catch.

Of course, the Barracuda may not give you properly usable options to implement
all this stuff...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.sans.org/pipermail/unisog/attachments/20070716/4b01016b/attachment.bin 


More information about the unisog mailing list