In
<C6DDA43B91BFDA49AA2F1E473732113E5DBA71(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Fixing other forwarding relationships is a little trickier but not
all that hard.
"Not all that hard." Hmmm... I disagree. There are a lot of options
for email forwarders, none of them are pretty.
I think we will sink a lot of time into this subject alone, even if we
limit it to RFC2821 data.
I think that the layout of the draft should be:
4. Hints for filter writers (NON-Normative)
At other points
MUA considerations
Verifying RFC 822 From, Sender, Reply-to
The only "MUA consideration" and RFC2822 data verification stuff I
think should be put into the RFC is a list of known problems and a
recommendation proceed with extreme caution.
On the SPF-discuss list, we had the following exchange:
: > Trying to determine how far down the Received: chain you can trust can
: > be a real challenge, but there are reasonably good techniques for
: > doing so.
:
: It is near to impossible one one message alone unless you have the
: user configure it for you (not happening for most users)
:
: But it is quite easy on a series of messages.
The funny thing is that just yesterday, SpamCop started to roll out a
change in their system that requires every SpamCop user to specify
their trusted incoming email routing. Spammers have gotten good
enough with forging headers, that the SpamCop folks have given up
trying to figure out how far down the Received: chain you can trust.
This is despite the fact that they are sharp cookies, know a lot about
email, have been working in the area of RFC2822 header analysis for
years, and have collected a great deal of data about email
relationships.
I'm sorry, but I'm *very* skeptical of trying to do anything with the
RFC2822 data. Until someone comes up with a specific program
(preferably open source so that it can be experimented with) that can
be shown to do a good job on real live data, I will object to trying
to add this to the RFC.
I do not think we can get a useful RFC out in a reasonable amount of
time and have any confidence that RFC2822 checking is correct.
Phill:
Do you have code that verifies the RFC2822 data? Can you show it to
us?
-wayne