Re: [ietf-dkim] incremental vs. infrastructure adoption
2006-11-28 06:47:21
On Sat, 25 Nov 2006 04:52:11 -0000, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
Charles Lindsey wrote:
A whitelist is useful as soon as a single recipient (filter, user,
whatever) can apply it.
Be careful there. We want people out there to welcome and accept these
protocols when they start to be deployed. A huge spate of false
positives and false negatives will rapidly cause it to come into
disrepute and to wither. This is not a technical problem - it is a
social problem, but we ignore it at our peril.
I do not see how your statements relate to the one of mine to which you
appear to be responding.
Just that if a feature is deployed with an inadequate infrastructure to
support it, it may make matters worse initially, and so bring the whole
idea into disrepute.
Q. "I bank with Bank of America. I always used to get those "SAFE"
logos. Now they have suddenly stopped".
A. "I see from your headers that you are on holiday in the Netherlands
Antilles. The ISP you are using there doesn't use whitelists for
American Banks - just for the Bank of the Antilles and ABN/AMRO."
This, I think, is a very interesting example, conceptually.
The detail you supply, however, is confusing. Your sentence beginging
"The ISP..." does not make sense to me.
I guess that you are presuming that all of the relevant email functions
are under control of the local-access ISP and that, therefore, when
traveling, I might get a different MUA?
You have connected your laptop to the system provided by the person you
are staying with, the conference organizers, the hotel, or whatever. Or
perhaps you are without your laptop and are a guest on someone else's
system. And the system you are connected to just just not provide the
particular set of whitelists you were used to back home.
Although true, there is no requirement that it be "standardized".
Different existing lists have different access methods.
No implementor of the popular MUAs is going to invest effort in
implementing this "SAFE" Logo if there are lots of different protocols
which might be used.
Statements containing firm absolutes, when they involve human
decision-making, tend to be problematic..... That such a situation is
absurd and often does not work correctly is not the point. The point is
that I believe it disproves your absolute.
My statement does not need to be absolute to reflect the likely
consequence of trying to implement whitelists piecemeal.
You can't do it in the headers, because Bad Guys can write headers
too.
Not when the headers are signed. (eg, <http://goodmailsystems.com>.)
And there you gave a good answer (and it also brings the thread back
on topic :-). OK, such schemes are possible. But the Bad Guy can still
insert the "SAFE" header and sign it, so there is still work for the
verifying agent to do by way of spotting such already present headers
and acting accordingly. .
Typical discussions, about such indications of safety, distinguish
between what is carried in the message, across the Internet, versus what
is generated within the trusted Administrative Management Domain (ADMD)
of the recipient.
If you are wanting that "SAFE" logo to appear on your MUA when a
whitelisted email is received, then that information has to be
communicated somehow from the site that checked the whitelist (which is
usually in a diferent ADMD to yourself). That means it must be possible to
communicate it by SMTP (you cannot assume that everybody uses POP3 or IMAP
to access their mail, and even there it would need upgrades to those
protocols).
The only place in SMTP to hide it is in the headers of the message. So
those would have to be signed, which means verifying capability in the
MUA, together with means to spot alleged signings by the Bad Guy. This is
all, in principle, doable (that is how the 'Padlocks' on web browsers
work), but it will not be a simple system to set up and deploy.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] Collection of use cases for SSP requirements, (continued)
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Jeff Macdonald
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Dave Crocker
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Charles Lindsey
- Re: [ietf-dkim] Collection of use cases for SSP requirements, John Levine
- RE: [ietf-dkim] Collection of use cases for SSP requirements, Bill.Oxley
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Steve Atkins
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Charles Lindsey
- [ietf-dkim] incremental vs. infrastructure adoption, Dave Crocker
- Re: [ietf-dkim] incremental vs. infrastructure adoption, Charles Lindsey
- Re: [ietf-dkim] incremental vs. infrastructure adoption, Dave Crocker
- Re: [ietf-dkim] incremental vs. infrastructure adoption,
Charles Lindsey <=
- [ietf-dkim] Re: Collection of use cases for SSP requirements, Frank Ellermann
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Steve Atkins
- Re: [ietf-dkim] Collection of use cases for SSP requirements, John Levine
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Dave Crocker
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Michael Thomas
- Re: [ietf-dkim] Collection of use cases for SSP requirements, David Sanchez
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Steve Atkins
- Message not available
- Re: [ietf-dkim] Collection of use cases for SSP requirements, David Sanchez
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Charles Lindsey
- Re: [ietf-dkim] Collection of use cases for SSP requirements, Dave Crocker
|
|
|