spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Re: Election issue: forwarding problem

2007-02-05 11:13:29
Scott Kitterman wrote on Monday, February 05, 2007 12:04 AM -0600:

The tricky part about this is not the technical aspects, but the
administrative/procedural part.  If you have a legacy userbase of
thousands/millions how to you go back and validate which mail from
identities they should be using.  This is a non-trivial problem.

That's true in the general case of users with arbitrary outbound
addresses that have no correspondence to their incoming addresses.  It's
also true for the case that Peter mentions where the underlying
architecture is unfriendly to authentication.  For the most important
case, where inbound and outbound addresses are the same, the solution is
reasonable, as Frank suggests.  It still doesn't address some users'
desire to submit mail with an identity they control on another network
that doesn't support authenticated submission.  The problem is at
another service you can't control, so it's another chicken vs. egg
situation.

Moreover, what is the problem we are trying to fix?  Services have
little interest in preventing their users from forging domains belonging
to someone else.  SPF checking on incoming is in the recipient's
interest, which is why they _may_ eventually do it.  Outbound SPF
checking is highly responsible, but not particularly in the sender's
interest.  It's similar to outbound virus filtering and rate limiting,
except that the best practice of outbound authentication makes it
redundant.  If you want to say it's better than doing nothing, I'd
agree.



For an MSA that has implemented appropriate technical restrictions, I
agree that the prospective SPF check is largely redundant.

It's important to state that.  This works best for small systems with no
outbound authentication who wish to limit their users forging foreign
domains that publish SPF records.


The prospective SPF check is an easily implemented check that would
prevent much forgery coming from large ISPs without the administrative
burden of validating their entire userbase.  It also gives them an
easy
answer if someone complains about forgery from ther network (publish a
proper SPF record and it'll stop).

It actually wouldn't prevent much forgery at large domains, as this
method allows all of their users free use of any domain designating
those MTA's.  It only prevents the customers of large services from
forging domains belonging to users of _other_ services, which is not
very interesting to them.  They see their current measures, which
consist of booting users after they commit forgery and abuse other
systems, as adequate for their needs.

--
Seth Goodman

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to http://v2.listbox.com/member/?list_id=735