ietf-mxcomp
[Top] [All Lists]

Comments on marid-submitter-01

2004-07-04 16:22:21

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:dcrocker(_at_)brandenburg(_dot_)com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>


<Prev in Thread] Current Thread [Next in Thread>