ietf-mxcomp
[Top] [All Lists]

towards a compromise

2004-04-21 09:15:22

The current task of this working group is to pick the identity on which 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... There have been strong arguments for each of these and even arguments for including all of them.

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. The sender will simply state the identity, and the receiver will judge it as 2821 or 2822 depending on need.

o For 2821, we will either pick HELO or MAIL FROM, but not both as they have different meaning. In the case of a null MAIL FROM, the receiver has the choice to abandon the MARID check or drop back to 2822 checking.

o For 2822, we devise a selection algorithm. This well-known selection algorithm will determine which header to use in the presence or absence of other headers.

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.

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.

-andy


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