SPF deployment by Oct. 1 ?
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? John Bittenbender P.S. If I missed a mail about this somewhere along the path please disregard or edjamacate me off-list.
On Sat, Jul 24, 2004 at 09:49:41PM -0400, 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?
http://www.ietf.org/html.charters/marid-charter.html http://spf.pobox.com/ - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
try the marid working group... http://www.ietf.org/html.charters/marid-charter.html On Sat, 24 Jul 2004, 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?
John Bittenbender
P.S. If I missed a mail about this somewhere along the path please disregard or edjamacate me off-list.
-- -------------------------------------------------------------------------- Joel Jaeggli Unix Consulting joelja@darkwing.uoregon.edu GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Thank you gentlemen.
try the marid working group...
John B
On Sat, 24 Jul 2004, John Bittenbender wrote:
http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html
Does it strike anyone else as odd that they would be encouraging the use, but not have SPF setup yet for the primary domains they are known for yet? AOL is leading the way by publishing their SPF records. I can understand not implementing the blocks or delays yet, but publish the records ASAP. I think this will be the next best thing in E-mail. I'd love for that date to be August 1 though. FYI SpamAssassin 3.0 has / will have SPF checks built in. Gerald
Gerald wrote:
Does it strike anyone else as odd that they would be encouraging the use, but not have SPF setup yet for the primary domains they are known for yet? AOL is leading the way by publishing their SPF records. I can understand not implementing the blocks or delays yet, but publish the records ASAP.
It does, I´ve also been advocating for them to implement reverse maps for servers responsible for distributing updates so they could more easily be identified but to no avail. Pete
I think this will be the next best thing in E-mail. I'd love for that date to be August 1 though.
FYI SpamAssassin 3.0 has / will have SPF checks built in.
Gerald
On Mon, 26 Jul 2004 11:51:26 EDT, Gerald said:
I think this will be the next best thing in E-mail. I'd love for that date to be August 1 though.
OK... Aug 1 is a weekish away. Check your inbound mail for today, and ask yourself how much you'd be losing if you started enforcing SPF today, and what percentage of the sites you get legitimate mail from are likely to deploy SPF tags this week..... And then keep in mind that SPF is *known* to break certain types of mail reflectors and forwarding (argue all you want about whether such things are fundementally broken - they're still *in production use*)....
On 07/26/04, Valdis.Kletnieks@vt.edu wrote:
On Mon, 26 Jul 2004 11:51:26 EDT, Gerald said:
I think this will be the next best thing in E-mail. I'd love for that date to be August 1 though.
OK... Aug 1 is a weekish away. Check your inbound mail for today, and ask yourself how much you'd be losing if you started enforcing SPF today, and what percentage of the sites you get legitimate mail from are likely to deploy SPF tags this week.....
I'd be extremely surprised if anyone were planning to block all mail from non-SPF-using sites any time soon. However, it'll still be useful as an additional data point in a filtering decision process. -- J.D. Falk "...one of the worst signs of our danger <jdfalk@cybernothing.org> is we can't imagine the route from here to utopia." -- Kim Stanley Robinson
I'd be extremely surprised if anyone were planning to block all mail from non-SPF-using sites any time soon. However, it'll still be useful as an additional data point in a filtering decision process.
Indeed, running the spfmilter/libsfp2 combo in "--markonly" mode and noting the details of the inserted headers has been instructive enough to justify the couple of minutes spent setting it up. Stephen
JDF> Date: Mon, 26 Jul 2004 14:05:33 -0700 JDF> From: J.D. Falk JDF> I'd be extremely surprised if anyone were planning to block JDF> all mail from non-SPF-using sites any time soon. However, JDF> it'll still be useful as an additional data point in a JDF> filtering decision process. Kind of like using blacklists or <whatever> as an input to a filtering process. We don't block based on any one list's output, but we [currently] track 19 DNSBLs -- plus sender IP... I'm looking forward to SPF to provide another data point that hopefully will provide a strong correlation. Eddy -- EverQuick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked.
J.D. Falk wrote:
OK... Aug 1 is a weekish away. Check your inbound mail for today, and ask yourself how much you'd be losing if you started enforcing SPF today, and what percentage of the sites you get legitimate mail from are likely to deploy SPF tags this week.....
I'd be extremely surprised if anyone were planning to block all mail from non-SPF-using sites any time soon. However, it'll still be useful as an additional data point in a filtering decision process.
Good point, and nobody would receive the NANOG mailing list... ;-) Received-SPF: none (Cache: No spf record for (merit.edu) ) client-ip=198.108.1.26; envelope-from=<owner-nanog@merit.edu>; Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) -- Robert Blayzor INOC, LLC rblayzor@inoc.net
On Mon, 26 Jul 2004 Valdis.Kletnieks@vt.edu wrote:
On Mon, 26 Jul 2004 11:51:26 EDT, Gerald said:
I think this will be the next best thing in E-mail. I'd love for that date to be August 1 though.
OK... Aug 1 is a weekish away. Check your inbound mail for today, and ask yourself how much you'd be losing if you started enforcing SPF today, and what percentage of the sites you get legitimate mail from are likely to deploy SPF tags this week.....
From what I understand the fall back for SPF to use the MX record and then
Just checking if I have this correct: the A record if that isn't found, which covers alot of the net, how much? Does anybody have any SPF compliance measurements (exclude spam) from their production mail servers that they can share? Organizations that have separate outgoing mail servers from incoming mail servers will need to define SPF records. Mail forwarding to other domains on a per user basis (i.e. using .forward) without updating an organizations SPF record will fail the SPF check. The SPF check is based on the envelope sender and not the message from, so it won't break as many mailing lists as it would first seem.
And then keep in mind that SPF is *known* to break certain types of mail reflectors and forwarding (argue all you want about whether such things are fundementally broken - they're still *in production use*)....
1 percent? 5 percent? 0.1 percent? (of course this depends on all kinds of things) Then the other question is do we have any kind of figures for how much spam currently fails the SPF check in any known test? Even if SPF doesn't end up blocking very much spam, if it blocked most worms and viruses, that might be worth while. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+
On Tue, 2004-07-27 at 19:38, Mike Leber wrote:
On Mon, 26 Jul 2004 Valdis.Kletnieks@vt.edu wrote:
On Mon, 26 Jul 2004 11:51:26 EDT, Gerald said:
I think this will be the next best thing in E-mail. I'd love for that date to be August 1 though.
OK... Aug 1 is a weekish away. Check your inbound mail for today, and ask yourself how much you'd be losing if you started enforcing SPF today, and what percentage of the sites you get legitimate mail from are likely to deploy SPF tags this week.....
Just checking if I have this correct:
From what I understand the fall back for SPF to use the MX record and then the A record if that isn't found, which covers alot of the net, how much? Does anybody have any SPF compliance measurements (exclude spam) from their production mail servers that they can share?
One needs to know outbound addresses and not just those seen in round-robin fashion of inbound machines. MX records are not a fix.
Organizations that have separate outgoing mail servers from incoming mail servers will need to define SPF records.
There is an alternative. The BATV proposal would remove the need to publish the SPF records, but SRV records for the outbound machines should be published if to enjoy named accreditation.
Mail forwarding to other domains on a per user basis (i.e. using .forward) without updating an organizations SPF record will fail the SPF check.
The SPF check is based on the envelope sender and not the message from, so it won't break as many mailing lists as it would first seem.
It breaks all forwarding, whereas BATV does not.
And then keep in mind that SPF is *known* to break certain types of mail reflectors and forwarding (argue all you want about whether such things are fundementally broken - they're still *in production use*)....
1 percent? 5 percent? 0.1 percent?
(of course this depends on all kinds of things)
Then the other question is do we have any kind of figures for how much spam currently fails the SPF check in any known test?
Even if SPF doesn't end up blocking very much spam, if it blocked most worms and viruses, that might be worth while.
The proposal in question is not SPF, but rather Sender-ID. There is a big difference. Sender-ID will not stop either spam or phishing. Sender-ID allows alternative identities just as likely to confuse users. SPF could aid stopping some of the bounce, as it checked the MAIL FROM parameter, but Sender-ID completely ignores MAIL FROM, so bouncing continues. Neither Sender-ID or SPF could hope to stop zombie machines. CSV, on the other hand, can stop both spam and zombies by way of name based accreditation allowed to be aggressively vetted. CSV, the other MARID proposal. :^) CSV, BATV and SPF, would be a winning combination at ending both spam and viruses. -Doug
On 07/26/04, Gerald <gcoon@inch.com> wrote:
http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html
Does it strike anyone else as odd that they would be encouraging the use, but not have SPF setup yet for the primary domains they are known for yet?
From that article: 'Sender ID is a proposed technology standard, backed by Microsoft, for verifying an e-mail message's source. It combines two previous standards: the Microsoft-developed "Caller ID," and the Meng Weng Wong-developed SPF.' Here's Hotmail's Caller ID record: _ep.hotmail.com text = "<ep xmlns='http://ms.net/1' testing='true'><out><m><indirect>list1._ep.hotmail.com</indirect><indirect>list2._ep.hotmail.com</indirect><indirect>list3._ep.hotmail.com</indirect></m></out></ep>" http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx -- J.D. Falk "...one of the worst signs of our danger <jdfalk@cybernothing.org> is we can't imagine the route from here to utopia." -- Kim Stanley Robinson
JD, Nice work. Good to hear Hotmail is doing their fair share to be a responsible member of the community by adapting SPF. Does this mean that other improvements, such as not defaulting to sending HTML-tagged e-mail with a 10-column line wrap, aren't far behind? =) ---Rico On Mon, 26 Jul 2004 14:05:17 -0700, J.D. Falk <jdfalk@cybernothing.org> wrote:
On 07/26/04, Gerald <gcoon@inch.com> wrote:
http://www.infoworld.com/article/04/07/22/HNmicrosoftid_1.html
Does it strike anyone else as odd that they would be encouraging the use, but not have SPF setup yet for the primary domains they are known for yet?
From that article: 'Sender ID is a proposed technology standard, backed by Microsoft, for verifying an e-mail message's source. It combines two previous standards: the Microsoft-developed "Caller ID," and the Meng Weng Wong-developed SPF.'
Here's Hotmail's Caller ID record:
_ep.hotmail.com text = "<ep xmlns='http://ms.net/1' testing='true'><out><m><indirect>list1._ep.hotmail.com</indirect><indirect>list2._ep.hotmail.com</indirect><indirect>list3._ep.hotmail.com</indirect></m></out></ep>"
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
-- J.D. Falk "...one of the worst signs of our danger <jdfalk@cybernothing.org> is we can't imagine the route from here to utopia." -- Kim Stanley Robinson
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). Cheers, James -- James Couzens, Programmer ( ( ( ((__)) __lib__ __SPF__ '. ___ .' (00) (o o) (0~0) ' (> <) ' ---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo--- http://libspf.org -- ANSI C Sender Policy Framework library http://libsrs.org -- ANSI C Sender Rewriting Scheme library ----------------------------------------------------------------- PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF
participants (15)
-
Douglas Otis -
Edward B. Dreger -
Gerald -
J.D. Falk -
James Couzens -
Jared Mauch -
Joel Jaeggli -
John Bittenbender -
John Bittenbender -
Mike Leber -
Petri Helenius -
Ricardo "Rick" Gonzalez -
Robert Blayzor -
Stephen Stuart -
Valdis.Kletnieks＠vt.edu