On Tue, Feb 26, 2019 at 04:03:37PM -0800, Jim Fenton wrote:
> >>> If a REQUIRETLS message is bounced, the server MUST behave as if
> >>> RET=HDRS was present as described in [RFC3461]. If both RET=FULL and
> >>> REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be
> >>> transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS
> >>>
> >>> If the MAY is not taken, will the next hop be obligated to detect that
> >>> this
> >>> is a bounce and apply the preceding MUSTs? If not, perhaps this also
> >>> should be a MUST?
> >> It seems like it should, yes.
>
> > Actually, absolutely not. It is not the job of email *relays* to
> > modify the message content, and they must not be obligated to do
> > so. Message modifications break DKIM signatures, and require
> > content processing logic that relays are not expected to support.
> >
> > The bounce is constructed as a new message at the server that
> > encounters the initial delivery problem, it is *only* at *that*
> > point that the decision can be made to include or exclude the
> > original message body in the bounce.
>
> Good point; so we should just remove the phrase "and MAY be transformed
> to RET=HDRS on relay"? It contradicts the previous MUST anyway.
To be clear, certainly by the time the message is a bounce traversing
a relay back towards the envelope sender, it is too late to change
the structure of the bounce message. So no "bounce detection" is
appropriate.
However, along the original delivery path towards to the recipient,
one might require or allow relays to replace "RET=FULL" with
"RET=HDRS", so that by the time the message eventually bounces it
leaks less content. Ideally of course the MUA sending the message
with REQUIRETLS "yes", should also have specified "RET=HDRS".
So my previous message does not preclude relays on the outbound
path (towards the original recipient) changing the "RET=" value in
the original envelope. That's probably what the draft is getting
at, and perhaps could be stated more clearly.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
