Murray S. Kucherawy wrote:
>> Scott Kitterman wrote:
>> My experience is it varies a lot by domain. Some domains are phishing
>> targets
>> and some aren't. If it's not a phishing target DKIM doesn't matter much
>> either way. If it is, then if they can manage to sign all their outbound
>> mail
>> signed/not signed gets to be useful. So I don't think looking at global
>> status is a very useful basis for deciding the question.
>
> So you'd rather I run this on some signing domains that aren't
> obvious phish targets? I can do that. If you have a few you think
> might be interesting, send me the names; if not, I can see if I can come
> up with some just based on the numbers.
>
> And I can constrain it to a specific reporting site (e.g., my own)
> instead of all reporters if you think that gives a more interesting view.
This sounds like you are missing a point here. But it might help to
know a general makeup of the volume collection you have from the
standpoint if it was already pre-filtered. I guess you won't readily
know that without asking your contributors, but it would be good know
what level, if any, filtering was already done.
The reason why I ask is because many systems reject mail before it is
accepted and this can mask the value of RFC5322 (payload) evaluations.
In addition, it quite often very difficult (if not possible) to turn
it off just to see how DKIM will work.
For your collection analysis, you will need a majority of the system
with "always accept" first operations so that you can get the large
spectrum of bad vs good mail. Then you will need a criteria for what
is considered "bad."
Did you see my post where I showed how large the local hosted domain
spoofing is a real problem?
For our receiver, we have 4 checks at the MAIL FROM: SMTP state:
o CLHRP - Check Local Host Return Path
o RPF - Operator defined Return Path Filter rules
o SPF
o CBV - Call Back Verifier
For CLHRP, if the domain part is a locally hosted domain, then the
user account is checked. It must be a valid user account.
For RPF, operators create their own rules, and normally it could be a
lightweight SPF-like conditions to help avoid the next SPF DNS based
check for local domains:
REJECT IF %RPD% = "santronics.com" AND %IP% !IN 208.247.131.*
REJECT IF %RPD% = "winserver.com" AND %IP% !IN 208.247.131.*
REJECT IF %RPD% = "isdg.net" AND %IP% !IN 208.247.131.*
After that SPF is checked and then CBV (which BTW is the highest
rejection for us, bad return paths is a real problem).
Its not just me, any SPF domain will have the same high benefit of
protected against local domain spoofs. So with these MAIL FROM check
alone, it can very well hide the exclusive value and benefits of DKIM
for unauthorized signers or invalid/no signatures states.
BTW, one reason why we have such a high reject is because we were
ISP/ESP in the 90's with our PPP and RADIUS servers and got of that
business in 1998. We had around 80K "Free Domain" user accounts and
we still get a consistent 60% RCPT rejection of dirty or inactive
accounts. It has never let up.
I suspect the YAHOO, GOOGLE, AOL, if they are among your collection,
they probably reject a lot today at the SMTP level. In the past, many
didn't and always accepted first for scalability reasons. But
machines are much faster today, software is more dynamic in its
checking especially with the terrible accept/bounce problem everyone
is trying to avoid with SMTP rejects.
I am just saying, it will help to know to some extent what is the make
up of the collection you have from a pre-filter standpoint. If most of
it is pre-filtered, then extracting the various value of DKIM is
masked or lost.
--
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
