In <9156B81DAA29204989AD43E88688FAAB01373742(_at_)df-lassie(_dot_)dogfood>
"Harry Katz" <hkatz(_at_)exchange(_dot_)microsoft(_dot_)com> writes:
[....] Reading through yesterday's
Jabber log it seems the participants wanted to tackle identities in this
order: HELO/EHLO, RFC2821 MAIL FROM, RFC2822 headers. IMHO this is
exactly backwards. I agree there may be some merit in validating the
MTA by checking its HELO/EHLO domain as Dave Crocker is proposing.
This being a standards group, I don't think we can assume that any
document that we create will mean we have set the priorities of mail
admins. Mail admins will do what they think is best.
What I do think we can do is try and get well thought out standards
published in as timely a fashion as possible. I think the ordering of
the above priorites in part reflects how long various people feel it
will take to create a well thought out standard for each identity.
Do you have any working code that validates the RFC2822 that we can look
at, test, analyze and collect data with? I realize that the C-ID doc on
the microsoft website has an algorithm outline, but that would require a
lot of work to turn into working code.
If you can't provide working code, can you provide data and your own
analysis of the situation?
HKATZ: We're working on the code. The analysis is in section 3.2 of the
Caller ID spec.
I have read the spec a couple of times, but I guess I was looking for
real-world examples of how it works, what kinds of problems you are
running into, possible solutions, what MTAs and MUAs have support,
approximate sizes (LoC or time) of implementations, etc.
Basically, I think that "seeing is believing". I dunno about anyone
else, but I personally have not done a lot of actual work on verifying
RFC2822 identities, and I haven't talked with anyone who has. I have
thought about the subject quite a bit, but since I haven't seen RFC2822
validation in action, I tend to think that it will take longer to
create a standard for validating it. Actually, I tend to think it
will take *much* longer to create a spec with a rough consensus.
-wayne