Mailing List Archive

In <417A7FC9.3020304@convio.com> David Crooke <dave@convio.com> writes:

> We're (among other things) an email marketing provider, and getting
> close to taking the plunge with our clients and having them create SPF
> records.

Cool!


> He're a practical question:
>
> Meng has been working to get Microsoft on board and came up with the
> hybrid standard labelled "Sender ID", which if you follow it to the
> letter says that you (as a mail sender) can publish either Caller ID
> or SPF, and Caller ID takes precedence if you have both, because the
> receiving MTA should perform the DNS lookup for Caller ID first.

There are a lot of misconceptions in this paragraph, which really
isn't too surprising considering how messy the whole business has
been.

SPF is a system that has been evolving since last summer. Rapid
changes to the standard stopped early last winter, but it has still
been slowly evolving since. There is a move underway right now to
solidify this standard as "SPF-Classic".

SPF-Classic is by far the most widely deployed anti-forgery system
(aka designated sender system) in the world, easily outnumber all
other systems combined.


Much more radical changes to SPF have been proposed by several people,
including Meng, and are being debated. These proposals have gone by
the names of "Unified-SPF" and "SPFv2" and a few others.

Since the Unified-SPF/SPFv2 spec is still very much in flux, I can't
recommend committing to it unless you are willing to be actively
involved in its development.


CallerID was Microsoft's original proposal for a designated sender
system. From what I can tell, it has been abandoned, and the
Caller-ID records published under Microsoft.com, and hotmail.com.
(but, not msn.com!)


SenderID was the proposed merger of SPF and CallerID that was
developed during the IETF's MARID working group's life. A final spec
was never delivered before the working group was shut down. The spec
was about 90% SPF and 10% CallerID, and many have argued, including
Meng, that most of the 10% from CallerID is badly broken.

As evidence to just how committed Microsoft is to the SenderID spec,
note that they haven't published SenderID records for microsoft.com
nor hotmail.com. If they did publish records, they would likely use
their SenderID Wizard, which creates invalid records. Yes, Microsoft
knows that their wizard is publishing broken records, but say that
because they outsourced the job to India, they can't easily change
it.

