Richard Clayton writes: > Yes in DKIM2 you may discover that an alteration was malicious, but at > least it will be crystal clear (once, for forensic purposes you check > every signature to hand) which entity should be blocked henceforth.
That looks like this forensic thing is done by the postmaster etc on the receiving end, i.e., people, not automatic systems, thus this is even less scaleable than users adding their known trusted forwarders to their trusted forwarders list. There are much more receivers than there are admins doing forensic things, and the requirement of knowledge is much higher, as those admins to do not have access to the knowledge the actual receiver might have. I am sceptical this will actually be scalable, and one persons spam is important newsletter to another person, thus doing blocking on the mailsystem level is not good idea. At least if person adds bad host to his/her trusted forwarders list, this will only affect him, and he/she can blame himself/herself. The customer support load might be same, but at least there is easy solution for those requests, simply say remove the offending forder from the trusted list. If the DKIM2 will collect list of hosts that are known to be bad and do blocking based on that, then the person receiving that fake newsletter might consider that newsletter to be important and complain when admins block it... By the look of it I am not sure if this difference is really something that will make DKIM2 scalable and ARC not... -- [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
