On Tue, 2004-07-27 at 13:38, James Couzens wrote:
On Sat, 2004-07-24 at 18:49, John Bittenbender wrote:
http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html
As a side note, I notice that the article mentions a submission to the IETF but I haven't seen any RFC's related, if there is one out there can someone please point it out for me?
I didn't see anything obvious here:
http://www.ietf.org/html.charters/dnsop-charter.html
or here:
http://darkwing.uoregon.edu/~llynch/dnsop/
Looking in the wrong place?
The "MARID" version of SPF is a bastardization of the original SPF being called SenderID in that they are trying to cram as much crap into it as they can. Although it appears that the idea of storing "SenderID" records in XML as DNS records has been averted I'm extremely sceptical that anything will come of that group in the near future.
As for people parsing SPF records and dropping email as a result of a FAIL response, there are some groups out there doing this. Verizon tried for a few days I believe and then quickly reverted when they realized the error in doing so. I think its much to soon to be doing this especially in view of the forwarding problem with SPF.
The MARID list is pretty useless for anyone seeking information, and actually its pretty useless even if you are trying to subject the proposed protocol to any idea you might have as many on the list have disregarded valid issues several times. Perhaps this is to retain focus, or perhaps its because they think they know better, this is my opinion in view of what I have witnessed thus far. You will find a better reception on the SPF-DISCUSS list as is hosted by spf.pobox.com. You can find links to it on the spf.pobox.com site by clicking on the "Forums" link (poorly worded I know, the old site was much better).
Sender-ID employs existing SPF records intended to qualify the RFC 2821 MAIL FROM, but then fully ignores the RFC 2821 MAIL FROM. Sender-ID introduces "Purported Responsible Address" (PRA) from the RFC 2822 headers, where differing types trump more recent headers. The author of SPF and owner of spf.pobox.com dropped the MAIL FROM strategy of ASRG to adopt this proprietary scheme of Microsoft. PRA will not abate the bounce traffic. PRA is not able to end Phishing as touted either. A message can be fully validated by including a header such as Resent-From: random.random.Starbucks.to where the From seen by the user could be anyone. There is no means to accredit the administration of the domain accountable for the introduction of the spam either. With the typical scale otherwise needed, many publish their records open-ended to allow mail sent from differing points of access. If a common relay point were published in a closed-ended fashion, then those sharing this server would know they could forge mail for that domain as fully validated. The number of DNS lookups to obtain the "record set" could include hundreds of queries. There is a timeout of 20 seconds for obtaining perhaps dozens of references contained within a single "SPF" record, such as PTR, MX, A, AAAA. If a timeout occurs, the message receives a 450 temp error and is to be repeated at some point. A new series of DNS queries is immediately started for the next message. Without exceeding Sender-ID time limits, the process can continue for more than 3 minutes per message. It also threatens network stability with high levels of UDP traffic together with premature termination and overlay of these queries. With IPS's transparent interception of SMTP traffic, mail may go missing if this is not known before hand. Defining an "open" record set could swamp DNS with spammer abuse. Forget about mail forwarding working. But, by all means, publish, publish, publish. Caveat Emptor. Publisher beware. MARID http://www.ietf.org/html.charters/marid-charter.html (note, the marid-protocol links are in error). Sender-ID drafts: http://www.ietf.org/internet-drafts/draft-ietf-marid-submitter-02.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-core-02.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-00.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt CSV drafts: http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-intro-01.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-dna-01.txt There is an alternative solution that can do something to protect the networks and not break mail. The Client SMTP Validation (CSV) drafts provides a solution to ensure the SMTP client can be both authenticated and authorized to send mail. If used in conjunction with SPF, it could effectively thwart spam and Trojan systems. PRA however, keeps the door open. : ( There is a possible alternative to SPF that uses a DomainKey approach to sign the RFC2821 MAIL FROM using the local part called Bounce Address Tag Validation (work in progress). http://www.brandenburg.com/specifications/draft-crocker-marid-batv-00-06dc.h... There is also work ongoing to provide an effective means to identify the sender (work in progress). http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-00.txt -Doug