Douglas Otis wrote:
On Jan 23, 2007, at 8:50 AM, Hector Santos wrote:
Douglas Otis wrote:
On Tue, 2007-01-23 at 10:07 -0500, Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
Authoritative statements made by a DKIM aware MUA is a good thing.
However from an ISP perspective I would not depend on an end user to
have a DKIM aware MUA but will verify and do Policy silently at my
edge MTA devices. Any mail that makes it past there can still be
acted upon by the MUA.
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.
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!
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? Whats the different if the VERIFICATION is applied at the MTA
vs MUA. What makes the MUA exclusive and holds the copyright on this
technology of yours? What about thin clients?
By the way, what filter? I don't see anything about Filters in DKIM-BASE?
Anyway, it is still out of your control.
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.
Verifying all signatures ahead of filters will increase require
resources.
What 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?
> 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 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?
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 expect ions for MUA/DKIM operations.
> 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.
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!
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.
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?
> How about a bottle of Cabernet versus your six-pack? : )
I've been drinking GlenFiddich (aged 15 years) these days. :-)
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.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html