Dan,

> Hi, I have questions regarding the suggestions on
> http://www.ijs.si/software/amavisd/amavisd-new-docs.html regarding
> "Putting policy banks to good use -- examples", and I am a little
> unclear how it is supposed to work.
>
> I'm specifically looking at Example 3 in the policy bank.
>
> The configuration shown is:
>
> main.cf:
> content_filter=smtp-amavis:[127.0.0.1]:10044
>
> smtpd_recipient_restrictions =
>   reject_unauth_pipelining, reject_non_fqdn_recipient,
>   reject_non_fqdn_sender,
>   reject_unknown_recipient_domain, reject_unknown_sender_domain,
>   check_client_access cidr:/etc/postfix/filter-mynets.cidr,
>   permit_sasl_authenticated, permit_tls_clientcerts,
>   reject_unauth_destination,
>   check_sender_access regexp:/etc/postfix/filter-catchall.regexp
>
> /etc/postfix/filter-mynets.cidr :
> 127.0.0.0/8    FILTER smtp-amavis:[127.0.0.1]:10042
> 10.0.0.0/8     FILTER smtp-amavis:[127.0.0.1]:10042
> 172.16.0.0/12  FILTER smtp-amavis:[127.0.0.1]:10042
> 192.168.0.0/16 FILTER smtp-amavis:[127.0.0.1]:10042
>
> /etc/postfix/filter-catchall.regexp:
> /^/            FILTER smtp-amavis:[127.0.0.1]:10040

> In my case, I want to do this for DK/DKIM.  I want to have all outgoing
> mail signed (from mynetworks and non-local authenticated mail), but not
> mail destined for a local address (even if from mynetworks or auth).
>
> Am I just confusing myself for no reason?  It probably isn't a problem to
> be signing those auth-to-local and mynetworks-to-local mails, but if it
> doesn't have to go through that step it reduces the latency a bit.

You could save a little, but probably is not worth the trouble.

Would you be signing by a dedicated signing milter, or by dkimproxy?

Btw, there is another example further down using policy banks,
specifically illustrating DKIM signing and verifying.

The main idea is to decide early in MTA what mail will need to be signed,
and route it through dedicated path through a content filter and milters.

> I thought this example was almost exactly what I needed, except that I
> think I could still use permit_mynetworks rather than the
> check_client_access because the global filter would be the DK/DKIM
> signing path and the non-global filter would be the incoming version
> without DK/DKIM signing.  So with:
>
> main.cf:
> content_filter=smtp-amavis:[127.0.0.1]:10044
>
> smtpd_recipient_restrictions =
>   ...
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   ...
>   check_sender_access regexp:/etc/postfix/filter-catchall.regexp
>
> /etc/postfix/filter-catchall.regexp:
> /^/            FILTER smtp-amavis:[127.0.0.1]:10040
>
> mails originating from mynetworks and all authenticated mails go off to
> be signed by DK/DKIM and the rest, identified by the final
> check_sender_access will get the custom FILTER action.

Ok.

> My confusion about the example as posted is the following line from that
> page:
> "The final effect is that ... authenticated non-local mail will be sent
> for content filtering to port 10044 (the global setting), while all the
> rest will be sent to port 10040 (as specified in catchall filter)."  I
> don't understand how "authenticated non-local mail will be sent for
> content filtering to ... the global [content filter]".
>
> I can see from this config how ALL authenticated mail gets sent to the
> global content filter, but I don't see how it is only NON-LOCAL
> authenticated mail that gets sent to the global content filter, as the
> page states.

  check_client_access cidr:/etc/postfix/filter-mynets.cidr,
  permit_sasl_authenticated, permit_tls_clientcerts,
  reject_unauth_destination,
  check_sender_access regexp:/etc/postfix/filter-catchall.regexp

Because 'check_client_access cidr:/etc/postfix/filter-mynets.cidr'
is located _before_ the sasl/tls stuff, it diverts content filter
to 10042. Actually mail from mynets still does reach the sasl/tls rules,
but its FILTER sticker remains attached.

> Mails matching the check_client_access (from mynetworks) 
> gets sent off to a non-global FILTER.

Yes, and the FILTER sticker says with the mail, it overrides
the content_filter setting.

> The next line is 
> permit_sasl_authenticated, which seems to send ALL authenticated mail
> to the global filter, not just NON-LOCAL authenticated mail.

No, it just stops further search, keeping whatever FILTER sticker
placed by earlier rules.

> So my question I guess is how do I differentiate between local and
> non-local mails that come in via mynetworks or auth, or am I missing
> something obvious?  Do I need to abandon the global filter and use the
> lookup FILTER action for all?  If so, how do I do that with
> permit_sasl_authenticated?

I believe it makes more sense now.



There is one problem I don't know how to solve (looking at the
  http://www.ijs.si/software/amavisd/amavisd-new-docs.html#dkim
example), namely if there are _early_ rules in smtpd_recipient_restrictions 
that explicitly allow stuff, like:

  check_recipient_access pcre:/usr/local/etc/postfix/permit_rcpt_to_postmaster

(or to spam lovers, at a MTA level) then futher routing goes astray,
mail is delivered to an ORIGINATING route. If the only purpose
of the ORIGINATING policy bank were to route further to a signing backend,
it is no big deal, just some wasted cycles. But if other overrides would
be desired in this policy bank, it's name becomes more obviously 
inappropriate.

I guess the advice in this case should be sought on the postfix-user ML,
although I fear the verdict would be to use a multiple-instance setup.

  Mark




-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to