Re: [ietf-dkim] list vs contributor signatures, was Wrong Discussion

On Apr 30, 2010, at 5:30 AM, Ian Eiloart wrote:

> --On 29 April 2010 10:58:44 -0600 "McDowell, Brett" 
> <bmcdowell(_at_)paypal(_dot_)com> 
> wrote:
>
> > On Apr 28, 2010, at 2:11 PM, John R. Levine wrote:
> >
> > > > Your proposal that MLM remove Signatures would cause restrictive
> > > > policies to fail.
> > Which is why I oppose this proposal.
> >
> >
> > > Indeed.  I'm assuming that any list that paid attention to ADSP would
> > > sign  its outgoing mail and would expect its recipients to trust it
> > > enough to  whitelist the list's mail.
> > That's quite an assumption.  I would not make that same assumption as we
> > chart out new/better mechanisms for MLM's to handle DKIM-signed mail.  It
> > will be true in some cases, and false in others.  All for valid reasons
> > we should seek to account for.
> An MLM in receipt of a properly signed message "from" a domain with ADSP 
> policy "discard" has a few options:
>
> 1. Forward the message to the distribution list unaltered, such that the 
> signature remains intact. This might surprise some recipients, and may be 
> an exception to normal list policy. On the other hand, it might be feasible 
> if the list normally doesn't alter the subject or body.
>
> 2. Break the signature, and forward the message in the knowledge that 
> recipients may discard it.
>
> 3. Break the signature, then discard the message.
>
> 4. Bounce the message, on the grounds that it may not be deliverable once 
> the signature is broken. The DKIM signature should mean that it's safe to 
> bounce the message back without risking collateral spamming, at least when 
> the return path is in the same domain as the "From:" header.
>
> 5. Reject the message at SMTP time, with an appropriate 5xx error code. 
> Similar to above. Safer when the return path domain doesn't match the 
> "from" address domain.
>
> I don't think I like (2) and (3).
I think this helps frame the discussion.  It's highly related to Steve's post 
that Dave so rightly re-posted for re-consideration.  People on this list are 
advocating various options, but oddly enough I think this is the first post on 
the thread that tried to summarize all options.  

FWIW, I don't like #2 or #3 either.  

There's been some debate on this list regarding option #1 and it seems to be a 
non-starter for MLM operators.  Actually, I've recently been joining a lot of 
new mail lists and some are configured like option #1 and I cannot stand them 
as a user.  So I'd say option #1 might be an elegant/simple solution but I 
personally wouldn't want to see mail lists behave this way.

Options #4 and #5 seem closely related to what Steve was advocating when he 
brought up the value and role of FBL's could play in the original use case 
which John L. provided (before I threw in my use case in reaction to Murray's 
report on MLM re-signing discussions at IETF 77).  I think they are all related 
because they all seem to fall into the category of "I, the MLM, am not going to 
deliver the mail, but I'm going to provide some failure information to the 
appropriate parties in the most useful form I can".  

> From Steve's message:
<snip>
> >  Wouldn't
> > it be a better idea to avoid the guessing?
> Yes, by notifying all the responsible parties who have set up a
> DKIM based FBL and who have valid DKIM signatures on the
> message.
>
> Part of the overhead of handling an FBL is to decide which
> reports to pay attention and which aren't. In your case you'd
> (probably) want to ignore any reports about mail sent from
> your legitimate users via mailing lists, via some heuristic that
> works for you.
>
> But you're the only one who can make that decision, so you
> can't push that decision off on to Yahoo or mailing list providers
> in general. I don't want them to make the decision to not
> send reports to responsible parties who do want the reports
> and can handle them.
>
> It's not too hard for anyone handling inbound FBL streams
> to categorize them mechanically, and automate their policies
> to ignore reports they believe are irrelevant, so the overhead
> for this sort of FBL report is low. If the mailing list manager strips
> signatures, they lose a source of data and don't get to make
> that decision.
>
> (As for reputation - a big part of reputation is the content that
> is sent. If a particular list subscriber consistently sends mail
> that other list subscribers complain about then it's not
> unreasonable that that may damage the reputation of that
> particular list subscriber as well as that of the list.)
>
> Cheers,
>   Steve
</snip>

I think the role of DKIM FBL's needs to be discussed more on the list.  Not 
only does it directly impact the first use case John L. introduced, but it 
could add a dimension to the second use case (X-Y-Z) that's been overlooked 
thus far.

Option #6:
I don't think this summary captures the MLM re-signing option Murray and I have 
been somewhat advocating for.  So I want to get that on the table in this 
summary.

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