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
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: possibilities for 2822 (was SPF implementations), (continued)
- Re: possibilities for 2822 (was SPF implementations), Chris Haynes
- RE: possibilities for 2822 (was SPF implementations), Scott Kitterman
- Re: possibilities for 2822 (was SPF implementations), johnp
- Re: possibilities for 2822 (was SPF implementations),
Scott Kitterman <=
- No more xxxx=yes please (was: possibilities for 2822), Frank Ellermann
- RE: No more xxxx=yes please (was: possibilities for 2822), Scott Kitterman
- RE: No more xxxx=yes please (was: possibilities for 2822), Seth Goodman
- Re: No more xxxx=yes please, Frank Ellermann
- RE: Re: No more xxxx=yes please, Scott Kitterman
- RE: Re: No more xxxx=yes please, william(at)elan.net
- RE: Re: No more xxxx=yes please, Seth Goodman
- Re: No more xxxx=yes please, Frank Ellermann
- Re: possibilities for 2822, Frank Ellermann
- Re: possibilities for 2822 (was SPF implementations), Dick St.Peters
|
|
|