On Jun 21, 2004, at 4:32 PM, Mark Lentczner wrote:
1) Margaret Olson's examples
Alas, these examples didn't actually state what aspect SPF couldn't
handle. I don't know if the desire is to have mail rate information
in SPF, or reputation information or what. As a part of the system,
SPF seems to me to work in all the examples given.
Yes, the desire is to have mail rate information in the MARID record. I
apologize for not being clearer about that. Several people have noticed
that you don't necessarily trust the record author - but that is why
you accredit both the sender and any channels used with indirect
pointers. The rate at which a domain sends mail is an important piece
of the risk assessment puzzle - should I accept this mail or not? If I
know that you send at a rate that is inconsistent with spamming or if
you have a very thorough, audit driven accreditation, then I'll accept
your mail.
There are many ways in which I can envision transmitting and enforcing
rate information; my examples were intended simply to illustrate the
problem.
MARID on it's own doesn't do very much; it just says that the domain is
authorized to send mail via these MTAs. It is essential for a broader
solution to the spam and phishing problems but not sufficient. Phill
Hallam-Baker and Jim Lyons have made other suggestions for how we might
incorporate the reputation, accreditation, signature, and other
information that is necessary. I don't think any of us have the
complete answer yet but these things are emerging. The will be tied to
the authentication. We need to be able to accommodate the additional
information, even though we don't have it completely designed at this
moment in time. We know it is out there.
2) Jim Lyon's examples
These examples focused on assignment of reputation, and how that might
depend on the route the mail takes, or even perhaps on different
mailbox names within a domain. I contend that these are issues for
the reputation systems. All SPF does is authenticate that the domain
believes that it's mail could have traveled via a particular MTA. If
that check passes, normally, one just feeds the domain name into a
reputation system (such as white or black lists.) If there is need
for finer grained reputation, then it is up to some reputation service
to offer better assessments based on more information. Nothing in any
of the proposals tells clients how they should assess reputation. If
it is argued that domain name based reputation will be the only de
facto available option, then I submit it isn't too hard for large
entities to use multiple mail sub-domains:
jane_doe(_at_)example(_dot_)com - mail from real people
news(_at_)support(_dot_)example(_dot_)com - mail from opt-in newsletters
coolOffer(_at_)ads(_dot_)example(_dot_)com - unsolicited advertisement
Creating sub-domains to make up for a syntax limitation doesn't make
any sense to me.
3) Phillip Hallam-Baker's examples
These examples are a clear extension into other approaches. None of
these examples has anything to do with domain authentication of an IP.
To quote Phillip about such extensions: "...the number of degree of
freedom are huge". To this end, these examples beg for something much
larger than the part of the problem the current projects ever set out
to handle.
I understand the desire to design a more comprehensive mail policy
format. And I understand the desire that such a format be extensible
for future approaches that are now only contemplated. However, the
proposed XML syntax doesn't achieve this either: While it is true
that XML provides a much richer syntactic framework in which to extend
an original document format, it says nothing about the semantic
meaning of such extensions.
As Jim Lyons stated elsewhere in this thread, you need to stick to
upwards compatible extensions. In practical terms, this means you can
add information but you can't change the definition of existing
information. The XML syntax handles this well. I agree that no amount
of syntax will paper over the problems inherent in an extension that
changes the meaning of existing published records.
Margaret.
molson(_at_)constantcontact(_dot_)com
margaret(_at_)margaretolson(_dot_)com