Re: whitelisting mime_header_checks whith extra smtpd and cleanup in master.cf

[Noel Jones]

On 5/27/2016 3:51 AM, Konstantin Kletschke wrote:
> Hi,
> 
> I wonder if there is a mechanism to implement a function to whitelist
> mime_header_checks or not.
> 
> I read this is not possible, I also read this is possible with separate
> cleanup (because header_checks and mime_header_cheks belongs to
> cleanup)
> and smtpd in master.cf... 50:50

The separate cleanup+header_checks must listen on a different IP:port.

You'll need to arrange with the sender to use the alternate IP:port
rather than your normal MX:25, or use firewall tricks to redirect
the sender to the alternate IP:port.  Both these are inconvenient
and prone to breakage because they're different from normal mail flow.

So... whitelisting (mime_)header_checks is not possible without
fragile infrastructure changes that don't scale well.  And it's not
really whitelisting, it's exempting specified clients from any
header_checks.


> 
> I have a mime_header_checks statement in my main.cf rejecting mails
> with
> specific attachements. Some hosts sending these attachements on
> purpose needs to be whitelisted. So I implemented this in main.cf:
> 
> header_checks=pcre:/etc/postfix/whitelist
> mime_header_checks=regexp:/etc/postfix/blocked_attachements
> 
> /etc/postfix/whitelist looks this way:
> 
> /from@mail\.address/ FILTER smtp:[127.0.0.1]:10027


That can't work because the blocking header_checks have already run.
  FILTER specifies the next-hop *after* the mail is received and queued.

Use amavisd-new or similar content/proxy/milter/filter to apply
different policies to different senders.


  -- Noel Jones

Re: resolve local domain with MX records

[Wietse Venema]

Please read my email again. Postfix does not use DNS do decide what
domains to ***receive*** email for; you must specify those domains
with mydestination, relay_domains, vrtial_alias_domains or
virtual_mailbox_domains.

Of course Postfix will use DNS to decide how to ***deliver*** mail.
Sending email without DNS would be problematic.

Wietse

Re: resolve local domain with MX records

[Zalezny Niezalezny]

Hallo Vietse,

thank You very much for Your support and Postfix!

I have one more question, maybe here You will be also able to help. You
said that "Postfix will not look in DNS...".
Our E-mail environment base on Postfix and Exchange and we are using local
domains to balance E-mail traffic between nodes.

If DNS look up is only intentional, then how to properly configured SMTP
relay ? In my environment E-mail is going thru several network zones to
different departments and in most cases everything is configured using
/etc/postfix/transport table.


domain.com   relay:mydomain.local


Internal domain with MX records is kind of loadbalancer (with high
availability) in that case. So how to properly route E-mails to different
domains where each department has 2-3 mail servers.
In the configuration files, should I specified "IPs" with comas etc.etc. ?


Thank You in advance for any hint.


Zalezny


On Fri, May 27, 2016 at 2:53 PM, Wietse Venema  wrote:

> By design, Postfix will not look in DNS to find out what domains
> it should receive mail for. This is intentional, so that Postfix
> behaves predictably when some network infrastructure is down.
>
> Postfix configuration requires that you configure ALL domains that
> Postfix receives mail for with mydestination, relay_domains,
> virtual_alias_domains or virtual_mailbox_domains.
>
> Wietse
>

resolve local domain with MX records

[Zalezny Niezalezny]

Hi Everyone,

in my Postfix I have configured something like this:


/etc/postfix/main.cf
# ###
smtpd_sender_restrictions =
check_sender_access regexp:/etc/postfix/check_sender_regexp
# ###

/etc/postfix/check_sender_regexp
# #
/.*@domain.com/ FILTER relay:mydomain.local
# ##


mydomain.local - its local domain in our internal environment which include
3 x MX records


How should I write the rule in /etc/postfix/check_sender_regexp, to force
Postfix to resolve MX records from "mydomain.local" and choose one of them
to deliver message ?


With current configuration all the time I getting following error:

Remote Server returned '< #5.3.0 X-Postfix; unable to look up host
mydomain.local: No address associated with hostname>'



How to properly configured ?



Thanks in advance for any hints.



Cheers

Zalezny

Re: Postfix relay - allow authenticated users from any ip

[Zalezny Niezalezny]

Thank You very much for Your explanation. That sounds more clear for me.
I will configure SASL Auth then.

Thanks a lot every one!

On Fri, May 27, 2016 at 2:14 PM, /dev/rob0  wrote:

> On Fri, May 27, 2016 at 10:11:59AM +0200, Zalezny Niezalezny wrote:
> > What about user ? Do i need to create simply OS user (/etc/passwd)
> > and it will be enought ? Or some dedicated configuration file is
> > required ?
>
> If you take Victor's advice and use TLS certificate validation, no
> user is necessary.
>
> If you choose the SASL AUTH way, yes, you need some kind of user
> configured that your SASL backend[s] can authenticate.  A system
> user would be the easiest way to do this.
>
> For SASL, you'd need Cyrus SASL on the client side, and either of
> Cyrus or Dovecot on the server side.  I agree with Victor in that
> check_ccert_access sounds simple and easier in this case.
> --
>   http://rob0.nodns4.us/
>   Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
>

