ietf-mxcomp
[Top] [All Lists]

Re: towards a compromise

2004-04-22 06:34:30

Andrew Newton <andy(_at_)hxr(_dot_)us> wrote:

The current task of this working group is to pick the identity on which 
                                                        ^^^^^^^^
s/identity/identity or identities/

   Refer to our charter if necessary:

http://www.ietf.org/html.charters/marid-charter.html

MTA authorization is to take place.  In other words, in the MARID RR 
(whatever form it may take), the domain name is either 2821.MAILFROM, 
2821.HELO, 2822.From, 2822.Sender, etc... 

   "Either" suggests that Andrew is proposing a non-extensible MARID
DNS record. This would be a very bad idea.

There have been strong arguments for each of these and even arguments
for including all of them.

   Indeed: I find the "all of them" arguments most convincing.

   (Disclaimer: I wrote one of those myself.)

As chairs, we see very strong support for 2821 identities and somewhat 
strong support for 2822 identities.  Interestingly enough, such strong 
cases have been made for each that many favoring 2821 identities see 
2822 identities as being important for secondary consideration and vice 
versa.

Keeping in mind that the purpose of this working group is not to solve 
the entire problem of spam but to stop abuse of the email system within 
the scope MTA authorization, we wish to solicit opinions of the 
following proposal.

The MARID identity will be both a 2821 identity and a 2822 identity in 
the following manner:

  o  Since interpretation of the identity is up to the receiver, the 
sender will not state the type of the identity. 

   This is a bad idea. (It makes it even more likely Andrew is proposing
something non-extensible.)

   There are three very different meanings for authorizing the HELO, the
RFC2821-MAIL-FROM, and the various RFC2822 headers.

   Authorizing the HELO means that the domain (or ISP operating the
network) directly controls the particular MTA, and claims to respond
to reports of errors or misuse.

   Authorizing the RFC2821-MAIL-FROM means that the operators of the
domain have taken reasonable precautions to ensure that this email
address -- when used in RFC2821-MAIL-FROM by the particular MTA --
accurately represents the proper bounce address; and that they claim
to respond to reports of its misuse.

   Authorizing the RFC2822 headers is still a bit murky, and we haven't
fleshed out the exact meaning of that.

   Operationally, we have a pressing need to know _whether_ the domain
or network intends to vouch for the RFC2821-MAIL-FROM bounce address.
We emphatically should not settle for ambiguity on that issue.

The sender will simply state the identity, and the receiver will judge
it as 2821 or 2822 depending on need.

   Aside: I fully admit the receiver is going to do whatever it wants
regardless of what we say. :^(

   I know I have stated quite clearly that not every domain will want
to signal their policies on RFC2822 headers; and I sincerely hope it's
obvious that different domains will want to signal different policies.

<snip details>

  o  This does not preclude any other statements the sender may make 
regarding the domain identity, such as 'noForwardingFromThisDomain' 
etc..., nor make any assumptions regarding the format of the MARID RR.

   This is more encouraging: Andrew is at least leaving room for
expansion.

   (Indeed, if Andrew's proposal served to sneak this past Ted, we
could go ahead and define separate "extensions" for HELO, MAIL-FROM,
and each RFC2822 header to accomplish what we need. ;^)

The advantage here is that there are two well-known validation paths.  
Senders have a reasonable expectation of how their identity will be 
interpreted thus giving them confidence in how they formulate their 
RRs.  Receivers have only two validation paths to implement and/or 
configure.

   Hmm...

   Perhaps there _is_ a way to twist this so that the sending MTA's
domain can vouch for MAIL-FROM and simultaneously state no-policy
on RFC2822 headers...

--
John Leslie <john(_at_)jlc(_dot_)net>


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