ietf-mxcomp
[Top] [All Lists]

Re: TECH-OMISSION:Submitter concept should be expanded to include Peristent User Accounts (PUA)

2004-09-02 11:22:05

On Thu, 2004-09-02 at 09:01, Scott Kitterman wrote:
I wasn't sure to post this as a deployment issue, a DOC-BUG issue or a
tech-omission issue, my apologies if this isn't the right one.

Currently it is very difficult for small domain owners, such as myself, who
use a shared MTA to construct a record that will produce a pass result
without also opening ourselves up to forgery from other legitimate (i.e. the
MTA owner has authorized them to use the MTA) users of the shared MTA.  The
reason for this is that virtually no shared MTA providers that allow domains
other than their own in mail from or from restrict them at all.

This limitation applies equally to SPF classic as well.  In a recent
discussion on this topic on the spf-discuss list (with ~1,000 subscribers)
only one provider that would prevent cross-customer forgery was identified.
The result of this is a record that looks like this (I'm using an
abbreviated generic version of my SPF classic record since I haven't created
a Sender-ID record - the point's the same either way):

"v=spf1 include:webmail.hostco.com ?a:relay.hostco.com ?mx
?include:isp.net -all"

There are three possible solutions to this problem that I can see:

1.  Shared MTA providers only allow their customers to send e-mail from
domains for which they have a legitimate right to do so.  I believe this
would be very cumbersome for large providers to do.  How would they know
what domains different users had access to?  If I use my hosting company's
MTA, then they could know reasonably easily, but how about the ISP?  I can
see this leading to a situation where MTA providers would only allow mail
from domains they host.  That would cost people in situations like me
redundancy.  I generally send through my hosting company's MTA, but if it's
down, I can send via the ISP's MTA.  Combined with port blocking, this might
also force small businesses to host their domains with their ISP.

2.  Businesses that want to get a pass result need to set up their own
dedicated MTA.  The reason that small busnisses don't do this now is they
have neither the time nor the expertise.  This approach will no doubt result
in even more poorly configured and inadequately maintained MTAs appearing on
the internet.

3.  Explicitly add a third possible source for submitter, the Persistent
User Account (PUA).  This would allow providers of shared MTA services to
add as a submitter the local (to the shared MTA) e-mail address of the user
that submitted the message to the MTA.  This was discussed on the list in
July.  Here is the start of the thread:

http://www.imc.org/ietf-mxcomp/mail-archive/msg02633.html

A small business wanting to specify their "permitted or nominal"
outbound MTA servers, would not be concerned should the MTA receive the
reputation, where these servers are shared and administered by others. 
When an MTA is spoofing headers or not disabling abusive accounts, the
MTA reputation handles this problem directly.  It could be the
underlying problem is a compromise or misconfiguration of the MTA.  If
the headers are trustworthy, based upon knowing the reputation of the
MTA, then the origin of the mail can be determined by the headers. 
There is no need to add yet another field.

If the name of the MTA were authenticated, then listing the "permitted
or nominal" outbound servers would only require creating a name list,
and not require a redirected lookup or the repeated listings of
addresses that creates support issues and potentially high overhead for
mail recipients.  As example, the SPF records could become something
like:
  _mp._smtp.small-business.com. PTR hostco.com.
                                     PTR isp.net.
    
This does not require any additional lookups to determine what MTAs are
permitted to send mail on behalf of small-business.com nor does this
require keeping address records synchronized with the host addresses.  

A flag can indicate this list is to be considered comprehensive
(permitted) to enable rejection of mail not originating from MTAs having
a name from that does not include one of these top level domains.  If
the list is to be considered not comprehensive (normative), then only
when mail is coming from these prescribed MTA servers would the mail
receive a higher level of "certainty."

Including within the CSV-CSA record specification an indication that the
MTA relays multiple domains, could lower the "certainty" rating for mail
traveling through shared servers.  There could be another indication
that specifies all relayed mail is domain "restricted" meaning the MTA
checks to ensure only specific sources for a domain are allowed, to
restore the level of certainty.  In other works, it checks the policy
records for the mailbox domains.

The mailbox restrictions could be either the RFC2821 MAIL FROM or the
RFC2822 From.  A restriction on the RFC2822 From may be desired for
financial institutions for specific sub-domains as a means to offer
increased protection of these specific domains.  I expect most domains
would be happy using the SPF mode of only restricting the MAIL FROM. 

By limiting reputation to the MTA name, non-restricted mailbox domains
do not offer a means to exploit that domain.  A reputation service will
still be able to block mail from any domain of course, but it would be
at the channel level.  Reputation blocking needs a higher level of
certainty than that offered by examining just mailbox domains. 
Establishing a relationship with the MTA and the mailbox domain however,
enables the prevention of mailbox spoofing as an independent function of
reputation.  By keeping these function separate, the problems with a
shared MTA servers goes away.  By authenticating the name of the MTA,
reputation services are made much less expensive to maintain and polices
are easier to enforce.  By using the name of the MTA, a history can be
established and "new" names can be readily detected.   

-Doug


<Prev in Thread] Current Thread [Next in Thread>