Subject: TECH-OMISSION: Divergent assumptions about objectives

From: "Chris Haynes" <[email-masked]>
Date: Fri, 27 Aug 2004 04:28:23 +0100

I think I can see a pattern developing in several of the technical threads.

I appears that Sender-ID's (Microsoft's) primary, urgent concern is with
Phishing.

I would imagine that major banks etc. are, quite properly,  'encouraging'
Microsoft to find a reliable way to show users that messages really are from the
purportedly-responsible organization.

Microsoft has, it appears, chosen to do this by testing the PRA for proof of
authenticity (Sender-ID) and will then later find some way to display on the MTA
some symbol of authenticity alongside the PRA (e.g. the HTTPS-like closed
padlock which Margaret Olsen suggested).

If I am right, then Microsoft is only interested in absolute proof of
authenticity.

It does not really need to distinguish the range of other test values, such as
'probably authentic', 'probably forged', 'proven to be forged', and it thinks it
does not need to consider message entities other than the PRA (except in special
cases).

Now others, entering this WG with some knowledge of SPF, are perhaps approaching
this differently.

As the 'last call' process requires, we are looking only at the Sender-ID drafts
on the table - we have no visibility of any 'greater plan'.

Now when these people analyse the functionality provided by Sender-ID _in
isolation_,  they deduce that, like SPF, Sender-ID is intended to be a forgery
detection system, i.e. that it is supposed to be able to say categorically 'this
message is forged'.

This functionality is urgently required by MTA operators for the management of
threats other than Phishing.

What I think I observe is several people, myself included, making constructive
suggestions to improve the ability of Sender-ID to detect and handle forgeries,
and to do so in an SMTP-friendly way.  We then get frustrated when Sender-ID's
supporters don't seem to be interested, or actively oppose what are believed to
be viable, constructive suggestions made in good faith.

Suppose my deduction is right - suppose the central objective of Sender-ID is
only to recognise authentic messages.

Suppose the greater scheme of which Sender-ID is a part has no need to
distinguish the different degrees of 'not proven to be authentic'.

Suppose, therefore, that the ability to _prove_ that a message was forged is not
a core requirement of Sender-ID.

If I am right, would it help to make harmonious technical progress in this WG if
the -core draft were amended to reflect this significantly-different emphasis in
the objectives of Sender-ID?

If so, it's probably more appropriate for Microsoft to propose the change, but I
will (as the process requires) if necessary.

If I am wrong in my deduction, then we should be able to close this thread quite
quickly; I'm not about to argue with Microsoft about what their objectives
actually are or should be.

----------------

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.

Chris Haynes

---

From: Andrew Newton <[email-masked]>
Date: Fri, 27 Aug 2004 08:00:24 -0400

> 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

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 27 Aug 2004 16:45:34 +0200

> purportedly-responsible organization.

   http://weblog.infoworld.com/udell/2004/03/23.html

	\Maex
-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: "Chris Haynes" <[email-masked]>
Date: Mon, 30 Aug 2004 10:55:32 +0100

The co-chair, Andrew Newton, asked

> helps with readability and tracking of the issues.

=============================

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

---

From: "Chris Haynes" <[email-masked]>
Date: Mon, 30 Aug 2004 20:32:37 +0100

Please correct my  typing error.

I sent:

<snip>
> that the recipient ascribes to the message an authority which it does not
</snip>

Please replace 2821 by 2822 in the above.

Chris

---

From: "Chris Haynes" <[email-masked]>
Date: Mon, 30 Aug 2004 20:32:37 +0100

I sent:

<snip>
</snip>

Chris