Re: possibilities for 2822 (was SPF implementations)
2005-08-18 00:54:12
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.
Slainte,
JohnP
<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
|
|
|