On Wed, Feb 17, 2016 at 10:42 PM, Jim Fenton <[email protected]> wrote: > On 2/17/16 2:13 PM, Yakov Shafranovich wrote: >> >> Section 3.4 - delivery: >> It is unclear what "delivery" means here, especially considering that >> SMTP may relay messages to another server, perhaps reference RFC 5598? >> Also, the parts in section 1 and the optional parameter in section 2 >> should play together with this, perhaps by requiring TLS in IMAP, etc. >> or not. Either way, this may need clarification. > > I have been trying to void "boiling the ocean" by constraining this > feature to SMTP. From the context, it should be clear that by delivery I > was referring to protocols such as IMAP and POP, although webmail > applies here as well. Are you suggesting that this requirement should be > a MUST rather than the SHOULD I proposed? >>
Maybe a MUST for SMTP relays following this one, and SHOULD for non-SMTP? >> >> One other comment - perhaps some sort of limiting digital signatures >> for headers only like DKIM can be employed by the receiving MTA to >> certify that the receipt and transmission was effective? I am thinking >> along the lines of Received headers or DKIM headers, which would allow >> traceability. > > This seems to be a separate feature - authenticated return receipts. > This might be useful, but I don't think it belongs here. I would hope > that MTAs would add information about REQUIRETLS to their Received: > header fields, much as they do about the use of TLS for messages they > receive, but I haven't worked out quite how to specify that yet. +1 on the received headers. Thanks _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
