On Fri, 7 Jan 2005 09:12:41 -0500, Scott Kitterman wrote:
On Behalf Of Julian Mehnle
Scott Kitterman [spf2(_at_)kitterman(_dot_)com] wrote:
Last year I asked if anyone on this list was aware of a company I could
buy SMTP services from that would not allow cross customer forgery. I
got one positive answer from Brazil.
In addition to SMTP-AUTH, MTA operators need to limit customers to using
authorized identities. This is a change for them that isn't going to
happen overnight.
And that can only mean that we have to advocate prevention of
cross-customer forgery more aggressively. We might even want to write up
an RFC that explains what MTA implementors and ISPs have to do.
Yes. Leaving aside the how for a moment, we need to advocate this.
The way to do it is in how we advocate SPF deployment. When we tell
people the put the ? in front of shared MTAs that don't prevent
cross-customer forgery we explain why and tell them that they ought
to talk to their provider about it. Eventually, this is going to be
a competitive discriminator. That's when it gets done.
Hopefully I got attribution right
I have given this issue much thought ever since the early days
of SPF, and I have considered to be an issue that needs to be
resolved if SPF is to become truely universal.
To expect a shared MTA owner to manually check the authority of
each of it's users to relay email from a domain (or address)
that is different to the one provided with the account, is
going to be onerous. Also what about removal of authority at a
later date.
I have the start of a possible solution in mind, but a full
tech spec:
If within the SPF record (via include) extra records were
provided using expansion features, I think it would be possible
for MTA owners to automatically verify the right of it's users
to send emails for non local domains.
The record could be an expansion of the login account name for
the MTA, known to both the MTA owner and the user, or another
agreed unique identifier, we are assuming AUTH here of course
Alternatively a fixed IP address could be used for a non AUTH
scenario.
This extra SPF record is in the control of the domain owner,
and therefore the authority is given (or removed) by the domain
owner.
Obviously this will require a change in MTA software, and the
domain will need a half decent DNS provision.
It could be combined with another suggestion I've heard (from
Jim Hill and another I afraid I can't remember), which is for
relaying MTA's to SPF check against themselves before delivery
is attempted, even better if it was done pre data with the
originator.
Obviously much work required, I now await to be shot down in
flames, ideas are cheap, implementation is not.
Regards
Karl Prince
______________________________________________________________
Email via Mailtraq4Free from Enstar (www.mailtraqdirect.co.uk)