In article <cd84a9c5-db98-45c9-bca1-281acfb38...@beta.fastmail.com> you write: >-=-=-=-=-=- >-=-=-=-=-=- > >My 2 cents, if we are validating an email then the services MUST cover email, >either by including '*' or 'email'. Regardless of what >attachments that email contains. > >RFC8460 appears to conflict with 6376 in this regard, and with that in mind 8460 should be updated to suggest s=email:tlsrpt or s=*
Or it could have separate signatures, one for the MTA with s=email and one for the mtasts consumer with s=tlsrpt. I honestly do not understand what problem the s=tlsrpt signature is supposed to solve. It can't have anything to do with authentication or security, since the alternative HTTPS transport has neither. As far as I can tell, to the extent anyone implements s=tlsrpt signatures, they just make it an alias for s=email with no opportunity for validators to choose. I'm inclined to submit an erratum and say the s=tlsrpt signature language was a mistake. R's, John _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
