I am still trying to work out why people think there is a real distinction
between the problems faced with 821 and 822 from.
Both are going to result in issues when you have forwarding. These may
require an additional protocol fix in another area but that is out of scope.
So far nobody has disputed the fact that if the MARID record agrees with 821
and 822 from that we can conclude that the record is authentic. That seems a
very useful fact in its own right, one that can be used in combination with
information from other sources to safelist messages.
So far it has been asserted that the 821 situation is 'better understood'. I
don't agree. In fact the only thing I think we do understand about 821 FROM
is that another protocol measure such as SRS would be required to fix up the
forwarding situation properly in a way that does not require forwarders to
maintain per message forwarding state.
822 forwarding seems to be somewhat complicated by the fact that certain
mailing lists are not operated in strict compliance with RFC standards. This
has been chased down to one service and one platform, both of which are
fixable without deploying new code. A best practices guide for operators of
mailing lists, postcard sites and forwarders would seem to be the answer
here. These are the areas where the principal pain falls on the admins
today, they have a huge incentive to adopt a conformant configuration.
Here it does not seem to be a case of people having different requirements
as Patrik's diagram suggests. It is more a case of there being more than one
way to achieve the same end result and different people tried different
paths. It is a classic case of diversity without value.
What I think this group should concentrate on is defining ways to describe
the set of legitimate outgoing edge MTAs for a given domain and the
conclusions that can be drawn from the various identities being consistent
or inconsistent with this statement.
Then we can work out how to achieve each of the familiar email use cases
that we keep discussing (mailing list, forwarder, postcard site) in the
context of these properties.
It is pretty clear to me that there are sensible ways to make mailing lists
and postcard sites work that do not require additional protocol semantics.
Phill