Frank Ellermann wrote: > Hector Santos wrote: > >> If DKIM h= has from:to:subject:date: and one or more >> of these fields are missing - BINGO - instance REJECT > > Wait a moment, didn't DKIM support the concept of a > signed *absence* of certain header fields using h= ?
True, except From:, but I believe that just adds to the problem and had always made me weary of DKIM adding too much pressure on receivers. IOW, how long will perpetual failure going to be tolerated? My theory, not for long. > *In theory* it could make sense to add Reply-To and > Sender always to h=, no matter if they are present > or not, Why? Why put further confusion and ambiguity on receivers? Why further perpetuate a continued recognition of a lower payoff in DKIM analysis? Why make the life the support people or whoever trying to make heads or tails if a header was indeed part of the original hashing and integrity expected to be maintain? I can see it now - we will never know if a SUBJECT or TO (which is not required by 2822) was part of the message or not even if h= says there *might* be a header. IMV, domains will be stupid to risk playing games that only adds confusion with an already complicated concept - a strategy you should expect to see from DKIM exploiters. > because a Reply-To or Sender inserted later > could a bad idea or malicious. A practical case is > Content-Type, present or absent, any modification > would be highly suspicious. Agree. But back to the OP's theory based on already long known experience by an acquaintance, when key display headers are prepended, and the question if this "our" problem. Of course not, if you value the fundamental idea of mail integrity that DKIM attempts to provide. Its a moot point if there are headers that will screw up the integrity. But it is still a problem for the general receiver in terms of further reducing the worth of DKIM calculations due to perpetual failure. If a receiver wanted to save the day, it might want to apply 2nd rehashing in case the first calculation failed based on the FIRST from: field. It might want to try the second to see if that the real From: field. But its worth the effort? Is it just as good to kick out (flag) the first failure regardless of the reason? When it comes with missing headers, thats a darn good check, and those who suggest it is not, doesn't matter because DKIM or NO DKIM, systems are doing it and a lot more will as the IETF continues to push 2822, asking what servers support it and how much, etc, you are beginning to see receivers actually kicking out mail based on invalid 2822 headers. But again, remember To: is not required by 2822. So its possible that a DKIM h= including To: may failure to validate without violating 2822. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
