Michael Thomas wrote:
Wietse Venema wrote:
Hector Santos:
Wietse Venema wrote:
If the verifier gives different treatments to different types of
"other", then the bad guys will exploit the verifier's behavior.
Applying equal treatment should be done across the board, the valid
and invalid, not just for the so called "elite" messages.
It is with the exceptions and relaxed provisions where exploitation
will take place, the FSUSP (FAILED SIGNATURE UNSIGNED STATUS
PROMOTION) is one of them.
Perhaps I wasn't clear enough.
When a DKIM verifier gives unequal treatment to any of the following:
- no signature
- broken signature
- unsupported signature
- other failure
Then the bad guys will send their forged mail in the way that receives
the most favorable treatment.
Correct. +1. Bueno.
I think that what people need to keep completely separate is that
forensic categorization is NOT the same as what an automaton
should be programmed on. It's fine to mine all of these nuances
to look for trends, etc, but it requires judgment and some amount
of risk. A dumb automaton is usually not this informed, and we
definitely do not want to promote the idea that you naively use
those clues as if they were not gameable.
Michael, process automation is my expertise. As a chemical engineer, I
am highly trained to look a total system integration for cause and effects.
But thats neither here or there, this is all quite simple.
Your have a SMTP Appliance product in the market. You have thousands, if
not millions of customers using your SMTP Appliance product.
I find it highly unprobable, near on the ridiculous, that this product
is going to IGNORE failures with their new DKIM processing.
If you ignore it, then what you have done is simply promote legacy
operations with the bad guys - they don't have to sign at all. If you
tell me that you have offer an HELPER system (reputation or otherwise),
then you are not ignoring it and unless everyone has the same reputation
system and/or SMTP Appliance box, you will be treating it differently.
Thanks
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html