[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: iesg comment re message submission in draft-ietf-grip-isp-expectations-03.txt
I'm open to making this change. I'd like to hear from Randall Gellens,
who was largely responsible for the original text.
Randall ?
Tom.
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)