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