[ietf-dkim] SSP and mailing lists

[Steve Atkins]

On Sep 11, 2006, at 1:06 PM, wayne wrote:

> In <4505B4D8.1040705 at cs.tcd.ie> Stephen Farrell  
> <stephen.farrell at cs.tcd.ie> 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.

Or you could just use S/MIME.

DKIM+SSP is not the only tool in the toolbox. Perhaps this is
one of the situations for which it isn't the right tool? If so, we
shouldn't blunt the tool we're developing to make it just barely
usable for a problem where a different tool would be more
appropriate.

Cheers,
   Steve