Hi, On Tue, 30 Dec 2003 11:40:22 -0800 "Gary Smith" <[EMAIL PROTECTED]> wrote: > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of Greg Webster > Sent: Tue 12/30/2003 11:31 AM > > Not 100% a spamassassin issue, but I've got a ton of spammers trying any > address they possibly can on my domain. Postfix responds to each one > with a 'reject: unknown user', but of course spammers don't use their > own address and my mail queue gets insanely full (not quite to the point > of a denial-of-service, but close). Does anyone know how to tell Postfix > not to respond to emails sent to users that don't exist?
> Create a user called "blackhole" and then add the entry into the postfix > configuration (/etc/postfix/virtual) that says (usually the last line) > > @yourdomain.com [EMAIL PROTECTED] > > This basically says any lost mail goes to the blackhole user. Then > create a cron job similar to this: > > :>/var/mail/blackhole > > on a 1 hour interval or something like that. Alternatively you can > choose not to erase it and use it as a spam catch for feeding bayes. > > It should work... First, you probably shouldn't accept mail that you don't have any intention of delivering, meaning you should reject unknown users during the SMTP transaction (after RCPT but before DATA) rather than accepting the mail, shunting it to a disposal queue, and periodically flushing that queue. It's a waste of local resources (bandwidth, storage, processing power, and the effort to deploy and maintain such a scheme.) Yes, it solves the problem of junk messages bloating a queue, but it still means you have to do something with mail that should have never been accepted in the first place. My question is what messages are filling Greg's queue? If you reject unknown users with a 550 error before the SMTP DATA phase, no message should be put in any queue. The sending mailer gets a 550 error code during the SMTP transaction and disconnects - done. One problem that crops up is that often a backup MX doesn't know which users are valid on the primary so the backup blindly accepts the mail, passes it to the primary where the mail is rejected, and the backup MX tries to send a bounce (DSN) message back to the (forged) sender. Those messages will rot in a queue until they expire or someone mucks them out. This is bad (your system is emitting bounce spam) and I don't have a good solution. The right way to handle this is to let the backup MX know what users are valid on the primary so it can reject mail rather than accept-then-bounce, probably with something like LDAP, or another shared user database. This is better addressed on the Postfix list. For a number of reasons, I am very interested in the resolution of this problem... -- Bob ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
