For the receiving MTA, complexity does not come from multiple
identities but from multiple code paths to support multiple
authorization policies. So, is there a way to take a group of the
identities and make them all apply to a single authorization
policy on the receiving MTA?
They are not authorization records, if you view them as authentication
credentials the question answers itself.
First for any given email sender identity there are three possible states:
1) There is no authentication record defined
2) There is an authentication record defined and the use is consistent
3) There is an authentication record defined and the use is not consistent
Second the set of authentication records can have two states:
A) The set of authentication records is complete
B) The set of authentication records is incomplete
Third, there are three possible outcomes:
PASS 2 Pass on to spam filter noting that identity is valid
FAIL 3A Probably reject
MAYBE 1 3B Pass on to spam filter
So now lets look at what happens with multiple identities.
First is there confusion for the sender?
I don't see this, HELO should always be configured for a legitimate domain.
Lets put forwarders aside for a moment, is there any reason that the first
party to inject a message into the Internet should use ANY identity that
is inconsistent with the authentication
The order of events here is that somebody configures their mail server
and at some point after is going to establish a MARID record. For confusion
to arise you have to imagine that the owner of the domains Alice.com and
Bob.com would for some reason have configured one mail server to handle
mail with RFC2822 From set to Alice.com but announcing itself HELO Bob.com
and vice versa. I really don't think that is very likely.
The person who owns the domain name has a very simple task, issue an
authentication credential to any mail server that they want to be allowed
to represent themselves as the domain name in any capacity and decide
whether this list is complete or not. The alleged confusion only arises
if you want to start confusing the domain name owner by telling them
about stuff they don't need to know like 2821 From vs 2822 From.
Second is there exponential complexity with multiple identities?
Absolutely not, the complexity of choosing to test three idsentities
rather that one is somewhat less than three times the complexity of
testing one. Here the chairs are wrong in their assertion of an exponent,
it is not there.
The first point is that the authentication of any identity by the
receiver is optional.
The second is that the evaluation of the authentication is going
to take place in combination with an AUTHORIZATION function, that
is authorization data that is decided by the receiver. Introducing
the concept of authorization records written by the sender are going
to lead to muddy thinking because you will end up with two sets of
records both called authorization.
The receiver evaluation function can be written
enum states = {pass, fail, undecided}
states state = undecided
foreach (identity i in identities) while (state = undecided)
states authentic = authenticate (i)
if
(authentic = fail)
state = fail
(authentic = pass)
state = authorization (i)
The only additional complexity introduced by the checking of multiple
identities is the loop. Someone might object that you can end up with
the same message passing or failling based on the order in which the
identities are verified, but that is easily fixed:
The perceived complexity here is due to a misformulation of the problem,
not a defect in the solution.
Phill