Re: [ietf-dkim] incremental vs. infrastructure adoption
2006-11-25 00:26:29
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.
Are you suggesting that my statement was incorrect?
If so, how? Please remember that the topic was as stated in the Subject line
and my comment was in that context.
Q. "My cousin John, who uses the same bank as me, gets nice "SAFE" logos
on his bank messages. I don't see them. Should I be worried?"
A. "You need to use a different MUA."
There is a new car that automatically performs parallel parking. Is there some
sort of problem creating by observing that you get that feature only by buying a
different car?
Or a different end-user feature by using a different MUA?
In other words, if your example is intended to be cautionary, please clarify,
with substantial detail.
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?
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. By way of example, note that web page designers
actually do have a wide variety of pages, with the same content, designed for
different devices and browsers. 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.
That said, of course, simplification is the reason competitors collaborate on
unified protocols.
But again, I find myself not understanding how your point is responsive to the
discussion in this thread. Perhaps my commenting that standardization was not
required was taken to mean that standardization is not a huge win? Gosh I hope
no one thinks I would believe such a thing...
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. (It might
be generated at presentation time or it might be added to the message within the
trust domain, but that is a minor point, I think, for this discussion.
User-visible safety indicators are typically viewed as the realm of the
delivering ADMD and not of the message as it is received from the open Internet.
In that context, how does your described threat survive?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
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, Powers, Jot
- 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
|
|
|