Mailing List Archive: SPF: Deployment

RE: Practical guidance for ESP's (SPF renamed to SenderID?)

Index | Next | Previous | View Threaded

jeremyp at gfi

Oct 26, 2004, 12:57 AM

Post #1 of 8 (5102 views)
Permalink

RE: Practical guidance for ESP's (SPF renamed to SenderID?)

The page: http://spf.pobox.com/esps.html talks about SenderID instead of
SPF.

I understand that technically SPF and SenderID are practically the same
thing and that now Microsoft has removed patents, making SenderID
acceptable to companies such as AOL who have already announced renewed
support for it.

The time has (finally) come for us to accept that SPF and SenderID were,
are and will be the exact same thing.

<flameproofjacketon/>

Jeremy Pullicino
Software Engineer

-----Original Message-----
From: owner-spf-deployment [at] v2
[mailto:owner-spf-deployment [at] v2] On Behalf Of Meng Weng Wong
Sent: Tuesday, October 26, 2004 12:39 AM
To: spf-deployment [at] v2
Subject: Re: [spf-deployment] Practical guidance for ESP's

On Mon, Oct 25, 2004 at 06:31:40PM -0500, David Crooke wrote:
|
| I hope I haven't started too big of a food fight with my last question
:-)
|
| Here goes with the underlying concern, and I'd be interested in a
| pragmatic, objective answer rather than bleeding edge or one that is
| partisan to one standard or another.....

My web page of advice to ESPs is online at
http://spf.pobox.com/esps.html

I'd be happy to take feedback and make any changes
necessary. I will also address "what should ESPs do" in my
forthcoming whitepaper which will be officially released at
the MAAWG meeting November 2-3: http://www.maawg.org/

| 1. As an ESP (email marketing service provider), serving clients with
a
| wide range of technical skill levels, what should we be doing right
now?
|
| a. Continue to sit tight and wait for the SPF / Sender-ID dust to
settle
| some more**
| b. Attempt to have individual customers roll out individual SPF
records
| for each of their domains, as used in "From:" body headers
| c. Roll out a single SPF record for our bounce handler sending domain,

| as used in the "MAIL FROM:" SMTP command

definitely do this.

| d. Have our email software create an additional "purported responsible

| sender" header and add it to all outbound mail

this is probably a good idea too.

| 2. For option d. above, should we configure these for each client, or
| just use one "convio.net" sender?

either way works.

| Side question: what is the best place to look for
| documentation on how the "sender" address is calculated? I
| understand that the algorithms for SPF-Classic, Caller-ID,
| Sender-ID, SPF 2 all differ subtly.

the specs will make their way online soon. i'll follow up
again when they have a stable URL.

| 3. For whichever of the options is recommended for question 1., which
| DNS record types should we publish:
|
| a. v=spf1
| b. SPF 2.0
| c. "Caller ID style", i.e. _ep.foo.org with XML data
| d. Some combination of the above

(a) only --- all software reading the PRA will read v=spf1.

you can use spf2.0/pra as an override iff the information
for a domain when read in PRA context differs from the
information when read in mail-from context.

i should probably give some examples. but i'm working full
steam on the white paper and i'll all the examples in there :)

| 4. Applying question 1. to "tell a friend about this website"
| functionality, where we are generating email with "From:" addresses
from
| all over the internet, option b. is not applicable ... should we do c.

| or d. or should we even consider not putting the user's address in the

| From: and using within a client's domain?

you can either set Sender: to be yourself, or change the
From: to be yourself and put the user's address in the Reply-To.

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

This mail was checked for malicious code and viruses
by GFI MailSecurity. GFI MailSecurity provides email content
checking, exploit detection, threats analysis and anti-virus for
Exchange & SMTP servers. Viruses, Trojans, dangerous
attachments and offensive content are removed automatically.
Key features include: multiple virus engines; email content and
attachment checking; an exploit shield; an HTML threats engine;
a Trojan & Executable Scanner; and more.

In addition to GFI MailSecurity, GFI also produces the
GFI MailEssentials anti-spam software, the GFI FAXmaker
fax server & GFI LANguard network security product ranges.
For more information on our products, please visit
http://www.gfi.com. This disclaimer was sent by
GFI MailEssentials for Exchange/SMTP.

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

jbglube at sympatico

Oct 26, 2004, 2:47 AM

Post #2 of 8 (4841 views)
Permalink

RE: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

From: Jeremy Pullicino Sent: October 26, 2004 3:57 AM

<snip>

|I understand that technically SPF and SenderID are
|practically the same thing and that now Microsoft has
|removed patents, making SenderID acceptable to companies
|such as AOL who have already announced renewed support for
|it.

<snip>

As to your technical conclusion, quoting from
draft-lyon-senderid-core, the authors, Messrs. Lyon and Wong
write:

|This document defines a pair of closely-related tests. One
|validates a message's Purported Responsible Address (PRA)
|as defined in [PRA]. The other validates a message's
|Reverse-Path (also known as MAIL-FROM address) as defined
|in [SPF].
|
|An e-mail sender SHOULD publish information for both tests,
|and SHOULD arrange that any mail that is sent will pass
|both tests.

