In <15928998-93AF-11D8-8B03-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton
<andy(_at_)hxr(_dot_)us> writes:
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.
I agree, almost everyone sees both the RFC2821 and RFC2822 data as
very important. So important, that I don't want to see either a rush
job that doesn't work, nor stuff kept back until everything is perfect.
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.
I don't quite understand what you are saying here and I'm wondering
about the same things that David Mayne questioned.
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.
I agree with Gordon: What is the matter with doing both HELO and MAIL
FROM checking a-la DMP and SPF?
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.
Well, I've ranted about this subject a lot recently: I don't think we
can "devise a selection algorithm" that can be tested and proven
trustworthy in the time allowed for in the schedule.
I think it is time to split tracks and pursue both the RFC2821 and the
RFC2822 identities separately. I think we can move much quicker than
the schedule on the RFC2821, but the it will take longer. Right now,
we appear to both be doing a rush job and foot dragging, creating the
worst of both.
As long as the MARID record is reasonably extendable and appears to
allow for RFC2822 validation, I see no reason not to go full steam
ahead with RFC2821 validation.
Can we do a split track?
-wayne