spf-discuss
[Top] [All Lists]

Re: possibilities for 2822 (was SPF implementations)

2005-08-18 05:23:55
johnp wrote:


Scott Kitterman wrote:

-----Original Message-----
From: Seth Goodman [mailto:sethg(_at_)GoodmanAssociates(_dot_)com]
Sent: Thursday, August 18, 2005 12:04 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] possibilities for 2822 (was SPF
implementations)



From: Scott Kitterman [mailto:spf2(_at_)kitterman(_dot_)com]
Sent: Wednesday, August 17, 2005 10:38 PM


Now what I was trying to suggest was something much simpler than many of
these options.

Give domain owners who do not want their 2822-From: (or 2822-Sender:
perhaps) used with someone else's 2821-Mail From:.

Domains that want to impose this restriction add from=yes to their SPF
record.


Any domain that opts in to this gives up the ability to participate in
mailing lists.  That is a heavy price to pay.  If you make it From: _or_
Sender:, when it exists, you still get what you want while allowing those
domains to post to mailing lists.


I agree (it was on purpose). Maybe we have some options (now it gets more
complex unfortunately).

Maybe instead of just from=yes, there is also an option for from=sender if you want to open it up a bit. I wasn't particularly looking for a modifier that would be of much use for typical sending domains. What I was looking for was a modifier that would give commonly phished domains a way to close down tight. I expect that this sort of modifier would have value for only a
few senders, but for virtually all receivers.

My goal is to extend the current Mail From protection provided by SPF to a
limited protection for high value Froms.  Thus rudimentary anti-phishing
tool would increase the incentive for receivers to check SPF. It would be
simple enough with from=sender to include sender also if one wanted to.
This would make it more generally useful for senders.


As a domain owner publishing a record - would there be any advatage in being able to specify the various headers I would like to be checked, by using something like "v=spf1 a mx -From -Sender -all" and include other headers that we decide are appropriate? the example record here would look at HELO and 2821 and if fail, it would look at From and Sender headers in the way Seth and others are discussing. This give domain owners the opportunity to opt-in to 2822 if they want and for as much as they want, while retaining the original concept of spf being 2821 only.

I agree with William that my idea on spfhelp.net is not "the same" but the concept of using spf to check 2822 is by no means new. I put the concept on the webpage in the hope of provoking discussion, it was never intended as a complete solution.

Perhaps an even more complex/complete approach has more value. I'm not sure. The problem is that once you start to assess the multiple 2822 identities you need a priority and a sequence and then it's hard to see that you aren't a variant of SID.

None of this is a new idea, but I think it's time to revisit.

My view is that we ought to do the least slightest thing we can that will do something significant and not try and open the entire IP based 2822 solution can of worms again.

If we gave domain owners a modifier to allow them to assert a limited acceptable use of their domain in 2822-From, then it would be possible to leverage the current SPF protocol into a first stage anti-phishing defense.

We are going to be coming up with more ideas as we go, but we should keep each one separate and distinct.

As things evolve, I see 2821 methods being a gatekeeper of sorts. 2821 is the domain of the MTA and the first arena in which checks can be done. I could even imagine adding modifiers later (it's premature to discuss now, I think) that refer to 2822 methods. One might add a modifier (this is not a new idea to me either - someone else thought of this first) pointing towards a DKIM SSP (that's the DKIM policy record). That would amount to a request from the domain owner to go into Data even if SPF fails because they are promising additional information in Data that might over-ride an SPF Fail. But that's for a later discussion.

So, I think a series of small steps are in order. From= would be a good first one.

Scott K