spf-discuss
[Top] [All Lists]

Re: For SPF council review: Policy for shared MTAs

2005-05-13 06:29:35
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
wayne wrote:
steps should be taken to prevent cross-customer forgery, such as the
use of SMTP AUTH [RFC2554]. 

SMTP AUTH alone doesn't help, it has to be the MAIL FROM AUTH in 2554, or
the enforced submission rights in 2476.  Maybe say "see also" adding 2476
instead of "such as" etc. 

A reference to section 6.1 in RFC 2476 would be good:

| 6.  Optional Actions
| 
|    The MSA MAY do any of the following:
| 
| 6.1.  Enforce Submission Rights
| 
|    The MSA MAY issue an error response to the MAIL FROM command if the
|    address in MAIL FROM appears to have insufficient submission rights,
|    or is not authorized with the authentication used (if the session has
|    been authenticated).
| 
|    Reply code 550 with enhanced status code 5.7.1 is used for this
|    purpose.

Here's a revised patch, including my wording improvements, an added 
reference to RFC 2476, plus the missing reference declarations:

- --- draft-schlitt-spf-classic-01pre5.xml
+++ draft-schlitt-spf-classic-01pre5+mehnle_cross-customer_forgery.xml
@@ -25,4 +25,8 @@
     <!ENTITY rfc1983 PUBLIC '' 
       'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1983.xml'>
+    <!ENTITY rfc2476 PUBLIC '' 
+      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2476.xml'>
+    <!ENTITY rfc2554 PUBLIC '' 
+      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2554.xml'>
     <!ENTITY rfc3696 PUBLIC '' 
       'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3696.xml'>
@@ -1964,5 +1968,8 @@
           format has several options for the third party domain to
           authorize the service provider's MTAs to send mail on its
- -          behalf.
+          behalf.  For mail service providers, such as ISPs, that have a
+          wide variety of customers using the same MTA, steps should be
+          taken to prevent cross-customer forgery (see <xref
+          target="cross-user-forgery"/>).
         </t>
       </section>
@@ -2015,4 +2022,24 @@
         </t>
       </section>
+      <section title="Cross-User Forgery" anchor="cross-user-forgery">
+        <t>
+          By definition, SPF policies just map domain names to sets of
+          authorized MTAs, not whole e-mail addresses to sets of
+          authorized users.  Although the "l" macro (<xref
+          target="macros"/>) provides a limited way to define individual
+          sets of authorized MTAs for specific e-mail addresses, it is
+          generally impossible to authenticate, through SPF, the use of
+          specific e-mail addresses by individual users of the same MTA.
+        </t>
+        <t>
+          It is up to mail services and their MTAs to directly
+          prevent cross-user forgery: based on SMTP AUTH (<xref
+          target="RFC2554"/>), users should be restricted to using only
+          those e-mail addresses that are actually under their control
+          (see <xref target="RFC2476"/> section 6.1).
+          Another means to authenticate the identity of individual users
+          is message cryptography such as PGP or S/MIME.
+        </t>
+      </section>
       <section title="Spoofed DNS and IP Data">
         <t>
@@ -2272,4 +2299,6 @@
       &rfc1034;
       &rfc1983;
+      &rfc2476;
+      &rfc2554;
       &rfc3696;
       &rfc3833;

AFAIK it's already in draft-hutzler-spamops-04, and that draft goes for
BCP supported by the ASRG.  Or maybe reference draft-hutzler:

<http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hutzler-spamops.xml>

I found nothing similar to RFC 2476 section 6.1 in there.  Did I miss it?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFChKvAwL7PKlBZWjsRApJ2AKCeffD2SvcPJJbWYVbM3CtbPLwqNQCdHtyn
fLq1cwEkt/CukdwRUtf0wD8=
=iZbU
-----END PGP SIGNATURE-----


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