SPF deployment by Oct. 1 ?

Mailman List Mirror (Read Only)
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.

2

http://www.ietf.org/html.charters/marid-charter.html

  http://spf.pobox.com/

  - jared

3

try the marid working group...

http://www.ietf.org/html.charters/marid-charter.html

4

Thank you gentlemen.

try the marid working group...

http://www.ietf.org/html.charters/marid-charter.html

John B

5

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

6

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

7

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*)....

8

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

9

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.

10

Date: Mon, 26 Jul 2004 14:05:33 -0700
From: J.D. Falk

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.

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

11

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... :wink:

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])

12

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

13

> 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 -----------------+

14

>
> > 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

15

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