ietf-mailsig
[Top] [All Lists]

Re: DKIM o=$ Outbound Signing Policy Suggestion

2005-07-20 17:25:40

Jim,

I guess, maybe,  not sure.

I say this because who is the "From:" anyway.   Lets take a real possible
scenerio.

user ABC has an account BankXYZ.COM.  The bank is going to send some "high
value mail" to the user ABC.

The user ABC receives and see this mail.   What it is actually in this
email or presented to the user that will give the user the a no-second
thought high trust confidence in the mail?

The AR display?

Unless its inserted in the body, there is no control of the MUA for the
bank.

The From:?

Why?   Maybe the domain part, but the odds are good it may have some "do not
reply" mail daemon account.

        i.e,    no-reply-customersupport(_at_)bankabc(_dot_)com

or it is some 3rd party service bureau?

            customersupport-bankabc(_dot_)com(_at_)servicebureau(_dot_)com

Either way the user doesn't "know this person" per se.  He knows the
company.

Maybe the company will realize that its plays well to be more personal, so a
real contact address is displayed:

            Mary(_dot_)Support(_at_)bankabc(_dot_)com

Nonetheless, regardless of the mail content,  from a transport vendor
standpoint,  all we need to know is how to authorize/authenticate this
message and what to do about it when it fails.

So maybe there is some idea here for the domain to defined how they want
errors to be handled, how to show or not show to users and also report
errors to the company as well.

For all intent and purposes,  the MTA is now part of the Bank's distribution
process when it comes to specific high value email.

Here is another idea that would help "High Value Email"

The company may want an acknowledgement that the user "seen" the message or
has been given access to read the mail. It in other words, it was delivered
to the user.   Not just a simple SMTP accept concept since it is possible
that a post processor can do something with it..   Not a human based
receipt-request concept, but rather a signal or feedback to the bank the
transaction was:

    a) Placed in he user' mail box,
    b) With 100% verification.

This may have some serious positive value for companies with high value
email.

This can always be done separately as a adjunct to DKIM, but it relates to
basically training the DKIM ready MTA to automate the process of handling
DKIM domain failed high valued email.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>


Hector,

Thanks; it's good to get some comment on the SSP document as well.

One thing that occurred to me (prompted by a phone call from a
colleague) is that signing policy really needs to have two dimensions:

1. What signatures are required?  None, third-party, or first-party
(From: address) only?

2. How would the From: address domain like the verifier to treat
failures?  Some possibilities:  Reject outright, warn user, send warning
to r: address (need to be concerned with privacy issues here), etc.

Does this fit with what you have in mind?

-Jim

Hector Santos wrote:

o=$ (High Value Email)

    All mail from the entity is signed; unsigned email
    MUST NOT be accepted, but email signed by a
    third party SHOULD be accepted.  All mail that fails
    verification due to some broken DKIM entity SHOULD be
    reported to company (r=) [before accepting].




<Prev in Thread] Current Thread [Next in Thread>