it is inconceivable that this group will be able to work on more than
two of these within the time allotted. further, it isn't particularly
clear that 5-8 are within scope.
I disagree on this particular claim, but agree with the general point made.
I think that all we are doing here is describing the means by which a
domain name owner specifies authentication credentials that recipients
can check to determine:
1) That a message definitively originated from the purported domain
In the case that the domain name owner specifies that ONLY mail servers
that provide credentials send legitimate mail for the domain AND no
forwarding relationship is indicated by the headers that are present
the recipient can determine:
2) That a message definitively did not originate from the purported
domain.
In certain cases it will not be possible to arrive at conclusion 1 or 2
with certainty. It is very likely that at some point receivers will simply
refuse to accept any emails that cannot be definitively authenticated,
but that point is not going to be reached in august and it is very likely
that additional means of proving the legitimacy of forwarders will be
established in the interim.
I know some people want to redefine the nomenclature of computer security
and call an authentication credential an 'authorization' when it is not.
If we were putting RSA keys in the DNS instead of IP addresses people
would understand what function they are serving. Putting the mistake
in the title of the working group does not make it less of a mistake.
The set of all possible credentials is quite large, the IP address of the
sender domain, cryptographic credentials etc. But the charter and the time
line only allow sufficient time to address one set of credentials and
for reasons of expediency we have chosen IP addresses.
The set of 'identities' to which the authentication credential may be bound
is relatively small and all provide value.
2821 HELO If this resolves to a domain name there is no reason why it
should not be consistent in a legitimate mail.
2821 FROM If this is present (i.e. not a bounce) the only reason
it might be inconsistent in a legitimate email is that
it was forwarded.
2822 Sender If present there is no reason this should not be consistent.
Non-compliant forwarders should get in compliance.
2822 From If Sender is not present then there is no reason this should
not be consistent.
So there will be some gaps in the coverage at both the 2821 and 2822 level
until the issue of forwarders is resolved by another group. So what?
The value of all of these authentication mechanisms is going to be limited
unless you can combine authentication with some form of authorization data.
So what?
We are defining one component of a solution here, not a complete solution.
All we need to do here is to define the component we are chartered for
and be sure it will fit with the other components that we need in the
future.
Phill