On Jan 23, 2007, at 1:12 PM, Hector Santos wrote:
Douglas Otis wrote:
On Jan 23, 2007, at 8:50 AM, Hector Santos wrote:
Douglas Otis wrote:
There are millions of new domains added and removed every day.
And if true, any given average node only sees 0.001% of them if
that.
How is this relevant?
Isn't the statement clear? Hardly one single NODE will have handle
a million churned domains per day, so its an irrelevant statistic.
Using your figures there are still 1000 unevaluated domains that
might be seen at some NODE. What makes this aggregate number
significant is the amount that needs to be evaluated and then
distributed.
New domains are often exploited before a registry can compile and
transfer what has changed. For ".com" there might be a 12 hour
lag in noting the millions of new domains, which is a short
interval compared to some TLDs.
Great, so the unregistered DOMAIN will fail. So it all good!
No. These domains are registered. They are not reported as being
registered however until much later.
Should the MTA verify DKIM signatures before applying filters?
Thats out of your control.
Verifying DKIM signatures after applying filters informs bad
actors what has slipped through.
How so?
When whether a signature is valid or not does not change how the
message is handled, then not validating the signature will not change
which messages are given a recipient. When verification is
selectively done ahead of filtering based upon signatures that permit
filters to be bypassed, then this should reduce the required
resources and false-positives. When DKIM verification follows spam
filtering, attempts to verify signatures only signals which messages
passed. Bad actors will be thanking you.
What's the different if the VERIFICATION is applied at the MTA vs MUA.
The signatures that are trusted will be different from the end user's
perspective. An untrusted verified signature is of no value in
either case. Only trusted and verified signatures should be used to
annotate messages.
What makes the MUA exclusive and holds the copyright on this
technology of yours?
The end user application can more accurately determine which messages
the recipient is trusting. Only those messages need to have the DKIM
signature verified.
What about thin clients?
There are extensions that can extend nearly all the popular MUAs and
web based clients. Web based clients can be extended by taking
advantage of normal display and unread options.
By the way, what filter? I don't see anything about Filters in DKIM-
BASE?
Spam represents the vast majority of what MTAs receive. These would
be spam/anti-phishing filters of course.
Anyway, it is still out of your control.
The base draft should not be so misleading and suggest that the MTA
always verifies signatures first.
Unless a valid signature permits the filter to be bypassed, there
is little value validating a signature afterwards.
Regardless of whatever your filter is, your right. If the MTA
validates the signature, there is little need or value for the MUA
to do it. Thats the whole point.
You have missed what was being said. An end user application does
not have a standardized way to know what has been validated by the
MTA. The MTA signing authentication headers increases the resources
required. The whole point is that what an MTA or MUA verify may be
very different. The recipient might not care about the From header,
but does trust the mailing-list noted in the Sender header for example.
Verifying all signatures ahead of filters will increase require
resources.
What filters?
Spam/anti-phishing filters.
Verifying all DKIM signatures adds cost and opens the door to DDoS
concerns without tangible benefit.
So why would you want the MUA to suffer if thats that case?
Why would the MUA suffer when limiting verification to just those
messages that are being trusted?
When the MTA will bypass spam or phishing filters based upon
specific signatures, these are the only signatures logically that
should be validated.
Who said anything about Mail Processing Order? Content processing
may not even be reached with 2821 checking is done. Is that a
problem for you too?
The MTA knows (well in advance) which signatures might rescue a
message from their filters before even accepting the message. Just
those signatures need to be checked.
The MUA can also be highly selective by only validating signatures
trusted by the recipient.
Which MUA are you talking about? Outlook, Thunderbird, Eudora?
What about telnet mail client, my web mail client? Do you have a
design there too? Will DKIM work without the SMART FAT OFFLINE MUA?
One could add DKIM verification scripts for any user interface or
API. When the application has a list of trusted domains, it should
not be problematic to cache DKIM keys for offline analysis, perhaps
for a slow and expensive connection.
There are plugins for Yahoo!Mail, Yahoo!Mail Beta, AT&T Yahoo!Mail,
Hotmail, Windows Live, Gmail basic and standard, Earthlink web mail
using Mozilla and IE browsers, and Outlook express to accept a
trusted list. This proves it is possible and works well.
Here is source for a DK and SPF plugin for Thunderbird by Joshua
Tauberer. Perhaps Mike might want to modify this for DKIM. : )
http://razor.occams.info/code/spf/
Such a strategy reduces resources demanded by DKIM deployment,
I see no proof of this and in fact, all indications are that you
are 100% completely wrong about your expectations for MUA/DKIM
operations.
When the more than 70% of the email accepted is spam, then verifying
only trusted sources eliminates a significant amount of DKIM related
overhead.
and will not leak critical processing information to bad actors.
I see no leaks at the MTA that can't be also leaked at any other
OFFLINE MUA.
Attempting to verify all DKIM signatures that have passed through the
spam/anti-phishing filters leaks information. When neither the MTA
or MUA attempts to verify untrusted signatures, no information is
leaked.
Don't forget about Display-Name only, clever use of UTF-8,
cousin domains, and obfuscations making it appear as though the
email-address is displayed.
So if the MTA can't handle it, we'll pass you that junk so you
can deal with it. A six pack your MUA can't deal with it neither!
There should not be any expectation that all signatures have been
verified. Logically only those signatures that might rescue a
message from being rejected should be checked. This checking
should be selective and happen ahead of other filtering.
Essentially this means that not all signatures should be checked.
(Hand flying over head!) Phew! Geez Doug, honestly, I have no clue
of what you are talking about! You are making all kinds of
assumptions!
Saying that all DKIM signatures should be checked at the MTA is
making assumptions as well. Ironically, checking all DKIM signatures
is not recommended by the DKIM base and lacks a logical reason for
consuming resources, which also signals bad actors about how far
their message has progressed.
There are millions more MUAs than there are MTAs.
Anyway, this is exactly the reason why you want the centralized the
DKIM processing at the backend. Our figure is ~15,000 users per
Wildcat! Hosting Server. Average break down about 30% Offline Mail
Access, 60% Online Mail Access (Web, Telnet, NNTP, GUI
frontend). Everyone benefits from centralized backend processing.
What do you mean by offline mail access?
This may suggest which MTA versus MUA effort might be better at
scaling.
So you basically you are saying that all this is waste a time, no
MTA should bother with DKIM processing, it should PASS all mail to
the user regardless of how its is access?
DKIM signatures should be verified at the MTA when a valid signature
might alter the handling of the message. This allows filters to be
more stringent while reducing false positives at the same time. The
end user application should not assume all signatures have been
validated when applying annotations based upon what is trusted by the
recipient. Unless there is a secure method to reliably pass
authentication information to end user applications, the signature
should be verified by the application.
You are beating a dead horse with your DKIM MUA push. Your best
bet is to get the MTA/MUA DKIM communications worked out so that
the MTA can pass verification information to the user (offline and
online). Until you do so, it is all out of your control.
Why should a user wait years for all the MDA/MUA interfaces to become
standardized? There is nothing to prevent an end user application
from verifying DKIM signatures now. It would be a mistake to think
that verifying _all_ DKIM signatures will not have a substantial cost.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
