On 26 Jan 2009, at 21:11, Jason Hirsh wrote:
...
PS. It is a bad idea to bounce mail that was queued by postfix. This
causes backscatter (and you may be blacklisted...)
I am confused by this comment.. do you mean I shouldn't let amavisd
do any bouncing??
it handles all of my spam, content and vitus checking
All the regular subscribers to this list know what backscatter is, and
use the term comfortably. Unfortunately, the word isn't much in use in
the wider geek or user community.
Ordinary people tend to say "I got loads of spam today" when they may
mean "I got loads of backscatter". A user who speaks more precisely
than most might say "I got loads of junk email-bounces today" -
"backscatter" is the shorter term for this.
Backscatter is when a spammer forges an email address and the
addressee's system bounces it. The real holder of the email address
(the email address that the spammer forged) gets their inbox filled up
with junk "undeliverable" messages. This is obviously undesirable.
The problem with deciding not to deliver a message after you have
accepted it is that you are sure to send backscatter. This is
unpopular with mail administrators who know a lot about email (like
the folks on this list) because it is avoidable. ISTM that it's easy
for a n00b to set up a mail system that creates backscatter (and much
harder to configure a robust mail system that is proof against spam),
but as far as an administrator (who deals with Postfix all day every
day, to the exclusion of all else) is concerned, why should he suffer
junk in his mailbox just because you don't know how to set up your
system "properly"? Consequently, if you cause backscatter you may get
blacklisted.
In your case, if I haven't been clear, once the message reaches
amavisd it is too late to reject the message in a "safe" way - it is
already in your system. If you can get *Postfix* to reject the message
then it will do so whilst the original incoming SMTP connection is
still active, and leave the problem with that sending server. The bad
message does not become your problem, and you do not have to cause
backscatter. The sending mailserver is left with the problem of this
bad message - the chances are that it's a spambot, but if it is a
legitimate mail relay then it's up to that system administrator to
deal with (he can determine which one of his users sent the spam in
the first place & cut off their account).
The best analogy I can think of is if you accidentally ordered
something from Amazon - you phone them up & they tell you it's too
late to cancel the delivery. The courier arrives at your door and asks
you to sign for it. If you refuse to do so then the parcel gets
returned to the vendor and it's no longer your problem - you can
dispute the charges by saying "I never accepted that parcel - you
can't prove I signed for it and my credit card company will reject
your charges". If, instead, you accept the parcel from the delivery
driver, he drives away and you open up the box to look inside
(amavisd) it becomes your responsibility to return the goods and
persuade the vendor that you deserve a refund.
So if you reject a message using amavisd you shouldn't bounce it, but
just put it in your junk folder or deliver it to /dev/null. The
spammer is surely not using his real email address, so when you reject
it you send the problem on to someone innocent.
If you want to reject messages you should do so at the Postfix
"layer". I've read reports on this list indicating that use of
greylisting, Domainkeys/DKIM &/or SPF records can reduce your spam /
backscatter to a degree whereby filtering (such as amavisd) is barely
necessary.
Stroller.
