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

Reply via email to