spf-discuss
[Top] [All Lists]

RE: Use of SPF with Shared MTAs (was Possible New Mechanism Prefix)

2004-06-26 18:37:03
From: Michael R. Brumm
Sent: Saturday, June 26, 2004 4:02 PM


(Rude side note:  You are using an outgoing mail server that you don't
trust.  This is a problem that you need to correct.)

No.  I trust the mail server to only be used by authorized
users.  It's the other users I don't trust.

From you previous posts, I understand that your ISP's MTA uses
SMTP AUTH...

So, your ISP's MTA allows authenticated users to pretend to be
anyone? On a properly configured MTA, when you authenticate you
are only allowed to send out using particular e-mail
addresses/domains assigned to your account.

You are absolutely, unarguably correct on this point.  Permitting users to
forge any address once they validate themselves to the MSA is a lazy,
brain-dead and improper way to operate an MSA.  The most charitable excuse
is that it is a convenience for users who don't have SMTP AUTH access to
their foreign MSA.  The less charitable explanations range from laziness to
incompetence.

Unfortunately, most mailservers do _not_ appear to enforce these reasonable
guidelines.  If they simply did that one simple thing, spam would be a
fraction of what it is today.  If they further restricted port 25
connections to their smarthost (where the end-user is not permitted to run a
mailserver), we probably would have no need for SPF.  This would be doing
nothing more than enforcing their own AUP's, but it does take a non-zero
effort.  Some customers would be annoyed, that is true.  If the big players
operated this way, the smaller ones would eventually be forced to go along
if they wanted their mail delivered.  At that point, the playing field would
be level.  This would also force more organizations to support SMTP AUTH,
removing the major excuse for permitting forgeries in the first place.

Because a number of the largest ISP's allow users to forge addresses after
authentication and do nothing to stop unauthorized end-users from operating
mailservers, we are stuck with a miserable mess today.  While it _should_ be
possible to say, "this message came from a designated MTA for the domain so
it is not a forgery", we are nowhere close to that.  Crypto solutions are
great, but we shouldn't need to resort to that complexity when such a simple
mechanism to prevent forgery exists.



Also, I know this might sound rude or uncaring, but if you are
really worried about being blacklisted because you use a shared
MTA that is insecure, then doesn't it seem reasonable that you
would pay for access to a properly secured MTA? I mean, there is
no free lunch.

This is also true.  Even if you have the money, however, there are not that
many of them and they are difficult to locate.  As a side note, I wonder if
it would make sense to start a list of providers with their level of
compliance to various BCP's listed?  It really is difficult, even for a
knowledgeable user, to locate a provider that complies with most of the
BCP's.  The providers don't make that information readily available and
often the tech support people don't even know for sure.  It would be
especially useful for people who value some practices over others, i.e. some
folks would insist on SMTP AUTH, some would insist on strict no-forgery
policies, some care more about the quality and quantity of incoming mail
tests while others would prefer to see a choice of blacklists for rejection.
I realize that this suggestion is fraught with difficulty and invites
lawsuits, but take it as a statement of a problem that exists in need of a
solution.  I don't think the reputation systems that are currently being
discussed address this need.

--

Seth Goodman