[.Section 1, Introduction - page 2 of Sender ID:
Authenticating Email]

The authors go on to write:

|The PRA version of the test seeks to authenticate the
|mailbox associated with the most recent introduction of a
|message into the mail delivery system. In simple cases,
|this is who the mail is from. However, in the case of a
|third-party mailer, a forwarder or a mailing list server,
|the address being authenticated is that of the third party,
|the forwarder or the mailing list.
|
|On the other hand, the MAIL-FROM version of the test seeks
|to authenticate the mailbox that would receive Delivery
|Status Notifications (DSNs, or bounces) for the message. In
|simple cases, this too is who the mail is from. However,
|third-party mailers, forwarders and mailing list servers
|MUST specify an address under their control, and SHOULD
|arrange that DSNs received at this address are forwarded to
|the original bounce address.

[.Section 2, Problem Statement - page 3 of Sender ID:
Authenticating Email]

http://www.spfhelp.com/downloads/draft-lyon-senderid-core-00.txt

I agree conceptually the approaches for PRA and MAIL FROM
authentication are similar.

However, the test for the check host function involves
authenticating different identities. This can give rise to
different results depending on how a sender has arranged
his, her or its affairs.

On this point, see the following on backward compatibility
in the proposal:

|Administrators who have already published "v=spf1" records
|SHOULD review these records to determine whether they are
|also valid for use with PRA checks. If the information in a
|"v=spf1" record is not correct for a PRA check,
|administrators SHOULD publish either an "spf2.0/pra" record
|with correct information, or an "spf2.0/pra ?all" record
|indicating that the result of a PRA chek is explicitly
|inconclusive.

[.Section 3.4, Backward Compatibility - page 6 of Sender ID:
Authenticating Email]

http://www.spfhelp.com/downloads/draft-lyon-senderid-core-00.txt

On the patent issue, I quote from an article published in
CNET news:

|Among other changes, Microsoft removed language in its
|pending patents for Sender ID that could have included
|claims to Sender Permitted From, or SPF, a widely used
|system for email authentication that was merged with
|Microsoft's CallerID for Email to create Sender ID,
|according to Microsoft's Ryan Hamlin.

http://news.zdnet.co.uk/internet/security/0,39020375,39171356,00.
htm

However, MS has not withdrawn its patent claim on the
concept of PRA operating in combination with CORE, which
forms the basis for the technology being licensed under
Microsoft's Royalty Free License which is not compatible
with the Open Standard Alliance model.

John

John Glube
Toronto, Canada

The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.779 / Virus Database: 526 - Release Date: 19/10/2004

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

mengwong at dumbo

Oct 26, 2004, 6:52 AM

Post #3 of 8 (4818 views)
Permalink

Re: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

On Tue, Oct 26, 2004 at 05:47:01AM -0400, John Glube wrote:
|
| However, MS has not withdrawn its patent claim on the
| concept of PRA operating in combination with CORE, which
| forms the basis for the technology being licensed under
| Microsoft's Royalty Free License which is not compatible
| with the Open Standard Alliance model.

Yes, this is correct. This seems like a novel situation,
though. Now there are essentially two halves to Sender
ID. As a receiver you can leave the PRA half untouched if
you don't like the patent situation, and implement SPF
Classic; as a sender you need to be careful your records
will work for both.

Is this state of affairs sufficiently satisfactory for the
industry as a whole to move forward?

I acknowledge that there are certain members of the
community who feel very strongly that as long as any part of
the spec is patent-encumbered, the entire thing should not
be allowed to proceed.

But in practice, Sender ID is being defined as a family of
drafts anyway; and it breaks down like this:

Lentczner's SPF Classic spec defining the protocol
+ the PRA spec
+ the new "Sender ID" core spec extending the protocol to PRA

So people who object to the PRA/Sender ID stuff can still go
ahead with the SPF Classic, which is what they would have
done anyway if the PRA stuff had never come along in the
first place.

Unless, of course, they are so disgusted by the whole thing
that they abandon SPF Classic as well. But that seems a
little bit like cutting off your nose to spite somebody
else's face.

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

spf2 at kitterman

Oct 26, 2004, 7:06 AM

Post #4 of 8 (4822 views)
Permalink

RE: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

>-----Original Message-----
>From: owner-spf-deployment [at] v2
>[mailto:owner-spf-deployment [at] v2]On Behalf Of Meng Weng Wong
>Sent: Tuesday, October 26, 2004 9:52 AM
>To: spf-deployment [at] v2
>Subject: Re: [spf-deployment] Practical guidance for ESP's (SPF renamed
>to SenderID?)
>
>
>On Tue, Oct 26, 2004 at 05:47:01AM -0400, John Glube wrote:
>|
>| However, MS has not withdrawn its patent claim on the
>| concept of PRA operating in combination with CORE, which
>| forms the basis for the technology being licensed under
>| Microsoft's Royalty Free License which is not compatible
>| with the Open Standard Alliance model.
>
>Yes, this is correct. This seems like a novel situation,
>though. Now there are essentially two halves to Sender
>ID. As a receiver you can leave the PRA half untouched if
>you don't like the patent situation, and implement SPF
>Classic; as a sender you need to be careful your records
>will work for both.
>
>Is this state of affairs sufficiently satisfactory for the
>industry as a whole to move forward?

