| > Please keep in mind that what you see is the worm connecting to your | > MTA from xxxxxxx.gotadsl.co.uk. It doesn't matter if you reject or
| > discard the message at DATA time, because the worm is unlikely to
| > generate a bounce message to its own forged return address. Or does
| > it? | | Good point. However, if it comes via another MTA, it will cause a bounce
| to be sent to some poor unsuspecting individual who is probably already
| pulling their hair out trying to keep the stuff out of their system...
You're right - a bounce *will* be sent, in this relatively rare case.
However there's an important difference. If you 5xx a virus after DATA
and cause a relaying MTA to bounce then the non-delivery report received
by the innocent bystander will not have YOUR domain as its From: header.
Therefore, when the innocent bystander replies to complain, the complaint
goes not to you, (another innocent bystander). It goes to the postmaster
responsible for the relay MTA - which should have been running Exim + exiscan
and thus not accepted the crap in the first place. Perhaps [s]he will
bother to make some improvements soon!
Also, note that the relay MTA is not an innocent party. It *must* be the
smarthost relay of the ISP hosting the infected customer peecee [1].
Therefore, this ISP *is* in a strong proper position to notify their real
virused customer that they have a problem and hopefully make a difference.
[1] unless the MTA is an open relay. ISTR encoutering viruses (forget
which) that came with a hard-coded list of open-relays to abuse.
Staggeringly, most of those relays were still up+open, despite the viruses
having spread widely. Duh! Clearly, the postmasters of those open relays
deserve everything they get.
--
Chris Edwards, Glasgow University Computing Service
