Thanks for the reply Rand. Due to normal thread-drift, I'll probably
leave any further comments to the SPF-discuss list.
In <41A4BC43(_dot_)1050809(_at_)sendmail(_dot_)com> Rand Wacker
<rand(_at_)sendmail(_dot_)com> writes:
wayne wrote:
* Could you proved some more detailed results of the "extensive
testing under real-world deployment scenarios"? That would be
extremely useful to many people, even if it is in a very rough
format.
Analysis of testing data/requirements as gathered by some of our large
ISP customers, Enterprises, and a number of key technical partner
sites. Comparing the authentication/filtering results between
SPF/SID/DK protected mail. Discussions with infrastructure folks
about their needs and likely deployment paths. Mostly this
information was used to develop likely course of evolution for
authentication on the net, which this document reflects.
I would be very interested in more raw data, such as number of false
positives for each method, percentage of domains/messages that can be
checked, etc.
* SPF validates the Return-Path: header, which *is* usually available
to the end-user, although not usually visible. The Resent-*
headers that Sender ID validates are *not* any more user-visible
than the
Return-Path: header.
Why does the paper claim that the Return-Path: header is not
visible
while the Resent-* headers are?
Return-Path: is a reflection of the RFC2821 MAIL FROM address, and is
entirely at the discretion of the MDA as to whether or not to insert
it.
RFC1123 section 5.2.8 says that the Return-Path: header MUST be
inserted on final delivery. RFC2822 says that the header is "optional",
but "optional" is not in upper case and I think it is OPTIONAL until
final delivery.
[...] For example, looking at my two primary mailboxes (one
personal, one work, both running very common standards-based
software), one records/exposes Return-Path: and another doesn't
(ironically in reverse order from what I expected).
Interesting. In my admittedly limited research, I found the
Return-Path: header was always added.
* What incompatibliites to end-to-end cryptographic authentication
systems does SRS cause? I know of none.
The reference is specifically with regards to BATV compatibility.
Hmmm... Interesting. You hadn't mentioned BATV anywhere in your
white paper, and I guess I really didn't consider BATV to be a
cryptographic system. Yes, there are some verbage in the BATV spec
about a public key signing system, but they don't go into any detail
and I can't see how they are going to be able to get a useful
signature in the 64 character limit on the local part.
* Why is only mention DK, but not IIM or SES?
There is currently very little deployment of IIM or SES, and little
indication that will grow soon.
Hmmm. Ok. There is far more deployment of SES than BATV though.
* Why do you recommend mailing lists modify the MAIL FROM addresses to
make sure they are properly authrorized, but you do not recommend
that mail forwarders do the same? Any modification to the MAIL FROM
address by mailing lists cause the same problems as for forwarders,
so the recommendations should be the same.
Mailing lists should be taking responsibility for the messages that
they send out, and this shift in accountability should be recorded in
the MAIL FROM and Sender: headers. Forwarders are simple redirectors,
and should do as little to messages passing through them as possible.
Ok. I guess this is venturing into an area that Meng has just ruled
off limits. I'll just say that I believe that forwarders have every
bit as much responsibility for the messages as mailing lists.
-wayne