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.
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
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 ...?
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?
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?
/rolf
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
