RE: Point of Order: Incomplete, flawed response to MARID WG CharterDaryl,
Perhaps it will help if I summarise my understanding of how Sender-ID (and SPF)
actually work.
My example was of an outbound, stored message in which the PRA (e.g. "From:")
was forged.
The "To:" address is that of a valid recipient.
The 'Mail-From:' address is a real address, but that of an 'innocent victim'
who has no connection whatsoever with the small business or the ISP.
In Sender-ID (and in SPF) it is the policy of the domain which the message
claims to be from (the _Purported_ Responsible Address and the Mail-From
address respectively) which is consulted, not the policy of the domain of the
host attempting to send the message.
So, as the message does not claim to come from the small business, it does not
matter one jot whether or not the small business has published a record, and
whether or not that record identifies the outbound MTA as a valid sender of its
messages.
It will be the record of the domain which has been forged which will be
consulted, and as that domain's record will not have authorised this particular
MTA host to send its messages, the message will be rejected and Sender-ID will
have worked as required.
However, with Sender_ID, the host which was attempting to send the Original
(stored) message will now create and send a Bounce message to whatever address
the forger decided to put into the Mail-From header. It may well also put a
full copy of the original message (including virus, sexually-explicit spam,
etc.) into that message.
That virus-carrying message will now be sent, unauthorised and unchecked by
Sender-ID, to whatever innocent victim was chosen by the forger.
This is the 'harm' that Sender-ID would be causing. If Sender-ID had not been
used, this second, virus-carrying message would not have been created and sent.
Headline summary: Sender-ID propagates viruses!
One really significant difference between Sender-ID and SPF is that SPF
prevents both messages being sent.
SPF inspects the Mail-From address and asks its domain record if the host
currently attempting to send the original message is authorised to use that
Mail-From address.
If the SPF test result is 'fail' (i.e. if the domain record derived from the
Mail-From address says "I _never_ use that host") the message is proven to be
unauthorised, the SMTP 'Deliver-or-Bounce' commitment is null-and-void, so the
outbound message is discarded and no bounce is generated.
To return to the essence of my original question to the Chair, Sender-ID only
seeks authority for the Original message. No authority is sought for Bounce
messages.
SPF seeks authority for _both_ messages - thus covering the whole of the MARID
charter's problem-space.
[Note, I use SPF solely as a 'proof-of-existence' of technology which has
demonstrated its ability to validate the authorities of both messages. As far
as I am aware, SPF has not formally been submitted to the IETF, so has not yet
undergone the rigorous engineering inspection which Sender-ID is now
undergoing. It would appear that there may also be other as-yet-unsubmitted
candidate technologies to be considered].
HTH
Chris
----- Original Message -----
From: Daryl Odnert
To: 'Chris Haynes'
Cc: IETF MARID WG
Sent: Wednesday, August 18, 2004 6:55 PM
Subject: RE: Point of Order: Incomplete, flawed response to MARID WG Chart er
Chris,
In your example, it wasn't clear to me whether or not the
the small business domain published a Sender ID policy
in the DNS.
Assuming the domain did not publish any policy data, the
receiving MTA cannot perform the Sender ID test if there
is no policy information in the DNS, so the message should
not be rejected with a 550 error unless it has is some other
good reason to do so.
On the other hand, if the domain did publish a Sender ID
policy and the message is rejected for policy reasons, then
either the policy data is inaccurate or the ISP is doing
something to the message that it shouldn't be doing.
So, I still don't understand the crux of your complaint
about Sender ID here. How is Sender ID causing any harm
to anyone here?
Daryl Odnert
Tumbleweed Communications
Redwood City, California
====
Chris' example:
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.