On 11/21/24 15:00, Barry Leiba wrote: > That sounds unnecessarily complicated, and, as you say: because report > senders won't know if BetterZip is supported by the recipient's > implementation or not, if they want to interoperate in an environment > where they can't negotiate the algorithm, they can't use BetterZip and > they just have to stay with GZip.
The z tag would take care of the 'negotiation' part, as receivers could use it to signal which compression algorithm they support, but the complexity does not stop there. It would also be necessary for a third part to be able to override the supported algorithms, and the default should fall back to gzip if a third party report consumer is encountered. > I think that unless we put the supported algorithms in the DMARC > record we can't practically support optional algorithms. And I think > it's more complexity than it's worth to put a list of supported > algorithms into the DMARC record, given the small benefit. The extensibility would suffer, but I think history shows that no-one will use BetterZip, as currently, providers of all sizes send zip files. I think the best we can hope for is that implementors will finally abandon zip files as payload. In my opinion, this thing is just too much for too little. Daniel K. _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
