Florian,

> Is there a dedicated DKIM documentation for amavis? I only found
> information at the "bits and pieces" page

Yes, that's where most of the DKIM-related docs is.
Besides, each newly introduced config settings is documented
in release notes when it was introduced.

> but have a few other
> questions, so before asking this list, I'd like to do RTFM, especially
> if it's not RTF-RFC. :-) Apart from an explanation of the available
> settings, I'm missing the description of the tags.

The DKIM signature tags? You need to read the RFC 4871 section 3.5.
For public key tags see section 3.6.1 of the same document.



> > Well, yes, although 'signing only parts of the body' (tag 'l') is
> > not very useful, as it can too easily be abused. The sooner we
> > forget it exists, the better.
> 
> So, if someone from outside mails to one of my hosted mailing lists,
> and these lists change the subject or add a footer, it's fairly normal
> that the Authentication-Result shows softfail for DKIM, right?

Yes, as received by the final recipient, member of a mailing list.

The content filter before handing message over to a MLM
can add its own Authentication-Result header field, which
would indicate the mail as received by a MLM did have a
valid signature.

> (Of course, if it annoys, I could remove it e.g. with Postfix header
> checks).

Indeed. Apart from saving few lines in a header, removing a
broken signature serves no purpose apart from aestetics.
A broken signature may still be useful in troubleshooting/forensics.

> > If these signatures are from the domain which also run a mailing list
> > (as opposed to a signature of an author of each post), then these
> > signatures should have been added on the fan-out side of their mailing
> > list manager, i.e. after all the mangling of a message has already been
> > made.
> 
> Right now, the messages get signed two times: First of all, when my
> users submit their mail via port 587, then it goes to the mailing
> list, the authentication-result afterwards is broken (because of
> subject and footer), and eventually, all is re-signed again.

Correct.

(btw, we configure all new mailing lists on our mailman not to
mangle the subject and not to add a footnote on non-digest delivery.
This way even the mailman can be transparent to DKIM signatures
of posters.)

> It still
> sounds a bit weird to me, but it basically seems to work. What makes
> me wonder is that the Authentication-Result header is not added all of
> the time when a local user sends to a local list, but that might be on
> purpose?

Authentication-Result header field is only added for local recipients.
Perhaps your mailing list's domain is not considered local?

There is another possibility, namely the last stage may remove a
previous Authentication-Result header field, if it carries the same
domain name. This follows from:

  # RFC 5451: For security reasons, any MTA conforming to this specification
  # MUST delete any discovered instance of this header field that claims to
  # have been added within its trust boundary and that did not come from
  # another trusted MTA. [...] For simplicity and maximum security, a border
  # MTA MAY remove all instances of this header field on mail crossing into
  # its trust boundary.

  $hdr_edits->edit_header('Authentication-Results',
    # delete header field if hostname is the same, keep unchanged otherwise;
    # simpleminded parsing, better match too many than too few
                 sub { my($h,$b)=@_; my($lh)=c('myhostname');
                       $b=~/\b\Q$lh\E\b.*\bamavisd/si ? (undef,0) : ($b,1) });
                     # $b=~/\b\Q$lh\E\b/si            ? (undef,0) : ($b,1) });

  # [...] Border MTA MAY elect simply to remove all instances of this
  # header field on mail crossing into its trust boundary
  # $hdr_edits->delete_header('Authentication-Results');

