This also can happen today.
Viruses act just like human viruses. They need a path of contagion.
Block that path or limit it and the virus is quickly contained and dies.
The virus writer would have to tailor the virus to these type systems
and also figure out how to get the virus to propagate outside these
systems in order to have it survive and grow. The virus writer would
also have to have an account internal to these systems. Far be it from
me to try to figure out what a virus writer is going to do next, but
writing specific code to take advantage of this type of infection path
would not be in the virus writers best interest as it does not allow for
the highest, most widespread infection rate.
Sure, the locks on my house don't keep people from driving semi-trucks
through my front door... Does that mean I should beef up my deadbolts?
Don't try to over design the system. It is not necessary.
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Chris
Sent: Wednesday, August 18, 2004 1:14 PM
To: Daryl Odnert
Cc: IETF MARID WG
Subject: Re: Point of Order: Incomplete, flawed response to MARID WG
RE: Point of Order: Incomplete, flawed response to MARID WG Charter On
Wednesday, August 18, 2004 5:38 PM at Daryl Odnert asked:
Chris Haynes wrote:
Therefore, Sender-ID _requires_ MTAs of previous good
repute to generate and send Bounce messages which:
Sorry, but I don't understand this objection. An MTA is
only responsible for sending a non-delivery notification
after it has accepted responsibility for relaying the message. What is
the real-world situation in which an MTA would be accepting a message
for relaying when that message will be unable to pass a Sender-ID test
at the next hop?
I think the following scenario is one which illustrates my concern:
Small business: (Virus on) End user MUA sends message to internal MTA,
which stores-and-forwards message to public-facing MTA of the business'
This ISP-MTA has not implemented Sender-ID, so does no know that the PRA
will later be detected as a forgery. This ISP is generally slack about
security, adding Resent-From headers, etc.
ISP-MTA accepts message for onward delivery, cannot initially contact
destination MTA, stores message and undertakes to try again later.
Second attempt to contact destination MTA succeeds.
Destination MTA applies Sender-ID, rejects message during SMTP protocol
exchange with a '550'.
ISP-MTA notes the '550' and fulfils its 'contract' by generating a
non-delivery "Bounce" message, which is sent to the address in
"Mail-From" in the original
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from all computers. 113