Re: [ietf-822] Aptness of DKIM for MLs

[Hector Santos <[e-mail]>]

Alessandro,   I believe what SM meant, is that every list developer 
has its own level of change needs and for the most part, in my view, 
you really don't want to make big changes to your mail framework when 
adding DKIM.  Its complex. But for an integrated system when you  have 
more controls of all the part, its doable. Take a look at our wcDKIM 
integration with our wcListServer component.

    http://www.winserver.com/public/files/wcdkim-ssi.png

But in general, the main reason there is a general issue/problem with 
the general LS is because DKIM was added at the edge so it can 
"blindly" sign all the outbound mail.  The key word here is "Blindly."

Overall,  the MLS change requirements to make the MLS more "fitting" 
with the blind DKIM signer component is:

1) Subscription controls for restrictive domains,
2) Submission controls for restrictive domains, and
3) "Meta" information to tell the signer not to sign a particular list.

Where and how those things are done will vary.  Unless the MLS 
developer does it himself, it will be asking much of list operators to 
handle this complexity themselves.  So makes you understand why is far 
easier for the LSP (List Service Provider) and/or resigner market to 
just ignore all Author Domain Signing Practice protocol and just allow 
for a complete open ended DKIM signing network when perhaps the only 
signature that matters most, is that last one in the transport chain 
and as long as the receiver trust the last signer, it really doesn't 
matter what the author does or the previous resigners had done.

Unfortunately, its a GOOD versus BAD framework.  With the signer 
trust, you can only look for the GOOD. It doesn't know how to handle 
the BAD and that is what the author domain signing protocols attempts 
to address and the trust folks keep forgetting or don't wish to deal 
with -- the bad legacy spoofing/phishing mail that Trust people can't 
do anything about.

-- 
HLS

On 5/9/2014 6:23 AM, Alessandro Vesely wrote:
> Hi SM,
>
> On Thu 08/May/2014 19:59:19 +0200 S Moonesamy wrote:
>> At 03:06 07-05-2014, Alessandro Vesely wrote:
>>> to "standardize" its syntax.[3]  It seems to me that eliminating some
>>> of such gratuitous changes is the solution to DMARC-for-MLs which
>>> minimizes the alterations in MLM software.  Are you sure it won't
>>> work?
>>
>> This mailing list breaks the DKIM Signature.
>
> No, it doesn't.  It broke elandsys' signature, but check tana's
> signature on this message.  (I send this to ietf-822 only, to avoid
> any confusion.)
>
> So it seems I could publish a strict DMARC policy right now, and cause
> minimal disruptions.  However, some verifiers (NetEase) consider
> tana's h= inadequate, see "objection" below.
>
>> Gratuitous changes to a mailing list message is a matter of
>> opinion.
>
> Well, not exactly.
>
> For corrections, section 6.4 of RFC 5321 is rather clear that
> submission servers MAY, while intermediate relays MUST NOT, apply
> certain changes.  So the range where opinions may vary is whether an
> MLM is to be considered akin to submission servers or relays.
>
> By /gratuitous/ changes, such as adding/removing double quote marks, I
> mean unnecessary embellishments that were already disputable before
> DKIM took root.
>
>> I suggest reading the past discussions first if you are interested
>> in trying to make it work.
>
> Yes, much of this discussion was recited at the time of ADSP, for
> example http://mipassoc.org/pipermail/ietf-dkim/2010q3/013829.html
>
> The most relevant objection to weak signatures is why would domains so
> concerned about security as to publish a strong policy weaken their
> DKIM signatures?  A solution is to do so for ML messages only.
>
> To recap, assume a domain has a DB of (user, mailing list) pairs which
> defines ML traffic.  Messages to ML are then sent in separate SMTP
> transactions and weakly signed.  MLMs sign those messages in turn,
> using strong signatures.  Verifiers derive the validity of MLM domains
> by comparing d= against To: or Cc: mailboxes.
>
> Besides minor refinements, the major bar is to build that DB.  I
> proposed to do it manually for starting, and then find out how to
> automate its maintenance.
>
> Ale
>