The flaw in this line of thought is that computer viruses are engineered
by people who are far more intelligent than biological viruses. Once an
obstacle appears, the human can alter the virus, most of which upgrade
themselves automatically already.
In the case of SPF, all the virus operator has to do to continue forging
email is to have the virus upgrade itself to use the infected domain's
relays using the user's stored email configuration or just by guessing, or
better, by using the SPF records. After that, they forge away.
--Dean
On Wed, 18 Aug 2004, Sauer, Damon wrote:
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.
Regards,
Damon Sauer
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Chris
Haynes
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
Chart er
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:
[snip]
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'
ISP.
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
(virus-generated?) message.
Chris
*****
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