Re: How about A-R dkim-adsp's "header.from" value?

From: Alessandro Vesely <vesely_at_tana.it>
Date: Tue, 06 Jul 2010 21:23:50 +0200

On 06/Jul/10 20:23, Murray S. Kucherawy wrote:
>> IMHO, for generic filtering, a "header.domain" would be the only
>> required datum for decisions about signatures being or being not
>> author domain ones, and I'd be tempted to use "x-header.domain". Is
>> anything planned for opendkim's filter, about this?
>
> I'm not clear on what you're proposing. What's an example of the case you're trying to cover?

A downstream filter may want to send a report in case a message is
invalid, and, say, the domain is subscribed to some sort of FBL.
Possibly, learning what is the relevant domain would ease its job.

I don't actually have that case: it is just a possibility. Thus, I'm
going to omit that propspec, unless there is an established
alternative that makes sense. Since you said you were going to amend
opendkim, I downloaded the last version (2.1.1), but saw no changes in
that respect. I thought you might just have planned it, hence I'm asking.

FWIW, the behavior I'm going to code provides for the following, in
case of a missing or invalid author domain signature: either do an
action or set a result according to the relevant condition.

  condition => action | result
  -------------------+---------+--------
  nxdomain => reject | nxdomain
  other error => ignore --I write no A-R in this case
  policy=unknown => ignore --nor in this one
  policy=all => reject | fail
  policy=discardable => drop | discard

Reject or drop can be turned into ignore by generic filter options
(i.e. never do that) or specific whitelisting (i.e. based on spf or
another dkim signature). In such cases the filter sets the result.
Oh, and it sets dkim-adsp=pass if it finds one.
Received on Tue Jul 06 2010 - 19:24:00 PST