Author: Alan J. Flavell Date: To: Exim users list Subject: [Exim] .forward files and spam counterfeits
A substantial proportion of our users need to maintain an email
account elsewhere for their research. Typically they'll set up a
forwarding arrangement, to relay their mail to their local address on
our mail server.
The following kind of problem comes and goes, but at the moment it's
proving a particular nuisance.
1. Spammer sends mail to victim@??? with the envelope
sender counterfeited as the same address victim@???
2. the mailer at elsewhere.example obeys the user's .forwarding
arrangements and offers the mail to us, with their local address here
as recipient, and their elsewhere.example address as envelope sender.
Sometimes (but not always) their elsewhere.example address also
appears in the To: header.
3. We recognise the stuff as spam, and refuse to accept it.
So far, so good. But the MTA at elsewhere.example then goes and
composes a non-delivery report to the envelope sender,
victim@??? - which, courtesy of their .forward file,
gets sent to us. Typically this non-delivery report gets a lower spam
rating, so quite a number of them ooze in under the wire, and the
recipients complain about being spammed with non-delivery reports.
N.B the site elsewhere is in no way under our control, there's nothing
directly we can do to influence their immediate antispam policy.
Obviously the best answer would be to have them stop accepting and
forwarding spam, but we have to make do with the situation as we find
it.
I'm trying to work out what, if anything, I can do to recognise these
non-delivery reports, and jack up their spam rating to the point where
we would reject them. They're being offered (thank goodness) with a
null envelope sender, so there should be no further delivery attempts
when we refuse to accept them.
Anyone got useful suggestions, please?
The forwarding MTA's non-delivery report *does* contain the wording of
our original rejection notice, so - if we could detect this situation
in the original mail - then we could consider including some magic
incantation in our SMTP response, and recognise that incantation when
the non-delivery report came back. But I'm at a loss to know how to
recognise the situation in the mail headers, since the envelope-sender
is set to their victim@??? address, whereas the
recipient address is their address locally at our server, and we don't
in general know the correspondence between the one and the other.