Re: iesg comment re message submission indraft-ietf-grip-isp-expectations-03.txt

[Randall Gellens <randy@qualcomm.com>]

[[[ I've added Chris and John to the To header, to give them a chance 
to comment.  --Randy Gellens ]]]

At 1:47 PM -0700 5/29/00, tomk@neart.org wrote:

>  I'm open to making this change.  I'd like to hear from Randall Gellens,
>  who was largely responsible for the original text.
>
>  Randall ?

I agree that SMTP authentication is very much needed, and I like the 
point in the suggested second paragraph.  However, I think removing 
the recommendation for the submission port goes against the intent of 
the draft.  It also defeats much of the suggested second paragraph. 
This paragraph talks about separating local delivery from relay, and 
how useful this is in the context of a security policy.  The use of 
the message submission port makes this much easier, and this can be a 
big help in effectively applying and enforcing authentication 
requirements.

I've included my own suggested replacement text at the end of this 
message, which I hope meets Randy Bush's goal of clarifying the 
importance of SMTP AUTH while also making clear the other points.

To answer your question, I am aware of several servers that support 
the message submission port as well as SMTP authentication (for 
example, Sendmail 8.10 and PMDF).  Some have as their default 
configuration that suggested by this document.

This document is intended to be published as a BCP.  I think removing 
the recommendation for the submission port would be a mistake.


>  On Mon, 29 May 2000, Randy Bush wrote:
>
>>What about changing
>>
>>>5.4 Message Submission
>>>
>   >>    To facilitate the enforcement of security policy message submission
>>>     should be done through the MAIL SUBMIT port (587) as discussed in
>>>     "Message Submission" [RFC2476], rather than through the SMTP port
>>>     (25).  In addition, message submissions should be authenticated using
>>>     the AUTH SMTP service extension as described in the "SMTP Service
>>>     Extension for Authentication" [RFC2554].  In this way the SMTP port
>   >>    (25) can be restricted to local delivery only.
>>>
>   >>    These two measures not only protect the ISP from serving as a UBE
>>>     injection point, but also help in tracking accountability for message
>   >>    submission in the case where a customer sends UBE.  Furthermore,
>>>     using the Submit port with SMTP AUTH has additional advantages over
>   >>    IP address-based submission restrictions in that it gives the ISP's
>>>     customers the flexibility of being able to submit mail even when not
>>>     connected through the ISP's network (for example, while at work), is
>>>     more resistant to spoofing, and can be upgraded to newer
>   >>    authentication mechanisms as they become available.
>>
>>With:
>>
>>5.4 Message Submission
>>
>>     To facilitate the enforcement of security policy, message submission
>>     should be authenticated using the AUTH SMTP service extension as
>>     described in the "SMTP Service Extension for Authentication" [RFC2554].
>>
>   >    The reason for this is to be able to differentiate between local
>>     delivery and relay (i.e. allowing local customers to send email
>>     via the local SMTP outgoing service to random receivers on the
>>     Internet). Non-authenticated delivery should only be allowed for
>>     local delivery. This to make the ISP SMTP service more resistant
>>     to spoofing, and to make it upgradeable to newer authentication
>>     mechanisms as they become available. See the RFC "Anti-Spam
>>     Recommendations for SMTP MTAs" [RFC 2505] for more information
>>     on this issue.
>>
>>     A separate RFC, "Message Submission" [RFC2476], describes the
>>     ability to handle message submission through the MAIL SUBMIT
>   >    port (587).
>>
>>I.e. the important thing is to specifically point out that SMTP
>>authentication is needed, deeply needed, regardless of what port is
>   >used. One might mention the other port number for SMTP submit, but I
>>don't know what the status of that feature is among the vendors. Last
>>paragraph can even be removed completely from my point of view.
>>
>>Also, add the following to the reference section:
>>
>>[RFC 2505] RFC 2505, Anti-Spam Recommendations for SMTP MTAs.
>>             G. Lindberg. February 1999. (Format: TXT=53597 bytes)
>   >            (Also BCP0030) (Status: BEST CURRENT PRACTICE)


My suggested text:


To facilitate the enforcement of security policy, message submission 
should be done through the MAIL SUBMIT port (587) as discussed in 
"Message Submission" [RFC2476], rather than through the SMTP port 
(25).  In addition, message submissions should be authenticated using 
the AUTH SMTP service extension as described in the "SMTP Service 
Extension for Authentication" [RFC2554].   In this way the SMTP port 
(25) can be restricted to local delivery only.

The reason for this is to be able to differentiate between local 
delivery and relay (i.e., allow customers to send email via the ISP's 
SMTP service to arbitrary receivers on the Internet). 
Non-authenticated SMTP should only be allowed for local delivery.

As more and more mail clients support both SMTP AUTH and the message 
submission port (either explicitly or by configuring the SMTP port), 
ISPs may find it useful to require that customers submit messages 
using both the submission port and SMTP AUTH; permitting only inbound 
mail on port 25.

These measures (SMTP AUTH and the submission port) not only protect 
the ISP from serving as a UBE injection point via third-party relay, 
but also help in tracking accountability for message submission in 
the case where a customer sends UBE.

SMTP AUTH is preferred over IP address-based submission restrictions 
in that it gives the ISP's customers the flexibility of being able to 
submit mail even when not connected through the ISP's network (for 
example, while at work), is more resistant to spoofing, and can be 
upgraded to newer authentication mechanisms as they become available. 
See the RFC "Anti-Spam Recommendations for SMTP MTAs" [RFC 2505] for 
more information on this issue.