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