For myself, I would find it acceptable if there were an unburdened
alternative for 2822 (or at least a placeholder for it as a scope). Leave
it to the market to decide only works if there is a real choice. Currently,
if one wants to work with the 2822 header, there is no choice, only PRA. If
there were room for a free alternative in the same domain, then I think a
lot more people would be ready to move on.

Scott Kitterman

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

wayne at midwestcs

Oct 26, 2004, 7:21 AM

Post #5 of 8 (4813 views)
Permalink

Re: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

In <20041026135228.GI6162 [at] dumbo> Meng Weng Wong <mengwong [at] dumbo> writes:

> On Tue, Oct 26, 2004 at 05:47:01AM -0400, John Glube wrote:
> |
> | However, MS has not withdrawn its patent claim on the
> | concept of PRA operating in combination with CORE, which
> | forms the basis for the technology being licensed under
> | Microsoft's Royalty Free License which is not compatible
> | with the Open Standard Alliance model.
>
> Yes, this is correct. This seems like a novel situation,
> though. Now there are essentially two halves to Sender
> ID. As a receiver you can leave the PRA half untouched if
> you don't like the patent situation, and implement SPF
> Classic; as a sender you need to be careful your records
> will work for both.
>
> Is this state of affairs sufficiently satisfactory for the
> industry as a whole to move forward?

This is the situation as the last drafts of SenderID before the IETF
shut the MARID working group down. This is not new. The response to
this direction was underwhelming and was, in part, why the IETF shut
down MARID.

If it didn't get the necessary support last time, why do you think it
will this time?

I have *long* said that:

1) The PRA patent license is a deal killer and can not be accepted.

The Microsoft license prevents most mail servers on the internet
from easily deploying SenderID. This creates a wedge issue where
Microsoft can use its monopoly as granted by its patent to try and
take over the MTA market. I hate markets that aren't free.

2) The PRA is untested, in theory doesn't work well, and what little
practical experience has been gained so far shows that theory
matches practice.

This, however, is something I think the market will be able to deal
with. There is something called "reality" that won't go away, even
when a very powerful company says something that conflicts with it.

Now the thing that really puzzles me Meng is that just yesterday you
told me that you do *not* support the PRA. That you think the PRA is
a terrible idea. And yet, I see you advocating that domain owners
support the PRA. Why are you telling others to do something that you
don't support and thing is terrible?

-wayne

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

mengwong at dumbo

Oct 26, 2004, 7:30 AM

Post #6 of 8 (4811 views)
Permalink

Re: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

On Tue, Oct 26, 2004 at 09:21:37AM -0500, wayne wrote:
|
| Now the thing that really puzzles me Meng is that just yesterday you
| told me that you do *not* support the PRA. That you think the PRA is
| a terrible idea. And yet, I see you advocating that domain owners
| support the PRA. Why are you telling others to do something that you
| don't support and thing is terrible?

One-button mice are a terrible idea too, but they're part of
the environment, and if we're to be realistic, then we need
to react to them whether we like them or not. I'm not
advocating that domain owners support the PRA: domain owners
are asking what they'll need to do about the PRA, and I'm
telling them how to deal with it.

You can pretend that something you don't like doesn't exist,
you can deal with it, or you can fight it. I'm not going to
fight Microsoft on this one; it's something they want very
much to do and from where I stand it looks like they're
going to do it no matter who fights them on it.

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

mengwong at dumbo

Oct 26, 2004, 7:32 AM

Post #7 of 8 (4821 views)
Permalink

Re: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

On Tue, Oct 26, 2004 at 10:30:34AM -0400, Meng Weng Wong wrote:
|
| One-button mice are a terrible idea too, but they're part of
| the environment, and if we're to be realistic, then we need
| to react to them whether we like them or not. I'm not
| advocating that domain owners support the PRA: domain owners
| are asking what they'll need to do about the PRA, and I'm
| telling them how to deal with it.

BTW, under Mac OS, if you have a one-button mouse, to get
the equivalent of a right click, you have to either
control-click, or hold down the button for a second or two.
Or you can go out and buy a three-button mouse from a third
party vendor.

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

nobody at xyzzy

Oct 27, 2004, 4:02 PM

Post #8 of 8 (4823 views)
Permalink

Re: Practical guidance for ESP's (SPF renamed to SenderID?) [In reply to]

Jeremy Pullicino wrote:

> I understand that technically SPF and SenderID are
> practically the same

That's not the case, they are very different. Sender-ID
tries a hostile takeover, but it will fail, like MARID.

> The time has (finally) come for us to accept that SPF and
> SenderID were, are and will be the exact same thing.

If you have the time to support unhappy users losing their
inbound mail and threatening to sue you, go ahead and apply
PRA tests on v=spf1 policies. If you don't have this time
just wait until it hits the fan. If some of your users use
"their" 2822-From anywhere, not only in mails sent via your
relays, this won't take long.
Bye, Frank

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads