Does it help if I agree with you that it should have been brought up? To your implicit question, I did not bring it up because I was not involved at the time. On the other hand, that effort did not expect an A-R to be used outside of one ADMD, so the need for source identification was not obvious.
ARC introduces the idea that A-R data might be useful outside of a single ADMD, so ARC is the opportunity to identify the data needed for this to be workable. ARC is still experimental, not standards-track. DMARCbis has forced recognition that indirect messages require different filtering algorithms than direct messages. To create those algorithms, it should be axiomatic that we need to be able to distinguish direct messages from indirect messages. Having done so, we need to extract the additional information needed to apply a differentiated algorithm correctly. I am simply an individual contributor trying to figure out how to use this stuff to correctly filter incoming mail. Show me how to correctly evaluate a forwarded message without understanding state sequence, and I will be happy to imitate someone else's success. Doug Foster On Tue, Dec 29, 2020, 9:50 PM Kurt Andersen (b) <[email protected]> wrote: > On Tue, Dec 29, 2020 at 5:31 PM Douglas Foster < > [email protected]> wrote: > >> >> DKIM, A-R, and ARC should all have a mandatory attribute indicating the >> HELO name of the server applying the header, the IP Address of the previous >> server which supplied the information being evaluated, or both. >> > > With all due respect, it seems to me like this is something which should > have been pointed out before this WG came to final consensus on 8601 (aka > 7601bis). A-R and AAR were not designed to be fed into a determinative > state machine. > > --Kurt >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
