Tue Sep 23 17:22:24 PDT 2003
Some viruses send themselves through the infected machine's smarthost
-- typically the outgoing SMTP server for the infected user's ISP or
company. These machines are correctly configured when they relay mail
from any machine in a given network. You could configure them to
check the envelope sender domain of outgoing messages, but that is
pretty rare, and not doing so is not a misconfiguration.
That relay will try to deliver to the recipient's MX. If that second
machine rejects the message, the original relay will generate a bounce
per 2822, to the forged address.
You see to have somehow got the idea that all SMTP relays are open
relays but that's simply not true.
> blocking it at smtp will not generate a bounce it will when
> correctly configured
Wrong; see RFC2822 s6.1:
If there is a delivery failure after acceptance of a message, the
receiver-SMTP MUST formulate and mail a notification message. This
notification MUST be sent using a null ("<>") reverse path in the
envelope. The recipient of this notification MUST be the address
from the envelope return path (or the Return-Path: line).
> > > But that's just the point. When you block a virus email at the SMTP
> > > level, you're usually blocking the computer which is actually infected
> > > with the virus. And if it's not, the computer relaying it to you is
> > > an open relay, which you shouldn't be accepting email from
> > > anyway.
> > The computer relaying it to you may be legitimately relaying it to you.
> > If your domain has multiple MX hosts, not all run by you, then they may
> > acept messages that will get blocked by your "real" MTA at SMTP time.
> > Thus generating a bounce message from the relaying MTA.
> how much are you willing to deal with because of someone else has not
> configuring the relaying mail server correctly?
What we're discussing here is whether it is responsible to cause large
volumes of bounce messages to the forged address, who has no practical
way of fixing the problem.
Postfix (and presumably other MTAS, and also procmail) comes with a
DISCARD option which can be applied at the SMTP layer and is far more
appropriate. Tell me: is there any way in which rejecting the message
> if the relaying mta is accepting mail with forged headers then you know where
> the problem is.
Yes we wouldn't have this problem, if every MTA could strongly verify
all the headers by e.g. requiring a cryptographic signature
corresponding to the sender address. But that is irrelevant to SMTP.
> got root?
Maybe you should learn a bit more before you use it.
More information about the linux-elitists