----- Original Message ----- From: "Douglas Otis" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]>
> An association of the HELO with that of the signing-domain indicates > the message envelope is being obtained first hand. The HELO is not > analogous to that of a postmark, the received header added by a > recipient would provide a better comparison to that of a postmark. Which is associated with EACH hop or client domain machine transporting the message. If you have X Received, it tells the story of the sequenced processing, including the HELO machines. But I don't need to look into the payload (letter) to find out at the HELO level (postmark) if its valid or not. In short, an invalid HELO means everything else invalid. It would be illogical to suggest that the letter might be still "ok" if the postmark is invalid. Does it exist? Sure, broken software and no incentive to correct it - hence the relaxation and the exploitation. Put another way, you must have a valid CDN before CSV/DNA can even have chance of being reliable and if you agree this is true, then the opposite is true as well. Invalid CDN promotes a rejection and nothing else really matters in a post-legacy world where there is a new level of expectations. Look Doug, it is obvious this is yet another clear indication of the separation of the philosophies - one administration oriented, the other more system process oriented. The problem is that administrative ideas (as you are suggesting it) are not compatible with existing practice. Your push for CSV/DNA (which I expect will be increasing now in a "Phase II" now that DKIM sans SSP has been "pre-standardized") is clearly trust. I, on the other hand, is simply suggesting that before you can ride the bike to see if it will win you a race, your spokes, gears, tire, brakes, and possibly seat is expected to be working order. Just because it a "branded" item doesn't mean it does not have quality control problems. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
