spf-discuss
[Top] [All Lists]

Re: For SPF council review: Policy for shared MTAs

2005-05-12 08:44:15
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wayne Schlitt wrote:
Besides something in Implications: Mail Services (Section 9.4), I could
also see it being mentioned in the Security Considerations instead.

I have added a sentence to the end of the second paragraph of section
9.4.  Along with other corrections, it now reads:

9.4  Mail Services

   [...]  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, such as the use of SMTP AUTH
   [RFC2554]. 

Like Scott said, SMTP AUTH (RFC 2554) in itself does not prevent cross-user 
forgery, it just limits who can use an MTA to relay mail.  (IMO this is a 
significant omission in RFC 2554, but oh well...)

I think Scott's text suggestion would be appropriate for section 9.4, but I 
also think that in order to complete the envelope sender forgery 
protection already provided by SPF, significant further steps are 
necessary, and that prevention of cross-user forgery is one of the most 
important.  So perhaps a sub-section should be added in the Security 
Considerations section, and section 9.4 should just point to that?

- --- draft-schlitt-spf-classic-01pre5.xml
+++ draft-schlitt-spf-classic-01pre5+mehnle_cross-customer_forgery.xml
@@ -1964,5 +1964,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-user forgery (see <xref
+          target="cross-user-forgery"/>).
         </t>
       </section>
@@ -2015,4 +2018,23 @@
         </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 entire 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, through
+          SPF it is generally impossible to authenticate 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 use only
+          those e-mail addresses that are actually under their control.
+          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>

(Patch may need to be applied manually because it is based on -01pre5, not 
your internal working revision.)

I know it makes the spec longer once again. :-(  The problem is, I don't 
think there is a single section that can safely be deleted in its 
entirety.  I'll tend to the size problem in another message.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCg3nPwL7PKlBZWjsRAq5lAKDtWm73af63lIwhwsaxgL142eQcvQCgjkwT
MhPTtJ7sdc05YgVxMF8HKio=
=4uaa
-----END PGP SIGNATURE-----