Re: Postfix relay - allow authenticated users from any ip

[/dev/rob0]

On Fri, May 27, 2016 at 10:11:59AM +0200, Zalezny Niezalezny wrote:
> What about user ? Do i need to create simply OS user (/etc/passwd) 
> and it will be enought ? Or some dedicated configuration file is 
> required ?

If you take Victor's advice and use TLS certificate validation, no 
user is necessary.

If you choose the SASL AUTH way, yes, you need some kind of user 
configured that your SASL backend[s] can authenticate.  A system 
user would be the easiest way to do this.

For SASL, you'd need Cyrus SASL on the client side, and either of 
Cyrus or Dovecot on the server side.  I agree with Victor in that 
check_ccert_access sounds simple and easier in this case.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: whitelisting mime_header_checks whith extra smtpd and cleanup in master.cf

[Wietse Venema]

Konstantin Kletschke:
> Hi,
> 
> I wonder if there is a mechanism to implement a function to whitelist
> mime_header_checks or not.

Postfix header/body_checks are blunt tools, primarily to block known
bad email that no-one should receive.

For fine-grained content management, use amavisd-new, perhaps as a
before-queue content filter (smtpd_proxy_filter). It supports
different policies for different email contexts.

Yes, it is possible to use different header/body_checks on different
IP addresses. Unfortunately, I do not have time to debug configurations
based on fragments.

Wietse

whitelisting mime_header_checks whith extra smtpd and cleanup in master.cf

[Konstantin Kletschke]

Hi,

I wonder if there is a mechanism to implement a function to whitelist
mime_header_checks or not.

I read this is not possible, I also read this is possible with separate
cleanup (because header_checks and mime_header_cheks belongs to cleanup)
and smtpd in master.cf... 50:50

I have a mime_header_checks statement in my main.cf rejecting mails with
specific attachements. Some hosts sending these attachements on
purpose needs to be whitelisted. So I implemented this in main.cf:

header_checks=pcre:/etc/postfix/whitelist
mime_header_checks=regexp:/etc/postfix/blocked_attachements

/etc/postfix/whitelist looks this way:

/from@mail\.address/ FILTER smtp:[127.0.0.1]:10027

Then I appended in master.cf the following:

wl-cleanup unix n - n - - cleanup
   -o header_checks=
   -o mime_header_checks=
127.0.0.1:10027 inet n - n - - smtpd
   -o cleanup_service_name=wl-cleanup

What now happens is the following:

Without my whitelist header_checks statement (master.cf modification
does not kick in) the mail comes in and gets filtered by cleanup
"Message content rejected" -> OK

With my whitelist header_checks
statement I see an additional line in the logfile with statement
"filter: " and its argument is, it is routed to 127.0.0.1:10027, looks
fine so far.

But then comes a log line from postfix/cleanup yielding in "Message
content rejected" -> NOK

What I wonder is, is this ought to be working anyway? I see snippets in
internet of customized -o cleanup_service_name= appended to smtpd or
submission or pickup statements, which is the correct one?

Additionally, if my "-o cleanup_service_name=wl-cleanup" would kick in,
should next cleanup log line entry in mail.log not be named something 
like

coming from

TIMESTAMP postfix/wl-cleanup [PID] ?

For example, there is a (rather ancient) mail thread from 2010

http://thread.gmane.org/gmane.mail.postfix.user/215219

where its said half/half: a) it only works with two instances and b) a
suggestion of the above way...

Kind Regards
Konstantin Kletschke

Re: Postfix relay - allow authenticated users from any ip

[Zalezny Niezalezny]

Hi Viktor,

thank You very much for Your hints.

What about user ? Do i need to create simply OS user (/etc/passwd) and it
will be enought ? Or some dedicated configuration file is required ?


Thanks in advance

Zalezny

On Fri, May 27, 2016 at 12:07 AM, Viktor Dukhovni <
postfix-us...@dukhovni.org> wrote:

> On Thu, May 26, 2016 at 11:40:22PM +0200, Zalezny Niezalezny wrote:
>
> > 1. How to configure relay server which will relay all E-mails from
> > authenticated users from any IP.
>
> main.cf:
> indexed = ${default_database_type}:${config_directory}/
> smtpd_tls_fingerprint_digest = sha256
> smtpd_tls_auth_only = yes
> # Note Postfix >= 2.10
> mua_relay_restrictions =
> permit_sasl_authenticated,
> check_ccert_access ${indexed}relay-ccerts,
> reject
>
> master.cf:
> submission inet ... smtpd
>   -o smtpd_relay_restrictions=$mua_relay_restrictions
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_tls_ask_ccert=yes
>   ...
>
> relay-ccerts:
> #   OK
>
> e3:b0:c4:42:98:fc:1c:14:9a:fb:f4:c8:99:6f:b9:24:27:ae:41:e4:64:9b:93:4c:a4:95:99:1b:78:52:b8:55
> OK
> ...
>
> Or configure SASL, but frankly client certs are much easier on the
> server side, and simple enough on the client side, at least with
> Postfix as the client.
>
> --
> Viktor.
>