Re: [exim-dev] [exim] DKIM vs DomainKeys

Pàgina inicial
Delete this message
Reply to this message
Autor: Magnus Holmgren
Data:  
A: exim-dev
Assumpte: Re: [exim-dev] [exim] DKIM vs DomainKeys
On Sunday 21 January 2007 15:40, Kjetil Torgrim Homme wrote:
> On Sat, 2007-01-20 at 16:29 +0100, Magnus Holmgren wrote:
> > In DKIM, however, the signing identity is found only in the signature
> > field. This means that there can be any number of valid (and invalid)
> > signatures.
> >
> > A reasonable way of handling that could be to let the ACL conditions
> > succeed if any valid signature matches:
> >
> > dkim_sender_domains = <domain list>: Succeeds if any valid signature is
> > made by a domain in the list.
> > dkim_senders = <address list>,
>
> right, so we could write
>
>   dkim_senders = ${if def:h_Sender: {${address:$h_Sender:}} \
>                                     {${address:$h_From:}}}

>
> to get DomainKeys-like behaviour. (this ignores the possibility of From
> containing more than one address. see below.)


Well, yes, *if* we want that. The fact that the Sender field has to be
clobbered by MLMs and other software that alters messages if they wish to
re-sign them is a problem with DK, and it should not be expected that the
signing identity be found in the Sender or From fields. However, it's still a
test that may be useful, as long as it isn't ground for rejection.

> > The expansion variables could represent the earliest valid signature.
> > It's of course possible to have a $dkim_senders containing a
> > comma-delimited list of all valid signature identities, but Exim has no
> > good built-in mechanism for looping over comma-delimited lists of
> > addresses, except in filters (foranyaddress). The best option probably is
> > ${perl ...}. So, probably some new expansion conditions might be needed.


> ${extract can use an arbitrary delimiter, but we lack the looping
> construct. perhaps a new kind of require keyword, which takes an ACL
> and a list?


There are now a number of looping constructs in progress, which should be
adequate, whether $dkim_senders is an addresslist (colon-separated) or an
address-list (comma-separated).

> as for the list: both comma and space can be used validly in an e-mail
> address, so we need an operator which understands quoting and dequotes
> each element. consider the following list of three addresses:
>
>         set acl_m0 = foo@bar : gazonk@zot : "<\"some::weirdo\"@quux>"

>
> I used colon as the separator in the above to mimic the normal syntax
> for lists in Exim. we can extend it like so:
>
>     set acl_m0 = $acl_m0 : ${quote:$sender_address}


Hmm, nah, quote doesn't work quite right here. It puts the whole string inside
quotes, not just the local part, does that when it's not necessary, and
doesn't double colons.

> to loop over it, I suggest this new ACL verb:
>
>     require_list = acl_check_element $acl_m0

>
> the ACL named acl_check_element would be called four times, with the new
> variable $list_element (or somesuch) set to the dequoted element value.
> this function should be made available as a more advanced ${extract for
> general use, e.g.:
>
>         ${extract_quoted{4}{:}{$acl_m0}}

>
> would return
>
>         <"some::weirdo"@quux>


Shouldn't that be <"some:weirdo"@quux>? I thought the colon was doubled so as
not to confuse it for a list separator in the list further up.

Calling an ACL to evaluate a single variable doesn't quite make sense to me.
Calling an ACL once for each DKIM signature found, without explicitly
invoking it through that require_list condition, would make more sense. In
that case, dkim_senders, dkim_domains, and dkim_local_parts would all be
meaningful as they would only test one signature at a time.

Yes... it all becomes clear to me... then we don't have to come up with a
single overall result for all signatures, and all the ACL conditions and
expansion variables that exist for DK today will work with DKIM. This is
probably the way to go.

The alternative might be a big $dkim_signatures variable containing a list of
attr="value" pairs, to be used with forany/forall/map/reduce and extract.

> finally, we now have the infrastructure to make an ${address operator
> which returns a list when the header contains more than one address.
> given:
>
>         To: foo@bar, Frank Zot <gazonk@zot>, <"some::weirdo"@quux>

>
> ${address_list:$h_To:} should now return:
>
>         foo@bar:gazonk@zot:"\"some::weirdo\"@quux"


There is now a suggested patch that implements exactly this as the "addresses"
expansion operator.

-- 
Magnus Holmgren        holmgren@???
                       (No Cc of list mail needed, thanks)


"Exim is better at being younger, whereas sendmail is better for
Scrabble (50 point bonus for clearing your rack)" -- Dave Evans