Thanks for your pennies. :-)
I just hope I wasn't giving you the idea that I was "promoting" the
eliminating of relaxed provisions.
No, I accept that it might be needed, but I strongly feel it only make sense
from a time limited based.
Note: I have not Wayne's spec yet. I am still an original SPF implemented
using Meng's specs.
The reason stated for relaxed provisions was predominated for "migration"
reasons, to allow systems to get their networks in order. Eventually, it
should be made a hard results - pass or fail.
What I am saying is that Migration implies an inherent "time frame" and we
should enforce this concept so that the relaxed provisions do not become the
automatic default for everyone.
As far as I am concern, if a domain is relaxed, it was a worthless lookup as
far as the SPF server is concern. It doesn't check any futher
authentication concepts for systems that have more than one. For these
type of systems, the made be able to trap the malicious transaction using
other means. But for a system just using SPF, their system would be over
burden.
Now, I also agree there is the forwarding problem. Using Relaxed provisions
should not be something that a SPF administrator relies on to solve the
problem. No, they should work very hard to get their network in order.
Otherwise, it is worthless information for SPF servers and will be until the
network is secured.
Now, we also have the potential of a relay system. Well, thats another
matter that requires the RELAY to do other things:
MUA---> MSA/MTA ---> MDA/MTA ---> MDA
As far as the MSA/MTA transaction to the MDA, it did its job.
If the MDA/MTA is an SPF server, then it this is called a transistion point
and it needs to modified the return path (SRS).
So in my view a MDA/MTA purports to supports SPF and it knows for sure it
will be routing mail, then they need to do SRS.
If the MDA/MTA does not support SPF, then we have a problem at MDA. This
is where the MDA could look at the HOPs to check the original MSA/MTA. But
this is a problem whether it is relaxed or hard results.
Base on my SPF experience, I think the forwarding issue is less of an issue
than the high potential exploitation of relaxed provisions.
If we don't address this, then ultimately, it could make SPF utterly useless
as it will most definitely be exploited by spammers once they see that a
"widely adopted SPF network" is forcing them to look for the loophole.
Just my nickle :--)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Michael Hammer" <dotzero(_at_)gmail(_dot_)com>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, May 17, 2005 1:29 PM
Subject: Re: [spf-discuss] Time to start rejecting on neutral?
Interesting thread. Enough so that it has drawn me back out of lurking
mode. It's all fine and well to stomp your foot and say that people
should boldly publish -all. The problem is that there are some pretty
interesting "checker" implementations (I was going to say screwy) that
a lot of (larger) mailers are still trying to sort through.
One example I've seen is a domain that rejects mail if the Mail From
(RFC2821) and the From (RFC2822) don't match. Granted that is a fringe
case that goes beyond SPF, but from an operational standpoint
recipient (MTA) implementations do show a wide variety of
outcomes....well beyond what reasonable people might expect from a
standard. This is especially true when one throws in applying PRA to
SPF1 records.
As others have pointed out, relaying is still an issue. Do you break
your business (or personal) communications today (using -all) in the
hopes that relayers get their act together or do you go with ~all in
the hopes that the pain of people treating that negatively is less
than the pain of broken relays?
One trend that bothers me is that I am seeing more ISPs utilizing rate
limiting without really thinking through the consequences of their
decisions. In fact, I was dealing with one large ISP that implemented
rate filters (by IP) and don't even log the connections (events) they
are rejecting! So it took a little digging to help them figure out why
they didn't see any connections in their logs.
In closing, SPF is a tool. I'm kind of amazed at some of the comments
on this list. Would you get upset at a screwdriver because you need
other tools to build a house? SPF is an imperfect tool in an
imperfect world. Bad people with bad intent will find other ways of
abusing the system even if SPF itself worked perfectly. I'd rather get
a tool that solves (even if for only a while) 80% of the problem than
to see endless efforts to create the perfect tool.
As usual, just my 2 cents.
Mike
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com