ietf-clear
[Top] [All Lists]

[clear] draft-lyon-senderid-core-01.txt

2005-05-20 11:08:43
1. Introduction
,----
| This document defines a pair of closely-related tests.  One validates
| a message's Purported Responsible Address (PRA) as defined in [PRA].
| The other validates a message's Reverse-Path (also known as MAIL-FROM
| address) as defined in [SPF].
|
| An e-mail sender complying with this specification SHOULD publish
| information for both tests, and SHOULD arrange that any mail that is
| sent will pass both tests.  An e-mail receiver complying with this
| specification SHOULD perform at least one of these tests.
`----

This "SHOULD" advice makes it difficult for an email provider to ensure
mailbox addresses are without conflict, without also licensing the PRA
algorithm.



2. Problem Statement
,----
| In the long run, once the domain of the sender is authenticated, it
| will be possible to use that domain as part of a mechanism to
| determine the likelihood that a given message is spam, using, for
| example, reputation and accreditation services. (These services are
| not the subject of the present mechanism, but it should enable them.)
`----

Because the server was authorized to support an "assumed accountable
sender," this process has "authenticated" the sender?  Would this be
like me saying "Because I authorized the postal service, and express
carrier, therefore any letter from them bearing my name is
"authentically" from me."  Reconsider the problem of not knowing which
identity was implied by the sender initially.

While this mechanism provides for a case where a message arrives through
an unauthorized server, which may allow the message to be rejected, this
by no means provides assurances sufficient for accruing reputations
against the "assumed accountable sender."  This would be wholly unfair.



3.1 Version and Scope
,----
| Under Sender ID, receiving domains may perform a check of either the
| PRA identity or the MAIL-FROM identity.  Sending domains therefore
| require a method for declaring whether their published list of
| authorized outbound e-mail servers can be used for the PRA check,
| the MAIL-FROM check or both.
`----

This does not prioritize these two checks.



3.4 Compatibility
,----
| Domain administrators complying with this specification are required
| to publish information in DNS regarding their authorized outbound
| e-mail servers.  [SPF] describes a format for this information
| identified by the version prefix "v=spf1".  Many domains have
| published information in DNS using this format.  In order to
| provide compatibility for these domains, Sender ID implementations
| SHOULD interpret the version prefix "v=spf1" as equivalent to
| "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.
|
| Administrators who have already published "v=spf1" records SHOULD
| review these records to determine whether they are also valid for use
| with PRA checks.  If the information in a "v=spf1" record is not
| correct for a PRA check, administrators SHOULD publish either an
| "spf2.0/pra" record with correct information, or an "spf2.0/pra ?all"
| record indicating that the result of a PRA check is explicitly
| inconclusive.
`----

Those that do not wish to be assessed by a system using a dubious
"authorization" as a basis for compiling reputations, will have
difficulty expressing this desire as a result of these semantics. To
"opt-out" of Sender-ID, a weak level of authorization must still be
offered.  There have been presentations where weak authorizations would
eventually be refused, and coupled with warnings these types of records
could potentially lead to damaging one's reputation.  I would describe
this as the "Sender-ID trap."



6.1 DNS Attacks
,----
| An MTA could largely defeat such an attack by using a properly
| paranoid DNS resolver.
`----

While noting the format and related processing of the DNS record is
defined in draft-schlitt-spf-classic-00, it seems this statement could
elaborate on specific attacks.  Warnings regarding the processing of
lookups in parallel, asserting a truncated timeout, or preventing
replicate lookups, rather than assuming any attack related specifically
to SPF/Sender-ID is resolved by way of paranoia. : )



7.1 Simple E-mailers
,----
| In the majority of cases, the domain's published information will be
| the same for both the PRA and MAIL FROM variants of this test.  In
| this case, domains SHOULD publish their information using an SPF
| record with the prefix "v=spf1".  Doing so will render their
| published information usable by the older SPF protocol, too.  (See
| [SPF] for information on the SPF protocol.)
`----

A SHOULD publish "v=spf1" interpreted as applying to either PRA or
MAILFROM ensures lack of clarity.  To achieve a modicum of spoofing
resistance, depreciate "v=spf1" in the SPF draft, which is integral to
this draft. 



7.2 E-Mail Forwarders
,----
| In order to pass the PRA variant of the test, a program that forwards
| received mail to other addresses MUST add an appropriate header that
| contains an e-mail address that it is authorized to use.  Such
| programs SHOULD use the Resent-From header for this purpose.
|
| In order to pass the MAIL FROM variant of the test, a program that
| forwards received mail to other addresses MUST alter the MAIL FROM
| address to an address under its control.  Should that address
| eventually receive a DSN relating to the original message, that DSN
| SHOULD be forwarded to the original MAIL FROM address.  However, if
| this altered address receives any messages other than DSNs related to
| the original message, these messages MUST NOT be forwarded to the
| original MAIL FROM address; they SHOULD be refused during an SMTP
| transaction.
`----

Forwarding DSN?  This seems challenging and problematic.  This also
drops the typical "on vacation" response.  It also weakens BATV efforts.



7.5 MUA Implementers
,----
| When displaying a received message, an MUA SHOULD display the
| purported responsible address as defined by this document whenever
| that address differs from the RFC 2822 From address.  This display
| SHOULD be in addition to the RFC 2822 From address.
`----

Again another SHOULD use a licensed algorithm?  Although this may be
intended to stop phishing attacks made against financial institutions,
the predominate MUA does not display anything other than the pretty name
of the From.  In addition, Sender-ID places the From at the lowest
priority of accepted headers.  As another consideration, financial
institutions place great value on assured delivery, that is incompatible
with the strict authorization needed to protect the user from seeing
phishing attempts.

There are less wrenching and safer alternatives.

If financial institutions were to use S/MIME and browser compatible
certificates, this could already be handled by more than 400 million
email clients such as Outlook, Outlook Express, Lotus Notes, Novell
Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora, Becky!,
Bat!, Mulberry, Blackberry, and more.  If not understood by the MUA, or
the recipient is aware of signature related problems with their
provider, the signature attachment could be ignored.  At least wary
recipients could check certificates to be assured of the From address
without using a proprietary MUA.

In addition, there are other lower cost signature schemes, such as
DomainKeys, that can be implemented on the MSA and MDA, independent of
the MUA, and afford real consumer protections with much stronger
assurances, without expecting all users will adopt a proprietary MUA.

Calling Sender-ID "Sender Authentication" should stop.  This is
overstating to a great degree the assurances afforded from a
confirmation of server authorization by an apparent sender.  Remember,
these records are public, and it is typical for email providers to be
shared by many different domain owners.  It is hard enough getting
providers to authenticate their clients, without expecting them to
enforce new constraints that are sure to cause endless complaints.
While it remains the email provider most able to ensure abuse is
curtailed, Sender-ID ignores their accountability.

I find it difficult trust this approach that offers no means to verify
who was actually accountable.  At least with a signature, there is
little doubt.

-Doug

<Prev in Thread] Current Thread [Next in Thread>
  • [clear] draft-lyon-senderid-core-01.txt, Douglas Otis <=