There is only one system out there that I know of that implements
SenderID, and that's sendmail's SID-milter. Unfortunately, it breaks
the SenderID spec by using the wrong records. (Breaking the SenderID
spec means that you can't get a license from MS for their patents over
SenderID. Sendmail is currently ignoring this because the patents
haven't been issued yet.)


So, no, you can't publish either CallerID records or SPF records. You
can publish SPF-classic records, which are the most widely used. You
can publish CallerID records, which only a very few sytems use. Or,
you can publish SenderID records, which almost no one uses.


> From the receiving MTA perspective, a lot of open source types have
> said they will only support the SPF half, due to concerns about IP
> restrictions around caller ID. This is fine if all the sending
> domains publish records for either SPF or both mechanisms in their
> DNS.

Yep


> From what I can see out there in the world, the majority of the big
> guns have SPF only, e.g. AOL - execept for Microsoft, who have only
> Caller ID records in their DNS.

Right. And MS has abandoned CallerID and its actions speak loudly
about its lack of commitment to SenderID.


> *What I want to know is, from an inbound perspective, does Hotmail
> (and other MS ISP properties) currently implement /Caller ID/ or do
> they implement /Sender ID/, i.e. will Hotmail look at an SPF record
> if there is no Caller ID one?*

I do not believe that any MS domain ever implemented any designated
sender system, either CallerID, SPF, or SenderID. I personally think
that it is very unlikely that Hotmail will implement any system within
the next year or two, maybe much longer. Remember, Hotmail doesn't
even do simple checks such as making sure the sending domain exists.
Such DNS looks are "too expensive", or that's what I've been told that
hotmail folks have said.

The folks from MS that have been involved in the CallerID and
SenderID proposals have all been from the MS Exchange group and the MS
PR group (with a little involvement from the MS Lawyer group.) The
Hotmail folks have been *very* quiet. MS is a big company, I'm sure
that it is hard to get everyone going in the same direction.


> If not, then as far as I see it the SPF / Sender ID effort is still in
> full schism, with Microsoft using only their proposed proprietary
> standard, and the rest of the world using SPF.

Yes, there is a schism, but it is only sendmail that is using MS's
proprietary standard. Even sendmail's milter implements "SPF-classic",
although it appears that they don't implement any of the SPF-classic
specs, but rather SenderID with the MAIL FROM. There were several
incompatible changes made when SPF was evolved into SenderID, so I
would not trust this milter to correctly implement SPF-classic.


> Recent advice from the Direct Marketing Association (DMA) was to
> implement "all three" - Caller ID, SPF and Domain Keys, which makes me
> suspect it is not current with the technology - is Yahoo! actually
> doing anything about Domain Keys any more, I thought they had decided
> to back SPF? They don't currently have SPF or Caller ID published.

It appears to me that the Yahoo (and sendmail) folks are very actively
trying to create a solid DomainKeys system. However, it appears that
it is still being worked on and there is no stable standard yet.

I think DomainKeys is an interesting idea, but it has a few critical
problems with it that make it not work very well right now. I hope
they can get it to work.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Sat, 23 Oct 2004 13:43:04 -0500, wayne <wayne@midwestcs.com> wrote:
> In <417A7FC9.3020304@convio.com> David Crooke <dave@convio.com> writes:
>
> > We're (among other things) an email marketing provider, and getting
> > close to taking the plunge with our clients and having them create SPF
> > records.
>
> Cool!
>
>
> > He're a practical question:
> >
> > Meng has been working to get Microsoft on board and came up with the
> > hybrid standard labelled "Sender ID", which if you follow it to the
> > letter says that you (as a mail sender) can publish either Caller ID
> > or SPF, and Caller ID takes precedence if you have both, because the
> > receiving MTA should perform the DNS lookup for Caller ID first.
>
> There are a lot of misconceptions in this paragraph, which really
> isn't too surprising considering how messy the whole business has
> been.
>
> SPF is a system that has been evolving since last summer. Rapid
> changes to the standard stopped early last winter, but it has still
> been slowly evolving since. There is a move underway right now to
> solidify this standard as "SPF-Classic".
>
> SPF-Classic is by far the most widely deployed anti-forgery system
> (aka designated sender system) in the world, easily outnumber all
> other systems combined.
>
> Much more radical changes to SPF have been proposed by several people,
> including Meng, and are being debated. These proposals have gone by
> the names of "Unified-SPF" and "SPFv2" and a few others.
>
> Since the Unified-SPF/SPFv2 spec is still very much in flux, I can't
> recommend committing to it unless you are willing to be actively
> involved in its development.
>
> CallerID was Microsoft's original proposal for a designated sender
> system. From what I can tell, it has been abandoned, and the
> Caller-ID records published under Microsoft.com, and hotmail.com.
> (but, not msn.com!)
>
> SenderID was the proposed merger of SPF and CallerID that was
> developed during the IETF's MARID working group's life. A final spec
> was never delivered before the working group was shut down. The spec
> was about 90% SPF and 10% CallerID, and many have argued, including
> Meng, that most of the 10% from CallerID is badly broken.
>
> As evidence to just how committed Microsoft is to the SenderID spec,
> note that they haven't published SenderID records for microsoft.com
> nor hotmail.com. If they did publish records, they would likely use
> their SenderID Wizard, which creates invalid records. Yes, Microsoft
> knows that their wizard is publishing broken records, but say that
> because they outsourced the job to India, they can't easily change
> it.
>
> There is only one system out there that I know of that implements
> SenderID, and that's sendmail's SID-milter. Unfortunately, it breaks
> the SenderID spec by using the wrong records. (Breaking the SenderID
> spec means that you can't get a license from MS for their patents over
> SenderID. Sendmail is currently ignoring this because the patents
> haven't been issued yet.)
>
> So, no, you can't publish either CallerID records or SPF records. You
> can publish SPF-classic records, which are the most widely used. You
> can publish CallerID records, which only a very few sytems use. Or,
> you can publish SenderID records, which almost no one uses.
>
>
> > From the receiving MTA perspective, a lot of open source types have
> > said they will only support the SPF half, due to concerns about IP
> > restrictions around caller ID. This is fine if all the sending
> > domains publish records for either SPF or both mechanisms in their
> > DNS.
>
> Yep
>
>
> > From what I can see out there in the world, the majority of the big
> > guns have SPF only, e.g. AOL - execept for Microsoft, who have only
> > Caller ID records in their DNS.
>
> Right. And MS has abandoned CallerID and its actions speak loudly
> about its lack of commitment to SenderID.
>
> > *What I want to know is, from an inbound perspective, does Hotmail
> > (and other MS ISP properties) currently implement /Caller ID/ or do
> > they implement /Sender ID/, i.e. will Hotmail look at an SPF record
> > if there is no Caller ID one?*
>
> I do not believe that any MS domain ever implemented any designated
> sender system, either CallerID, SPF, or SenderID. I personally think
> that it is very unlikely that Hotmail will implement any system within
> the next year or two, maybe much longer. Remember, Hotmail doesn't
> even do simple checks such as making sure the sending domain exists.
> Such DNS looks are "too expensive", or that's what I've been told that
> hotmail folks have said.
>
> The folks from MS that have been involved in the CallerID and
> SenderID proposals have all been from the MS Exchange group and the MS
> PR group (with a little involvement from the MS Lawyer group.) The
> Hotmail folks have been *very* quiet. MS is a big company, I'm sure
> that it is hard to get everyone going in the same direction.
>
>
> > If not, then as far as I see it the SPF / Sender ID effort is still in
> > full schism, with Microsoft using only their proposed proprietary
> > standard, and the rest of the world using SPF.
>
> Yes, there is a schism, but it is only sendmail that is using MS's
> proprietary standard. Even sendmail's milter implements "SPF-classic",
> although it appears that they don't implement any of the SPF-classic
> specs, but rather SenderID with the MAIL FROM. There were several
> incompatible changes made when SPF was evolved into SenderID, so I
> would not trust this milter to correctly implement SPF-classic.
>
>
> > Recent advice from the Direct Marketing Association (DMA) was to
> > implement "all three" - Caller ID, SPF and Domain Keys, which makes me
> > suspect it is not current with the technology - is Yahoo! actually
> > doing anything about Domain Keys any more, I thought they had decided
> > to back SPF? They don't currently have SPF or Caller ID published.
>
> It appears to me that the Yahoo (and sendmail) folks are very actively
> trying to create a solid DomainKeys system. However, it appears that
> it is still being worked on and there is no stable standard yet.
>
> I think DomainKeys is an interesting idea, but it has a few critical
> problems with it that make it not work very well right now. I hope
> they can get it to work.
>
>
> -wayne
>

Excellent synopsis. Can you talk about the DomainKeys critical problems?

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

In <e87cc0c004102314073927cf7c@mail.gmail.com> Ron Schnell <schnell@gmail.com> writes:

>
> Excellent synopsis. Can you talk about the DomainKeys critical problems?

I posted this message to slashdot on this subject:
http://slashdot.org/comments.pl?sid=126043&cid=10553862&mode=thread&commentsort=3

This was in response to the story "Gmail Begins Signing Email with
DomainKeys"
http://it.slashdot.org/article.pl?sid=04/10/18/0236201&tid=111&mode=thread&commentsort=3


Russ Nelson, who knows a lot about DomainKeys, posted a reply,
addressing some of these concerns. I see some obvious problems with
some of his suggestions. For example, he suggested that ever use
could (should?) be given a separate domainkey and to terminate that
key if it appears to be involved with spamming. Unfotunately, DNS
caching will cause that key to stick around for along time for many
clients and it also opens the door for anyone to get anyone elses
account terminated just by looking up the users domainkey too many
times.


As I said at the top of that slashdot post, I am *not* an expert on
Domainkeys. I would love to be proven wrong. If DK can be made to
work, I think it would complement SPF very well.


-wayne


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

On Sat, 23 Oct 2004, wayne wrote:

> There is only one system out there that I know of that implements
> SenderID, and that's sendmail's SID-milter. Unfortunately, it breaks
> the SenderID spec by using the wrong records.

I'm unaware of the code using the wrong records. We've had several people
deploy it successfully and there is an active list on the sourceforge
site. If you have more information could you please forward it to
sid-milter-discuss@lists.sourceforge.net

> Yes, there is a schism, but it is only sendmail that is using MS's
> proprietary standard. Even sendmail's milter implements "SPF-classic",
> although it appears that they don't implement any of the SPF-classic
> specs, but rather SenderID with the MAIL FROM. There were several
> incompatible changes made when SPF was evolved into SenderID, so I
> would not trust this milter to correctly implement SPF-classic.

Now that there's a new draft submitted for "SPF Classic", we're looking
to implement that as well:

http://ietf.org/internet-drafts/draft-lentczner-spf-00.txt

(I hope that's the right one...it's hard to know which are officially
sanctioned and which aren't).

There's a lot of specs flying around and we've been trying to work with a
number of them (SPF, Sender ID, DomainKeys), so the fluidity of the whole
situation leads to lags.

> It appears to me that the Yahoo (and sendmail) folks are very actively
> trying to create a solid DomainKeys system. However, it appears that
> it is still being worked on and there is no stable standard yet.

I don't know what "stable" means but Mark D. has submitted a -01 I-D that
is under discussion on the ietf-mailsig list and other places. I'd say
that all of the specs are in about the same place when it comes to
"stability".

-Rand

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

In <Pine.LNX.4.58.0410251526410.21617@snoopy.smi.sendmail.com> Rand Wacker <rand@sendmail.com> writes:

> On Sat, 23 Oct 2004, wayne wrote:
>
>> There is only one system out there that I know of that implements
>> SenderID, and that's sendmail's SID-milter. Unfortunately, it breaks
>> the SenderID spec by using the wrong records.
>
> I'm unaware of the code using the wrong records.

Well, ever since you first released it, your milter has used both
v=spf1 records and spf2.0/pra records. The MARID SenderID specs said
that you are supposed to use only the latter.


>> proprietary standard. Even sendmail's milter implements "SPF-classic",
>> although it appears that they don't implement any of the SPF-classic
>> specs, but rather SenderID with the MAIL FROM. There were several
>> incompatible changes made when SPF was evolved into SenderID, so I
>> would not trust this milter to correctly implement SPF-classic.
>
> Now that there's a new draft submitted for "SPF Classic", we're looking
> to implement that as well:
>
> http://ietf.org/internet-drafts/draft-lentczner-spf-00.txt
>
> (I hope that's the right one...it's hard to know which are officially
> sanctioned and which aren't).

That is the newest official SPF-classic spec, just released about two
weeks ago.


> There's a lot of specs flying around and we've been trying to work with a
> number of them (SPF, Sender ID, DomainKeys), so the fluidity of the whole
> situation leads to lags.

The spf-draft-200406 spec has been static for the last 5 months. Up
until the new SPF-classic spec mentioned above, the SPF-classic spec
has been pretty stable since last December.


>> It appears to me that the Yahoo (and sendmail) folks are very actively
>> trying to create a solid DomainKeys system. However, it appears that
>> it is still being worked on and there is no stable standard yet.
>
> I don't know what "stable" means but Mark D. has submitted a -01 I-D that
> is under discussion on the ietf-mailsig list and other places. I'd say
> that all of the specs are in about the same place when it comes to
> "stability".

Well, by "stable", I mean unchanged and in production use for a many
months. Yeah, you are right, SPF-classic isn't table anymore.


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

> As evidence to just how committed Microsoft is to the
> SenderID spec,
> note that they haven't published SenderID records for microsoft.com
> nor hotmail.com. If they did publish records, they would
> likely use
> their SenderID Wizard, which creates invalid records. Yes,
> Microsoft
> knows that their wizard is publishing broken records, but say that
> because they outsourced the job to India, they can't easily
> change it.

This news just in, from today's Edupage:

--
MICROSOFT REVIVES SENDER ID
Microsoft has breathed new life into its Sender ID technology, which is
designed to help Internet service providers (ISPs) filter junk e-mail,
after criticism of the technology and rejection by a standards body left
Sender ID foundering. Sender ID represented the merger of Microsoft's
development efforts and a somewhat different antispam protocol called
Sender Policy Framework, both of which endeavor to identify spam by
exposing fraudulent return addresses in e-mail. The technology community
was not receptive to Sender ID, however, because it was based on
proprietary Microsoft technology. Furthermore, the standard was not
accepted by the Internet Engineering Task Force (IETF). Microsoft has
made changes to the technology and narrowed the scope of its patent
application in an effort to persuade ISPs to use the protocol, and at
least one, America Online, has decided to begin testing Sender ID after
having dropped it last month. In addition, Microsoft will resubmit
Sender ID to the IETF. Reuters, 25 October 2004
http://www.reuters.com/newsArticle.jhtml?storyID=6601973
--

-- Paul

-------------------------------------------------
WinBiff 4.5, now supports SSL/TLS for security.
Download your copy from http://www.stecksoft.com.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com

In <001201c4bb0c$36666b60$02c8a8c0@blimpy> "Paul A. Steckler" <steck@stecksoft.com> writes:

>> As evidence to just how committed Microsoft is to the SenderID
>> spec, note that they haven't published SenderID records for
>> microsoft.com nor hotmail.com. If they did publish records, they
>> would likely use their SenderID Wizard, which creates invalid
>> records. Yes, Microsoft knows that their wizard is publishing
>> broken records, but say that because they outsourced the job to
>> India, they can't easily change it.
>
> This news just in, from today's Edupage:
>
> --
> MICROSOFT REVIVES SENDER ID

Yes, I mentioned that stories similar to this earlier today on
SPF-discuss.

At the time of my posting this note, Microsoft still hasn't created
SPF records for hotmail.com and microsoft.com and their SPF creation
wizard is still broken.

There have been similar press releases in the past that have resulted
in a similar lack of action. Of course, past results don't always
predict the future, but....


-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-deployment@v2.listbox.com