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

From: "Scott Kitterman" <[email-masked]>
Date: Thu, 2 Sep 2004 12:01:34 -0400

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

This would seem to be a much simpler solution for shared MTA providers to
implement than trying to determine which domains their customers are
authorized to send from.  It also gives a full address (no just a domain)
that has agreed to be responsible for the message.  Also, if Submitter
failed a check during 2821 checking, I believe the message could be rejected
before data.

This approach is hinted at in the examples (see the last paragraph of Page
7), but use in this manner is never described in the actual specification.
The reason I was thinking this might be a DOC-BUG is that examples shouldn't
introduce new functionality.

Proposed spec changes:

Page 2:

Change the paragraph that begins "Broadly speaking, ..." to:

   Broadly speaking, there are two possible approaches for determining
   the purported responsible address from existing SMTP information;
   either from RFC 2821 [SMTP] protocol data or from RFC 2822
   [MSG-FORMAT] message headers.  Each approach has certain advantages
   and disadvantages.

Page 4:

Change the paragraph that begins "SMTP clients MUST set..." to:

   SMTP clients MUST set the SUMBITTER parameter value to the purported
   responsible address of the message as defined in this RFC or [PRA].
   This also applies to messages containing a null reverse-path.

Add a new paragraph to follow that one:

   If an SMTP client is accepting a new message for transmission and the
   MUA is authorized to submit the message based on an e-mail address
   that does not appear in the RFC 2822 [MSG-FORMAT] message headers,
   then the SMTP client MUST set the SUBMITTER parameter value to the
   address used to validate the MUA's access to the SMTP client through
   whatever local means are used (such SMTP Authentication [SMTPAUTH]).

I'd be willing to settle for MAY here instead of MUST, but if we are going
to explicitly include this option, then I can't think of a strong reason
that it shouldn't be a MUST.

Page 5:

Add a sentence to the end of Paragraph 5.1:

If the e-mail address used for validation did not appear in the RFC 2822
headers, then appropriate RFC 2822 headers would be added and that e-mail
address would be used for the SUBMITTER parameters for subsequent
transmission of the message.

Scott Kitterman

---

From: Douglas Otis <[email-masked]>
Date: Thu, 02 Sep 2004 11:22:05 -0700

> 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