ietf-mxcomp
[Top] [All Lists]

Re: Point of Order: Incomplete, flawed response to MARID WG Chart er

2004-08-18 10:15:53

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