Douglas Otis wrote:
On Thu, 2006-11-23 at 21:18 -0500, Hector Santos wrote:
DKIM will never be effective at blocking spam. Spoofing can only be
stopped by comparisons with lists established by recipients, such as
utilizing their address-book.
I totally disagree and I don't see that is required for us to consider
implementing DKIM into our system. A MUA is not required to protect a
DOMAIN who has published an SSP with its policy define telling a
RECEIVER what is expected and not expected.
What is meant by an "all From email-addresses are signed" policy
assertion?
Exactly what it means.
Does this mean "Reject or drop messages sent to a
mailing-list."?
Possibly. If it is not suppose to happen.
If so, what percentage of domains wish to make this
assertion?
Who knows? Do you? No. But I have a pretty good feeling most people,
company and systems are very interested in protecting their email domain
properties in this era. PERIOD.
And quite frankly, I believe the percentage is quite low that most
domains will want to mix up (Break their own policies) screwing around
with operations ONCE they begin to consider DKIM. So if I begin to DKIM
protect our my "high value" domains, rest assured I am not going to be
using them promiscuously in mailing list or in other unknown areas. I
think that is common sense. Don't you?
How are EAI headers protected?
In the same way everything else is. EAI shouldn't break the integrity
of the system just like anything shouldn't.
What must recipients see before an assertion of signature expectation
> offers effective protections for either recipients or the email-address
> domain owners?
None. MUAs are not involved in my DKIM implementation considerations.
They are not required. We are not passing the buck to users.
This question is largely pointless.
So why ask?
There is no way to know what recipients can see.
Sure they do. Its been pretty standard for the last what? 30 years?
FROM
TO
SUBJECT
DATE
BODY
Why make is so difficult?
If the recipient sees a display name or the UTF-8 version of the From
header, what protection is provided by an assertion applying to
different domain?
MUA doesn't apply because the protection, if possible, was done at the MTA.
> None.
Exactly!
Many phishing attempts already utilize altered email-addresses.
Ok, so DKIM doesn't SOLVE everything. No one claim it did. BY the same
token, non-phished domains will be less exploited under a DKIM/SSP
environment and that is a very important and a major step in the right
direction.
Look-alike or cousin domain attempts are unaffected by
assertions of what is signed.
Ok, so what else is new?
Annotations based upon signed messages also found in the recipient's
address-book thwarts these various phishing attempts.
No it doesn't. You still have FUZZY logic involved, especially when the
unknown emerges. If you want to past fuzzy considerations to your users,
by all means, implement what you want into your own SMTP server so that
you can pass on the buck to your users. We are not doing that and I
strongly believe MOST users don't want to baloney sent their way either.
Protection is obtained without recipients needing to take out
> their magnifying glass or make often fruitless queries.
I don't agree. Once the DOUG-SMTP server passes MORE unknown to the
user, you are forcing the user to ponder, to begin scratching his heads,
and in fact, may begin to question the value, sanity and ethics of their
ISP as to why the ISP are passing junk to them, etc.
> At what point does it become clear self authorization schemes
> are pointless in both excessive traffic and easily
> defeated protections.
No point because I don't believe your statement is true. DKIM/SSP is a
wonderful technology, especially for 1st party domain protection. I
firmly believe that and I've seen nothing by you or anyone else that has
proved otherwise.
Causing phishing attempts to be unsuccessful is the best way to quell
this traffic.
And MUAs are suppose to solve this MTA's PASSING the UNKNOWN to them?
On the other hand, an authorization scheme will likely
improve phishing success rates.
I think that is an oxymoron - if you phish, you can't authorize it
because its an UNKNOWN entity. Even if the phisher is DKIM-COMPLIANT,
and this might pass the MTA test, it is no different than having no DKIM
record as well. So why would a phisher have a DKIM/SSP setup? He
doesn't have do this. There is nothing really lost or gain. However,
if its a NON-PHISH. there is a lot of protection value there.
It is possible for plug-ins to be implemented with existing MUAs.
Great. So write it. In the mean time, IMV, I think your suggestion and
proposal:
- Is completely inappropriate as a standard protocol suggestion for MUAs
across the board, it is completely unrealistic.
- lacks the design and vendor considerations in MUA variations,
- lack the design and vendor considerations for necessary MSA/MTA
handling and not passing the buck to end-users,
- is based on concepts typically reserved as "features" not protocol
variables, (i.e, not all MUA will have the same address book outline or
logic you have in mind).
- it unnecessarily requires broad MUAs compliance in order to make DKIM
adledgely effective,
- at a minimum, it is a ADD-ON concept but not one that is required to
make DKIM effective.
I believe you are attempting to push a specific MUA product design on
the industry when it isn't necessary, and it is obviously more harmful
for the user. Even then, are you planning to take over the MUA world to
make sure all systems all work the same?
It is being done now,
What's being done now? DKIM Extensions for MUAs or extensions in general?
> so the MTA vendor don't need to change what they are doing.
You mean I should stop and just wait for DKIM ready MUAs to come to
market? I don't have to do anything with my MSA/MTA/MDA? MFA? Am I
suppose to alter my MUAs using your ADDRESS BOOK design? What about my
online MUA devices? Do you have an extension for that too?
You need to keep your eye on the ball. MUAs are not required for
DKIM/SSP operations. It adds NOTHING more to the process but more cost,
unrealistic considerations and simply put, it won't help DKIM/SSP
process. Your MUA's ideas are simply not required to implement DKIM/SSP.
---
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html