In
<C6DDA43B91BFDA49AA2F1E473732113E0A19D0(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Take a look at the following post from the SPF list.
One thing it shows is that this particular user has a problem that is
due to his local mail configuration.
No, it was a problem with a user not understanding the difference
between the "RFC2821 from" and the "RFC2822 from".
Rather than telling him to fix it (he won't) I think we need to accept
that any set of rules for processing records are going to be affected
by the local mail configuration.
The user *did* fix it, he is now using the right data.
So rather than having the 'debate' proposed in the charter as to which
aspects of a mail message are the 'right' ones to use I think we should
try to write a spec that does not need the debate.
I really do not see how you can write a system that works equally well
for both the RFC2821 and RFC2822 "from" address. In some ways, a set
of rules for the exact process would have reduced the chance that this
person would have made an error.
Writing the spec in a declarative fashion becomes quite easy. You simply
tell the sender to list out the set of all outgoing mail services at
the edge of their network that you wish external receivers to accept
mail from. You then provide simple ways to encode that set:
I think this will likely cause a certain amount of confusion. It
isn't just the domain owner's machines that it can be acceptable to
send email from.
Basically, I think there is going to be a certain level of confusion
by mail admins and email users no matter what we do. I do not think
that a declarative spec with not even hints about how the information
is supposed to be used is a cure-all.
-wayne