The co-chair, Andrew Newton, asked
On Aug 26, 2004, at 11:28 PM, Chris Haynes wrote:
I have classed this as a TECH-OMISSION because its a case of inserting/
modifying a requirement so that it matches the actual functionality
being
specified; it closes a requirement-functionality gap which is what I
interpret
the spirit of TECH-OMISSION to be.
Can you need to be more explicit about the change you desire? This
helps with readability and tracking of the issues.
-andy
=============================
Please find below proposed changes to draft-ietf-marid-core-03.txt, which embody
my proposed changes.
It will be recalled that I proposing to meet the TECH-OMISSION objectives by
re-writing the requirements of Sender-ID to match the reality of the
functionality specified.
This is also intended to make much more clear the positioning and capabilities
of Sender-ID among the battery of anti-spam, anti-virus and anti-phishing
techniques under consideration.
I have just drafted here the Abstract and Introduction to the '-core' document.
If these changes were accepted, there are doubtless many other parts of the
Sender-ID drafts which could benefit from a corresponding revision and
clarification.
================
Replace the existing Abstract with...
vvvvvvvvvvvvvvvvvvvvvvvvvvv
Abstract
Internet mail is vulnerable to a specific form of deception, known colloquially
as 'Phishing'.
In a Phishing attack a message contains an unauthorised 'From:' address, thereby
purporting to come from a legitimate authority, such as a bank. The message
content often attempts to perpetrate a fraud on the recipient.
This specification defines a mechanism by which a bona-fide sender of a message
can assure the recipient that the host offering the message from transmission is
authorised to do so by the domain purporting to send the message.
^^^^^^^^^^^^^^^^^^^^^
===================
Replace the entire Introduction with...
vvvvvvvvvvvvvvvvvvvvvvvvvvv
1. Introduction
Today, a huge majority of unwanted email contains headers that lie
about the origin of the mail. This is true of most spam and
substantially all of the virus email that is sent.
One particular form of lying involves forging the RFC 2821 'From:' header, so
that the recipient ascribes to the message an authority which it does not
actually have.
Such messages are frequently used to attempt to perpetrate a fraud on the
recipient.
Bona fide senders have no way of assuring recipients that messages purporting to
be from them are, indeed from them.
A potential solution, which is compatible with current SMTP practice, would be
to be to provide some means for MUAs to authenticate the address purporting to
be responsible for the message, and to display some clear visual indication of
authenticity (akin to the HTTPS closed padlock symbol) alongside the domain
which has been found to be responsible for the message.
This specification contributes to such a solution by defining a mechanism for
message authorisation, and recommends that authorisation failures be notified to
the RFC 2821 message sender through the DSN 'bounce' mechanism.
In this mechanism bona fide senders use DNS to publish rules which confirm that
a host (identified by IP address) is authorised to send messages purporting to
originate from that domain.
The recipient of a message from that host can determine the Purported
Responsible Address of the message, obtain the rules published by the domain of
that address, and thereby assure itself that the message was authorised by its
purported originator.
The way that assurance is communicated to an MUA and displayed to its user is
not the subject of this specification.
To provide compatibility with the overwhelming majority of legitimate remailers
and mailing list operators the test of the 'From: address is modified to use the
Purported Responsible Address, determined algorithmically from the 'From:',
'Sender:', 'Resent-From: and 'Resent-Sender:' message headers.
Where the PRA is not the 'From:' address, any MUA display mechanism SHOULD
display the domain of the PRA, as well as the 'From:' address, and MUST NOT
indicate that the 'From' address has been assured.
^^^^^^^^^^^^^^^^^^^^^^^^^
Chris Haynes