Subject: Comments on marid-submitter-01

From: Dave Crocker <[email-masked]>
Date: Mon, 5 Jul 2004 06:22:10 +0700

Eric and Harry,

The next version of mail-crocker-email-architecture includes the
submitter construct.  The sequence that led to your spec convinced me
that there is a core construct we need to have be explicit in the
email architecture.

Comments on your draft's details:

> Abstract
> 
>      The responsible submitter is the e-
>    mail address of the entity most recently responsible for introducing
>    a message into the transport stream.

I find this to be a clear, concise definition and matches what I think
it should cite.

However, I think it worth asking whether anybody has any discomfort
with it at all and if so, why?

My reason for asking is that the definition needs to be bullet-proof
against any sort of "reasonable" misinterpretation.

> 1. Introduction
> 
>    The practice of falsifying the identity of the sender of an e-mail
>    message, commonly called "spoofing", is a prevalent tactic used by
>    senders of unsolicited commercial e-mail or "spam".  A number of
>    proposals have been put forward to address the spoofing problem.
>    Notable among them are [RMX], [SPF], [LMAP] and [CALLERID].

This line of discussion invites useless debate, because those proposals
generally are about RFC2821.MailFrom rather than RFC2822.Sender or its
relations and they are about spam control rather than improving the
ability of an SMTP session to have access to the purported sender
information.

Because this is intended as a very narrow specification, rather than
either a pedagogical treatise or a broader effort to reduce spam,
etc., that you have a simpler introduction that goes quickly to the
requirement you want Submitter to satisfy.

In general, a specification that compares itself with other
specifications is inviting debate about reportorial accuracy, and
other distractions to the technical focus.  You do not have to have
the comparisons, so I strongly suggest leaving them out.

Rather, how about something roughly along the lines of:

  Email abuse has highlighted the need to improve identification of
  the "submitter", the entity responsible for injecting a message into
  the email transport stream. The email message object current uses an
  array of different headers for this identification. The current
  specification codifies rules for correctly determining the submitter
  and encoding that identification into an email transport
  session-time field. This will permit...

In contrast, the following text:

>    Deriving the purported responsible domain from RFC 2821 data has the
...
>    Deriving the purported responsible domain from RFC 2822 headers has

is evaluating technical options that feed directly into the design of
this spec, so keeping the text IS useful to*directly* understanding the
thinking behind this specification.

> 4.1 Setting the SUBMITTER Parameter Value
> 
>    The purpose of the SUBMITTER parameter is to allow the SMTP client to
>    indicate to the server the purported responsible address of the
>    message directly in the RFC 2821 protocol.
> 
>    Therefore, SMTP clients that support the Responsible Submitter
>    extension SHOULD include the SUMBITTER parameter on all messages
>    where the purported responsible address, as defined in section 4 of
>    [SENDER-ID] differs from the MAIL FROM address.

A matter of my own ietf style preference:

The specification for determining Responsible Submitter strikes me as
having much broader utility than just the marid-core specification.

Although this might seem like nit-picking, I suggest you break it out
into a separate document, so that it receives independent focus and so
that it does not have to fate-share with other documents. Further,
that then means there is not need for THIS specification to fate-share
with marid-core.

> 
>    At some future time, it is likely that use of the SUBMITTER parameter
>    will be made MANDATORY whenever the purported responsible address
>    differs from the MAIL FROM address.

In my opinion, this is a very bad bit of text to have.

Specifications quite simply should not refer to the requirements of
the future, because they are typically wrong, especially when they
refer to social requirements rather than technical ones.  Whether this
is made mandatory depends upon the social aspects of its adoption, not
on the technical aspects of its operation.

You do not have to have this text in here, for the specification to be
whole and useful, so take it out.

>    A common model will be for the Mail User Agent (MUA) to transmit a

   will -> could

(submit is not yet in sufficient use to make the "will" certain, no
matter how much we all might wish otherwise.)

> 4.2 Processing the SUBMITTER Parameter

I think this entire section is is the wrong document, so I suggest
removing it.

It makes this specification be a customer of the marid-core
specification, rather than the reverse.

This can (and I believe should) be a neat, clean, simple, direct
specification for adding a bit of information into the SMTP control
flow. Broader, bigger systems USES of this information ought to go
into broader, bigger specifications that cite this specification,
rather than having this specification cite them.

Again, this is about setting up specification dependencies in a way
that minimizes risk both of timing and distraction...

> 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server
> 
>    When an MTA receives a message with a SUBMITTER parameter and must
>    forward it to another MTA that does not support the SUBMITTER
>    extension, the forwarding MTA MUST transmit the message without the
>    SUBMITTER parameter.

This is a very big decision.  I don't know whether I think it is right
or wrong, so I'm flagging it, hoping the working group discusses it.
It makes it easier to adopt, but greatly weakens its import.

> 6. Security Considerations
> 
>    The purpose of this extension is to help deter the practice of
>    forging or "spoofing" the address of the sender of an e-mail message.

Actually, the purpose of this extension is to move RFC2822
Sender-related identification into the email transfer control stream,
to improve its use during transfers.

All the rest is part of the broader, grander specification, elsewhere.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Jul 2004 10:02:03 +0100

> It makes it easier to adopt, but greatly weakens its import.

What are the alternatives?

I note that as SUBMITTER is currently specified it is an optimisation to
bring some post-DATA information into the pre-DATA envelope so that liars
can be detected sooner. If a message passes through an MTA that doesn't
support SUBMITTER the information can be recovered.

(I wonder if SUBMITTER will be of any use in practice. Why should we
expect a criminal to co-operate with optimizing our anti-forgery
protocols?)

I agree with Dave's other comments.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BERWICK ON TWEED TO WHITBY: NORTH OR NORTHWEST 3, BECOMES SOUTHEAST FOR A
WHILE, THEN WEST OR NORTHWEST 3 OR 4 OVERNIGHT. SCATTERED SHOWERS. GOOD.
SLIGHT.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 5 Jul 2004 07:49:21 -0400

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 04, 2004 7:22 PM
Subject: Comments on marid-submitter-01

> It makes it easier to adopt, but greatly weakens its import.

Well, the non-compliant SUBMITTER receiver will probably use CSV on the
sender then :-)

or use SPF with a simple HELO modification.  So even if:

        SPF(sender-MAILFROM , ip) -->  FAIL

the HELO Lookup:

        SPF(sender-HELO, ip) -->  PASS

must be true if the sender is a compliant SPF/SUBMITTER client.  After all,
it has made extensive changes to SMTP in order to comform to it in the first
place.  The client domain used must be MARID ready if you want to keep the
chain of trust unbroken.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com