--On Sonntag, 12. Oktober 2003 00:20 -0700 Chris PetersenOwning two domains which are subject to *major* joe-job attacks (1 to 2 million email a month) I found a
<[EMAIL PROTECTED]> wrote:
ah. Wouldn't From come at the same time as return-path?No, its too late to reject a mail at this point.The sending mail server supplies the "return path" using the "MAILSo if the point of badfrom is to catch spammers/forgers, wouldn't it
FROM" SMTP command, from which this setting is derived.
also be relevant (not to mention less confusing) to check the From
field?
You still may use maildrop for this.
I've received
plenty of mail (spam) without a return-path, so it'd be nice to have
SOME way to match those messages.
If you reject mails with empty RP you also wont get any legit DSN's. There are of course reasons to reject DSN if a domain gets joejobbed, but this breaks the (seriously flawed) mail-system completely.
I am using a perl-script specified in etc/maildropfilter to selectively reject empty sender for joejobbed domains, test any servers which uses an empty sender against nearly every available dnsbl (except XBL...) and a local list of known clueless spam- and virus-bouncers. While this set of DNSL would be inpractical for all mail it serves well for those with an empty sender.
Would be nice if etc/esmtpd had a "BLACKLISTS_BOUNCE" option to specify additional DNSB to be used for empty senders.
few mechanisms that work very well for thwarting off these attacks--two at SMTP time and one at delivery
time:
1) Recipient verification is a /must/. This kept joe-job attacks from crashing my servers and kept the queues
at reasonable levels so as not to effect mail delivery times (the larger the queue the longer it takes to deliver
a given message).
2) If your MTA supports RBLs, use them. I use qmail's rblsmtpd to check all incoming email against a couple
of RBLs. Though not as effective as recipient verification, it does prevent a large number of SMTP connections
from ever being completed to my servers.
3) SpamAssassin. With qmail, I use qmail-scanner to filter all incoming and gatewayed email. So far, I haven't had
a single false-positive. I've chosen to deliver /all/ mail to valid users and to edjucate them as to how to filter spam
out of their inbox. If qmail-scanner detects a spam email it tags the email's header with "X-Spam-Status: Yes", and
some other information regarding why it was detected as spam.
The fourth mechanism I use (not really spam related, though) is a virus scanner. All inbound email is scanned for
viruses and, if a virus is found, it's not delivered--a simple notification is sent to the user indicating that someone
tried to send them a virus. This has stopped a lot of the recent "Microsoft Update" emails that ClamAV wasn't
catching (I'm currently using F-Prot). These emails have similar characteristics as spam but aren't detected as
such.
Keeping the email out of your queue is important so it doesn't effect your service--thus scanning messageAnd I'd rather not use maildrop - I want the spammers to get a rejection
from the smtp connection, not some bounced message that might hit an
innocent forged-addressee.
Dont worry, there are no ways to bounce an empty sender ;) Seriously, spammers do not care wether you accept the mail or not, they wont remove the victim from their list ever.
via maildrop isn't the most efficient way to handle it.
Rejected at SMTP time is a better way. It tells the spammer that your system is atleast moderately protected.
It may not stop them from /trying/ to attack you but it will prevent them from being successful.
There's also a lot of controversy in the qmail world, anyway, about tarpitting. tarpitting allows you to specify a
maximum number of recipients (RCPT TO) before your connection is delayed--the number of recipients and the
duration of the delay are both configuration. The idea is to hold open the connections so that the spammer's
servers are now being bogged down because your servers' are holding open the connections. The drawback is
that your servers are also consuming resources to hold these connections open. In theory, though, by using this
technique against spammers one would expect that they'll be removed from spammers' list because their servers'
are "slow".
This is good in theory but in practice I've found it to be less effective than what I mention above. When you haveSetup a filter for maildrop which checks wether at least three of the following conditions are met:
- receipient (your domain) must be listed in To:, no CC/BCC - From: contains ^(postmaster|mailer-daemon)@ - sender has proper RDNS, does not contain (dsl|cable|dialup|ppp) - has valid Date: and Message-ID:, which should matche RDNS domain - subject contains (undeliverable|failed|failure|unknown|returned) - many/most bounces follow a specific format, check the RFC: Content-Type: multipart/report; report-type=delivery-status; - HTML-tags in the first few lines or CN/KR/TW are self-explanatory...
and drop everything else into a 'forged-dsn' folder for weekly review.
/thousands/ or even /millions/ of emails with forged MAIL FROM or envelope senders there's simply no way to
review all of these weekly. And, if you're on a spammers list, things are only going to get worse. Stopping them
at the SMTP level is the best first line of defense.
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
