On Sep 11, 2006, at 1:24 PM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
I will open a session on port 25 at mx.cs.tcd.ie and hope that the
receiving mta does not add its own sig to the message before
depositing it to the inbox. Local rules might require the
additional sig to ensure that the inbox only gets mail from the
edge mta. Now if Stephen is using one of Doug's dkim aware MUA's
that "see's" 2 signatures where only one should be might flag the
message with a red warning "suspicious mail lies here" or inform
Stephen that the message was deleted because the SSP didn't match.
It is likely the initial method of retaining email-addresses will be
through third-party lists. People are normally selective about what
they place in their address-book, and that too can be a source of
retained email-addresses. Perhaps the third-party list comparisons
get a gold-star, and the address-book comparisons get a silver-star.
One might view retained email-addresses as being a form or
reputation, but this will likely be something more along the lines of
knowing their identity. These domains may send a ton of spam and
have a bad reputation from that aspect, but DKIM still allows safe
transactions with this entity. As such, one should be reticent at
describing this as a reputation list. It is not, at least not in the
classic sense of an email reputation list.
When placing annotations upon email-addresses recognized as matching
a retained email-address, other email-addresses do not require
signature validations as there would be nothing gained in doing so.
In addition, a signature not associated with the email-address would
not be verified either. It would not matter if there were ten
signatures added to the message, only the signature assuring the
email-address is valid would be verified. As long as that signature
is not damaged, the message can be annotated with a star next to the
address.
There would not be any warnings needed when other signatures are
added to the message. In fact, just as with the web browser, without
the lock-icon in the corner of the window, most people are
conditioned not to enter critical data. Of course people should also
check the identity of the certificate that validated the lock, and
the star annotations can work in the same manner.
Again, the critical aspect of offering annotations would be observing
semantics that indicate the signing domain has validated the email-
address. A signing domain may sign messages where the email-address
is not validated, and these email-addresses should not receive an
annotation. When there is some explicit association made via policy,
one might assume only valid email-addresses are signed, but having an
assurance made directly by the signing domain would improve upon
security.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
