On Tuesday April 13, ste(_at_)smxy(_dot_)org wrote:
The only thing I can read from that, given that the rest of the world
has *not* implimented SRS, is that SPF is not ready for prime time yet,
as it breaks forwarding and there is nothing in place to fix that, that
anyone is ready/willing to impliment.
It would seem that perhaps I shouldn't use it, until it is a complete
solution. It looks very promising, but I can't use something that breaks
valid email. :-/
I feel I should point out (not that I would be the first) that SPF
does not break anything.
SPF is simply a way for a domain to publish policy.
SPF implementations are a way for receivers to evaluate an email
against someone's policy, and to tag the email accordingly.
But if any MTA unilaterally rejects SPF-fail messages (or assumes that
SPF-pass message are good messages) then it is that MTA that is
breaking valid email, not SPF.
Mail forwarding is an area where SPF cannot give reliable information
as there is no established way for someone to claim responsibility for
the email.
This can be fixed by either the forwarder or the recipient taking
responsibility.
The forwarder can do this using SRS.
The recipient can also take responsibility.
One way is for recipients to organise for their mail to be forwarded
to some special address rather than to their standard address.
This special address would indicate to any mechanism that checked SPF
results, that the recipient was taking responsibility, and that an
SPF-fail shouldn't be fatal.
Obviously this 'special address' would need to be protected from
misuse. Secrecy might be enough. Other options are possible.
Another way is to maintain a whitelist of trusted forwarders such as
that maintained at spf.trusted-forwarder.org
Note that I would advocate maintaining a local whitelist, rather than
(or atleast as-well-as) using trusted-forwarder, as the local mail
admin really needs to be in control.
If an MTA is to be harsh at rejecting mail based on SPF results, it
must provide a way for forwarded mail to get though successfully.
Either it requires all forwarders to take responsibility for mail they
send, or it takes responsibility itself.
The former is impractical. I am not in a position to force any other
domain to use SRS.
The later is practical. As a domain administrator, I am in a position
to educate my customers and encourage them to take action to make sure
that mail that is forwarded from other sites is accepted. I will be
doing this over the coming months before I consider getting really
strict on SPF compliance.
If SRS ever becomes near-universal, then maybe SPF-fail => reject can
be implemented without concern, but I don't see that happening very
quickly. For now, anyone who rejects email simply because SPF
checking reports Fail is risking losing genuine forwarded mail. This
is clearly the fault of the system that rejects SPF-fail, not the fault
of the system which asserts "!all" in their SPF record.
NeilBrown