Subject: RE: Comments on marid-submitter-01

From: "Harry Katz" <[email-masked]>
Date: Wed, 7 Jul 2004 12:14:29 -0700

On Sunday, July 04, 2004 4:22 PM, Dave Crocker wrote:
> 
> 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:

Dave, thanks for the detailed review and comments on the submitter draft
-- and my apologies for the delay in responding.  I'm attempting to turn
the crank on -02 this week or early next, so this is good timing.  

> 
> 
> > 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.

I've heard no objections so far, and this group isn't shy about voicing
them.  :-)  

> 
> 
> > 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...

My intent was to put some context around the reason for creating this
extension.  However, your points are well taken.  I'll revise and
shorten the introduction.

> 
>   
> 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.

I think it is important to have the PRA algorithm defined in one and
only one place.  Marid-submitter will still have a dependency on that
algorithm whether it's specified in marid-core or a stand-alone
document.  Let me think about this one.

> 
> 
> > 
> >    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.

OK.  In any case, the actions taken by receiving systems with respect to
MAIL FROM are independent of any actions they take on the basis of
SUBMITTER, so this really doesn't belong here.  Thanks.

> 
> 
> >    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.)

OK

> 
> 
> > 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...

Is your main concern here about the dependency on marid-core in this
section?  The only dependency is on the PRA algorithm, so this
reinforces your suggestion to split that out into a separate spec.
However, I think it's important to give some guidance in marid-submitter
to receiving systems as to how to interpret and process the SUBMITTER
value.  Equally important, we need to give _senders_ a clear
understanding of what will happen to their messages when SUBMITTER is
used and abused.  So, I think 4.2, in some form, needs to remain.

> 
> 
> > 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.

I don't see how we can do this any other way.  Otherwise, we're going to
disrupt mail flow until everyone upgrades. 

> 
> 
> 
> > 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.

I'll rework this. 

> 
> 
> 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: Dave Crocker <[email-masked]>
Date: Thu, 8 Jul 2004 09:12:49 +0700

Harry,

HK> I think it is important to have the PRA algorithm defined in one and
HK> only one place.

definitely.

HK>  Marid-submitter will still have a dependency on that
HK> algorithm whether it's specified in marid-core or a stand-alone
HK> document.  Let me think about this one.

the simple way I think of it is that PRA is a clarification to
RFC2821.  The rest of the spec is definition of a new capability.

...
>> a way that minimizes risk both of timing and distraction...

HK> Is your main concern here about the dependency on marid-core in this
HK> section?  The only dependency is on the PRA algorithm, so this
HK> reinforces your suggestion to split that out into a separate spec.

I think that's right.

HK> However, I think it's important to give some guidance in marid-submitter
HK> to receiving systems as to how to interpret and process the SUBMITTER
HK> value.

slippery slope.  in reality, doing serious justice to that goal means
replicating marid-core.

smtp options can be extremely small, discrete things.  that they might
fit into some larger, more interesting system does not require that
the option document that larger thing.

HK> Equally important, we need to give _senders_ a clear
HK> understanding of what will happen to their messages when SUBMITTER is
HK> used and abused.  So, I think 4.2, in some form, needs to remain.

But that is really the job of marid-core.

>> > 4.3 Transmitting to a Non-SUBMITTER Aware SMTP Server
..
>> It makes it easier to adopt, but greatly weakens its import.
HK> I don't see how we can do this any other way.  Otherwise, we're going to
HK> disrupt mail flow until everyone upgrades.

either choice has a strong and entirely legitimate basis, but it also
has a strong and serious limitation.

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>