On 5/5/15 1:24 PM, John R Levine wrote: >> John’s proposal changes DKIM but also requires additional >> changes in DMARC to respect the changes that were made to >> DKIM when doing alignment (the @fs=domain is more or less >> the same as the Original-To below). ... > > It's not supposed to. The decision about whether a DKIM > signature that depends on a chained signature is valid is > supposed to happen entirely within the updated DKIM > module. DMARC just uses that result. I assume the DKIM > module is able to look at all of the DKIM signatures on a > message and report back which ones are valid. Dear John,
Your version of DKIM delegation is cleaner but there is something that could be even cleaner. For example, TPA-Label could be made simpler by requiring a DKIMv2 like element to indicate which header fields in a delegated signature added by the third-party signature are not to change. Conversely, TPA-Label could reference a compressed selection of headers that represent a predefined element indicating which header fields are not to change between the first and third-party signatures and eliminate even the need for a DKIMv2 signature. This could offer a similar expiry scheme in the same manner, but I doubt such would be needed. The first party DKIM signature could even include a hash representing the content of the requisite headers, if that seems important. No special DKIM signature. No complex TPA registration which upset Hector among others. This would have less overhead without any mandated sequence or special DKIM signatures. DMARC domain would need to track which third-party services are being used. They could simply amend the list as needed and delay sending to any new domains until registered. This effort could be delegated to a different entity able to process outgoing logs and DMARC feedback. Once in place, DMARC induced disruption should evaporate while allowing safe use of Sender header fields to retain SMTP compatibility. We have seen too many botnets using various polymorphic schemes able to leverage any window of time to amplify any malicious message that might be allowed within any expiry. Expiry does not seem to offer much protection. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