> > Grep a log (level 2 or higher) and search for  ' dkim: '  (space before
> > and after). These log entries explain the choices made about signing.
> 
> Thanks, I will try that! Right now, my configuration parts look like this:
> 
> == main.cf ==
> smtp      inet  n       -       n       -       -       smtpd -o
> receive_override_options=no_address_mappings
> 
> submission inet n       -       n       -       -       smtpd
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
>   -o receive_override_options=no_address_mappings
>   -o content_filter=amavisfeed:[127.0.0.1]:10026
> 
> amavisfeed unix -       -       n       -       5  lmtp
>     -o lmtp_data_done_timeout=1200
>     -o lmtp_send_xforward_command=yes
>     -o disable_dns_lookups=yes
>     -o max_use=20
> 
> 127.0.0.1:10025 inet n  -       n       -       -  smtpd
>     -o content_filter=
>     -o smtpd_delay_reject=no
>     -o smtpd_client_restrictions=permit_mynetworks,reject
>     -o smtpd_helo_restrictions=
>     -o smtpd_sender_restrictions=
>     -o smtpd_recipient_restrictions=permit_mynetworks,reject
>     -o smtpd_data_restrictions=reject_unauth_pipelining
>     -o smtpd_end_of_data_restrictions=
>     -o smtpd_restriction_classes=
>     -o mynetworks=127.0.0.0/8
>     -o smtpd_error_sleep_time=0
>     -o smtpd_soft_error_limit=1001
>     -o smtpd_hard_error_limit=1000
>     -o smtpd_client_connection_count_limit=0
>     -o smtpd_client_connection_rate_limit=0
>     -o receive_override_options=no_unknown_recipient_checks,no_milters
>     -o local_header_rewrite_clients=
> 
> 127.0.0.1:10027       inet n  -       n       -       -       smtpd -o
> receive_override_options=no_address_mappings
>                                                       -o 
> content_filter=amavisfeed:[127.0.0.1]:10028
> ==
> 
> == amavis ==
> $inet_socket_port = [10024,10026,10028];
> $enable_dkim_signing = 1;
> dkim_key('domain1.org', '20110105', '/etc/amavis/domain1.org.key.pem');
> dkim_key('domain2.org', '20110105', '/etc/amavis/domain1.org.key.pem');
> dkim_key('lists.domain1.org', '20110105', '/etc/amavis/domain1.org.key.pem');
> dkim_key('lists.domain2.org', '20110105', '/etc/amavis/domain1.org.key.pem');
> $policy_bank{'ORIGINATING'} = {
>  originating => 1,
>  smtpd_discard_ehlo_keywords => ['8BITMIME'],
>  final_spam_destiny => D_BOUNCE,
>  final_virus_destiny => D_BOUNCE,
>  final_banned_destiny => D_BOUNCE,
> };
> $policy_bank{'NOCHECKS'} = {
>  originating => 1,
>  smtpd_discard_ehlo_keywords => ['8BITMIME'],
>  mynetworks_maps => [],
>  os_fingerprint_method => undef,
>  penpals_bonus_score => undef,
>  bounce_killer_score => 0,
>  bypass_decode_parts => 1,
>  bypass_header_checks_maps => [1],
>  bypass_virus_checks_maps => [1],
>  bypass_spam_checks_maps => [1],
>  bypass_banned_checks_maps => [1],
>  spam_lovers_maps => [1],
>  banned_files_lovers_maps => [1],
>  dkim_signature_options_bysender_maps => [  {
>  'domain1.org' => { d => 'domain1.org', c => 'relaxed/simple' },
>  'domain2.org' => { d => 'domain2.org', c => 'relaxed/simple' },
>  'lists.domain1.org' => { d => 'lists.domain1.org', c => 'relaxed/simple' },
>  'lists.domain2.org' => { d => 'lists.domain2.org', c => 'relaxed/simple' },
> } ],
> };
> $interface_policy{'10026'} = 'ORIGINATING';
> $interface_policy{'10028'} = 'NOCHECKS';
> ==
> 
> As you can see, I'm still rather new to the DKIM topic. :-) I was
> reading your docs and some mailing list posts and ended up with the
> above configuration, but there might be some glitches in it.
> 
> > Is the 'dkim_signature_options_bysender_maps => ...' syntactically part
> > of a policy bank hash (key/value pairs) ?  If it is not but is a global
> [...]
> At the moment, it is part of a policy bank, but just because I've seen
> that in an example and tried it out, to be honest. :-) Is the global
> approach better?

Use whichever makes more sense in your setup. Loading a policy
bank is cheap, so there is no reason not to use it. But if there is
no need for overriding some setting by apolicy bank, it is probably
more obvious/clean to use a global setting. So, if your overrides
only apply to a mailing list fanout, it's probably alright to keep
them in a policy bank.

> I feel as I'm still missing some basic information and knowledge on
> the DKIM process. Any pointers welcome!

RFC 4871 and RFC 5617 ?

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
AMaViS-user mailing list
[email protected] 
https://lists.sourceforge.net/lists/listinfo/amavis-user 
 Please visit http://www.ijs.si/software/amavisd/ regularly
 For administrativa requests please send email to rainer at openantivirus dot 
org

Reply via email to