-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Meng
Weng Wong
Sent: Thursday, June 24, 2004 10:40 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Possible New Mechanism Prefix
On Thu, Jun 24, 2004 at 10:33:10AM -0400, spf(_at_)kitterman(_dot_)com wrote:
|
| verizon.net. 86400 TXT "v=spf1 ip4:206.46.170.0/24
ip4:206.46.128.33
| ip4:206.46.128.101 ip4:209.84.13.21 ip4:209.84.13.20 ?all"
|
| I will have include:verizon.net in my spf record.
|
| Now, anyone who is also a Verizon customer can successfully
forge my domain
| and get an SPF pass.
They don't do SMTP AUTH? Shocking! If they did, they would
know exactly who was doing the forging, and you could sue them.
Yes, they do SMTP AUTH, so you are right. My concern is someone sees an SPF
pass on spam mail from my domain, and based on that reports me to {insert
your favorite RBL here} and then suddenly my domain is blackholed and my
mail doesn't get through.
This is my biggest fear with SPF. Suing them is great, but only after the
fact. I'd much rather not get RBLed in the first place.
The initial design assumption was that having a paper trail
within a single organization was a "good enough" first step
to deter basic return-path forgery.
I think that's a good assumption. I guess I'm afraid that as SPF spreads,
people will take a pass to mean more than it can in the current design. SPF
pass != the mail wasn't forged. In other words, SPF can state that mail was
forged if someone publishes a -all record. The most SPF can currently say
positively is that the message came from a permitted MTA.
| It seems to me that there is another level better than pass
that we might
| want to assert. Pass means the sender is permitted.
"Authoritative Pass"
| (my term for the next level) would mean that the MTA is
permitted and the
| domain owner will take responsibility for any e-mails from that
MTA, because
| only authorized domain users can send e-mail from that MTA.
|
| This "Authoritative Pass" would be used by individuals and organizations
| that run their own MTAs. People like me who rely on shared
infrastructure
| would use the current pass.
|
| I think this would be a win/win.
| Entities that control their own MTA would get a way to assert
an even higher
| confidence level that could be used to inform receiver policies.
|
| Entities using a shared MTA would be less likely to be disadvantaged by
| receivers trying to hold them accountable for messages they didn't send.
I am not clear about what the functional difference is
between an authoritative pass and the regular pass.
The functional difference would be a regular pass means the MTA is permitted
(a strong indication that it's not a forgery), while authoritative pass
woule mean that the MTA can only be used by authorized senders for the
domain (the message is not a forgery).
Maybe you want to do v=spf1 +mymta ?include:verizon.net -all
Yes, I'm thinking of changing my record to add the ? in from of all the
mechanisms. My suggestion here is to add a level of nuance so that those of
us reliant on shared MTAs can assert something beyond neutral without fear.
Also, based on the current definitions, +include:verizon.net is technically
correct since they are a permitted sender. I think there is benifit to
letting people running their own MTAs assert something stronger than just
permitted sender. I think it will also seriously reduce the risk that
someone using shared MTA resources will get burned.
| Of course, many groups will use a mix of the two.
|
| The more I look into how e-mail gets sent from my domain, the
more nervous I
| get about trying to fully describe it in an SPF record. Did
you know that
| when you mail an article from the CNN web site it comes from
"Received: from
| localhost (HELO relay.clickability.com)"?
what do they use for the return-path?
The e-mail address that you entered in the form. This is actually a whole
'nother area that I think needs more attention. It's not just greeting
cards...
Scott K