Hi Rolf, On 4/15/19 2:06 PM, Rolf E. Sonneveld wrote: > Hi, Jim, > > On 12-04-19 21:44, Jim Fenton wrote: >> >> One of the significant discussions at the Prague meeting (and >> originally resulting from IESG comments) was that the Section 6, >> "Mailing list considerations" was incomplete because it didn't >> consider other causes of origination such as Sieve and vacation >> programs. So I have drafted an alternative Section 6, below. Please >> review and comment. (Thanks Barry L. for reviewing first draft). >> >> 6. Reorigination considerations >> >> In a number of situations, an agent for the addressee of a message >> originates a new message as a result of an incoming message. These >> situations include, but are not limited to, mailing lists (including >> administrative traffic such as message approval requests), Sieve [RFC >> 5228], "vacation" responders, and other filters to which incoming >> messages may be piped. These newly originated messages may essentially >> be copies of the incoming message, such as with a forwarding service >> or a mailing list expander. > > I wonder whether it's not better to refer to c.q. use the terminology > as defined by RFC5598. Something like: > > In a number of situations, a mediator originates a new message as a result of > an incoming message. See [RFC5598] chapter 5 for a non-exhaustive list of > examples of mediators. These newly originated messages may essentially > be copies of the incoming message.
I like "mediator" and the reference to RFC 5598 rather than "agent". I think I'd like to keep the examples rather than refer everyone to 5598 to see what is meant by a mediator. [aside: RFC 5598 doesn't seem to have up-to-date information about mailing list mediators. Specifically, it says that they leave the From address alone, which is frequently not the case with "DMARC-friendly" mailing lists.] > >> In other cases, such as with a vacation >> message or a delivery notification, they will be different but might >> contain parts of the original message or other information for which >> the original message sender wants to influence the requirement to use >> TLS transmission. > > I think this section clearly shows the limited guarantees that > REQUIRETLS can provide. It may give the sender a false sense of > safety/security. How is an implementor supposed to implement this spec > conveying all nuances of the rich e-mail eco-system to the user? How > can we expect an average user to understand the warning that's in the > Security Considerations section? Suppose a MUA implementor implements > this spec by giving the user a nice button labelled 'when recipient > does not support encryption, return the message and do not deliver' > (this won't fit on a button anyway ;-)). The user may find this meets > his/her privacy requirements, presses this REQUIRETLS button and sends > the mail. There are plenty of scenarios where the expectation of the > end user is not met: > > * the recipients mail system returns an out-of-office message, > including the decrypted contents of the message; > * some intermediate MTA sends a forensic DMARC report including the > decrypted contents of the message; > * anywhere along the chain of MTA's someone eavesdrop on the message; > * a mailing list, which in the remainder of your text for chapter 6, > does not apply REQUIRETLS to the messages it distributes; > * et cetera > Most implementations of REQUIRETLS are relay MTAs that have no connection with the user at all. An MUA that provides a nice button should tell the user clearly what that means and not oversell the capability. I'm not a UX designer but I have seen ways to give more information on a feature when it is first used or until the user clicks a "don't show me this any more" thing. But, of the users that even know that email is only sometimes encrypted in transit, how many know that any verification of the certificate is probably ignored? That middleboxes can interfere with TLS negotiation to cause messages to be sent in the clear so that they can be intercepted? Yes, REQUIRETLS doesn't address every situation, but it greatly limits the scope of this problem. The intent of this section is to inform implementors of the limitations so that they can educate their users and not oversell it. > >> Agents that reoriginate messages should apply REQUIRETLS requirements >> in incoming messages (both requiring TLS transmission and requesting >> that TLS not be required) > > This is rather confusing. I assume you mean: > > ... incoming messages (requiring TLS transmission) and requesting that > TLS not be required to the reoriginated messages ...? Not quite. I'm saying that agents (now mediators) should reoriginate messages with the same REQUIRETLS characteristics -- both applying the REQUIRETLS SMTP option if it was on the incoming message, and the use of the TLS-Required header field if the originator's intent is to not require the use of TLS for the message. > >> to the reoriginated messages to the extent >> feasible. A limitation to this might be that for a message requiring >> TLS, redistribution to multiple addresses while retaining the TLS >> requirement could result in the message not being delivered to some of >> the intended recipients. >> User-side reorigination (such as use of Sieve rules on a user agent) >> typically does not have access to the SMTP details, and therefore may >> not be aware of the REQUIRETLS requirement on a delivered message. >> Operators of user-side agents that expect sensitive traffic should >> consider this possibility, and if operationally feasible (when >> forwarding to a specific, known address; when appropriate >> configuration options are available) should > > SHOULD instead of should? It's an action by the operator, not the protocol, so the non-normative "should" was used. > >> apply REQUIRETLS whenever >> feasible to messages that do not contain the "TLS-Required: No" header >> field. > > Operators of these user-side agents are often the end users > themselves. I don't think anyone can expect from the average user that > constructs a sieve filter (e.g. using a form in a webmail client) that > he/she will honor the REQUIRETLS settings of the original message (the > more because they won't have this REQUIRETLS information available, as > you describe). > > Apart from this, I find this sentence difficult to read, maybe you'd > better split up this sentence in shorter parts? I'll try to break it up into more manageable pieces, yes. Thanks for your review. -Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
