--On 1 July 2009 11:00:32 -0400 John Leslie <john(_at_)jlc(_dot_)net> wrote:
Ian Eiloart <iane(_at_)sussex(_dot_)ac(_dot_)uk> wrote:
The point of SPF is to authenticate the sending domain.
I don't believe SPF does any such thing. Domains can publish SPF RRs,
but those can't reasonably be said to "authenticate" anything, least of
all the "sending domain."
If the IP address is authorised (by the domain owner) to send mail from
the sender domain,
That's closer... But I'd argue that no SPF construct "authorizes"
sending email. In practice, I think it's quite clear that SPF constructs
merely express probabilities.
OK, so it's authorization rather than authentication. By "probabilities",
are you referring to the probability of forwarding, or the use of some
unauthorized MSA? Certainly, the latter need to be stamped out in the same
way that open relays were. There are other ways to deal with the forwarding
problem, and they'll be adopted in time as the value of SPF increases with
take up.
then bouncing mail into that domain isn't going to be causing
backscatter, unless the domain lacks internal controls over message
submission.
Of course, rather few domains other than corporate domains with
administrators more-than-average familiar with SMTP have reasonable
"internal controls over message submission". :^(
Yes, but they need to improve. They won't, unless they're held accountable.
If it does lack those internal controls, then the users of the domain
can blame the domain owner.
Indeed they can... does that actually accomplish anything?
Yes. Not usually as fast as you'd like. But, companies (email service
providers) go out of business if people stop using the service. For
commercial users
I guess there can also be issues where two distinct domains share the
same outbound IP addresses, through an email service provider.
Indeed, that is common...
In that case, the email service provider is the responsible party that
needs to be held to account.
(which, BTW, is what CSV set out to do...)
They need to ensure either (a) separation of domains by outbound IP
address combined with accurate SPF records,
Assuming they control either multiple IP addresses _or_ the SPF
records is risky. But even if they did, how would this lead to assigning
the responsibility correctly?
It prevents cross-domain abuse. When good.example shares IP addresses with
bad.example on the outbound MTA, then users of bad.example can forge mail
in the domain good.example and get themselves a free ride on the reputation
of good.example - thus damaging the reputation of good.example
If the two domains have separate outbound IP addresses (very feasible with
IPv6) then proper use of SPF can protect them from that abuse. Given that
this is all in the control of a single ESP, that ESP can put in place the
necessary protection for forwarding. This means that they can safely
publish +ve records for a domain's allocted IP addresses, -ve records for
the rest of the ESP's IP address space, and (for now) neutral or softfail
for the rest of the world.
Assignment of responsibility should be to the domain owner, or the email
address owner. It doesn't much matter which - they can sort that out
themselves. This would be a huge improvement over the current situation,
where you can only assign responsibility to an IP address. The main
improvement is that non-technical people have some understanding of
domains, but no understanding of IP addresses.
or (b) proper implementation of MSA on all the domains that they
provide service for.
That is at least practial... But how does it lead to assigning the
responsibility correctly?
The point is that the ESP needs to prevent the sort of cross-domain abuse
that I've referred to above. With proper implementation of MSA, they can
detect or prevent the cross-domain abuse. That ensures that an SPF pass
doesn't result in reputation being assigned to the wrong domain. It also
ensures that bounce messages aren't delivered into the wrong domain.
--
John Leslie <john(_at_)jlc(_dot_)net>
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg
--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg