Hello!
On Thu, Nov 18, 2004 at 05:23:10PM +0100, Alex van den Bogaerdt wrote:
[...]
I get the feeling you think false positives are possible with SPF.
Please discuss.
OK, you have quite legalistic points. For me, a false positive is
if someone human intends to mail me, from an address he "owns" (be it on
an own domain, be it on a shared domain, but granted to him by the
domain owner), and this mail doesn't reach me for other reasons than
network or computer failure, this is a false rejection.
Or if I, using my legitimate email address, send mail to someone and the
mail doesn't come through, it's a false positive - unless the recipient
actually *intended* to filter my mail (like killfiled me, e.g. using
Sieve).
For SPF, especially the forwarding problem is at risk of creating false
positives. Solutions like SRS put the burden on parties that might not
be interested in SPF at all. I'd think a solution would be more
appropriate that keeps the burden at the interested parties (i.e. the
sender's domain owner who wants to control the domain usage, and/or the
recipient's MX operator) *only*.
SES *could* be such a solution perhaps, but as the state of affairs are
now, some domains publish spf with -all, others reject spf fail, and
only a few forwarder sites do SRS. That's a bad order of things.
Things should go on a more realistic route: Reality is there *are*
different forwarding setups, by far not all of them run SRS, perhaps
not even anything spf-related at all. If your goal reality is a sender
controlled level of 2821-mail-from authentication w/o false positives,
I'd rather suggest things like solve forwarding first, in whatever way,
*then* start publishing -all and rejecting spf fail. Not the other way
round, as it seems to be done, unfortunately.
Kind regards,
Hannah.