Subject: Re: [ietf-dkim] SSP and mailing lists

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Sep 2006 21:06 -0400

On Mon, 11 Sep 2006 13:24:20 -0700 Steve Atkins <[email-masked]> wrote:

>Or you could just use S/MIME.

-1.  As has been discussed here several times, S/MIME has already failed in 
the marketplace.  While this is, in theory true, in practice the level of 
complexity associated with this is daunting.  Currently one of my main 
customers is about 9 years into a 5 year project to do just that.

Scott K
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 Sep 2006 21:02 -0400

On Mon, 11 Sep 2006 15:06:45 -0500 wayne <[email-masked]> wrote:
>In <[email-masked]> Stephen Farrell 
<[email-masked]> writes:
>
>>> "I sign all email, and do NOT permit email through any body or
>>> signature altering gateways"
>>
>> I've no idea how a sending domain could enforce the "do NOT permit"
>> there. Neither in practice, nor in principle. Does anyone? (This may
>> just be my own ignorance of course, I don't claim to be a mail
>> expert.)
>
>Well, you can't 100% enforce a "we don't send to mungers" requirement
>any more than you can enforce a "we sign all email" requirement.
>There are a lot of fairly easy steps you can take though:
>
>1) If you can, set up domains such as accounts.bigbank.com that have
>   no user mailboxes and is only used to send transactional email to
>   customer accounts.
>
>2) If you use domains where there are user mailboxes, have corporate
>   policies that you can't sign up for mailing lists and such.  If
>   anyone violates the rule, deal with them the same way you would any
>   other violation of customer policies.
>
>3) When a customer gives you an email address to use, send a test
>   email to them to verify that it is valid.  To activate, make them
>   either forward the email back or have them cut and paste it into a
>   web form, very similar to how spamcop has dealt with the "mailhost"
>   configuration stuff for several years now.
>
>4) When you find out that there are problems sending email to $customer or
>   $domain, work with the customer/mail-admin to fix the problem, and
>   if it can't be fixed, disable sending email to $customer and/or
>   $domain.
>
>Of course, you also have to do all the work to make sure that all your
>email is signed, that all your MTAs are working right, that employees
>working at home don't send through their ISPs, that you don't use
>greating-card/send-news-article stuff, etc.
>
>
>Yes, this is a bunch of extra work that most will not be willing to
>do, but I don't expect everyone to do it.  This is also the kind of
>work that the receiver can not easily tell if the sender is doing or
>not, but which the receiver can find very useful in deciding whether
>they should accept or reject an email that has been munged.  So, this
>is exactly the kind of information that needs a way for the sender to
>communicate with the receiver about.  It benefits both parties.

+1.  I would like to get e-mail from such a bank.

Scott K