Re: SPF deployment by Oct. 1 ?
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 <[EMAIL PROTECTED]> wrote: > > On 07/26/04, Gerald <[EMAIL PROTECTED]> 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 = " testing='true'>list1._ep.hotmail.comlist2._ep.hotmail.comlist3._ep.hotmail.com" > > http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx > > -- > J.D. Falk"...one of the worst signs of our danger > <[EMAIL PROTECTED]> is we can't imagine the route > from here to utopia." > -- Kim Stanley Robinson >
Re: SPF deployment by Oct. 1 ?
On Tue, 2004-07-27 at 19:38, Mike Leber wrote: > On Mon, 26 Jul 2004 [EMAIL PROTECTED] 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
Re: SPF deployment by Oct. 1 ?
On Mon, 26 Jul 2004 [EMAIL PROTECTED] 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? 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 | | [EMAIL PROTECTED] http://www.he.net | +---+
Re: SPF deployment by Oct. 1 ?
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, . 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 RFC2
Re: SPF deployment by Oct. 1 ?
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 signature.asc Description: This is a digitally signed message part
Re: SPF deployment by Oct. 1 ?
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=<[EMAIL PROTECTED]>; Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) -- Robert Blayzor INOC, LLC [EMAIL PROTECTED]
Re: SPF deployment by Oct. 1 ?
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 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: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked.
Re: SPF deployment by Oct. 1 ?
> 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
Re: SPF deployment by Oct. 1 ?
On 07/26/04, [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> is we can't imagine the route from here to utopia." -- Kim Stanley Robinson
Re: SPF deployment by Oct. 1 ?
On 07/26/04, Gerald <[EMAIL PROTECTED]> 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 = "list1._ep.hotmail.comlist2._ep.hotmail.comlist3._ep.hotmail.com" http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx -- J.D. Falk"...one of the worst signs of our danger <[EMAIL PROTECTED]> is we can't imagine the route from here to utopia." -- Kim Stanley Robinson
Re: SPF deployment by Oct. 1 ?
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*) pgpuulkugkTW5.pgp Description: PGP signature
Re: SPF deployment by Oct. 1 ?
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
Re: SPF deployment by Oct. 1 ?
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
Re: SPF deployment by Oct. 1 ?
Thank you gentlemen. > try the marid working group... > > http://www.ietf.org/html.charters/marid-charter.html John B
Re: SPF deployment by Oct. 1 ?
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 [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: SPF deployment by Oct. 1 ?
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 [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
