RE: whitelist for single reject

[Michael Fox]

> > ${config_directory}/reject1_map
> > # These hosts are whitelisted from this test only
> > 192.0.2.1   OK
> > 192.0.2.2   OK
> > # Everyone else gets this test
> > 0.0.0.0/0   reject1
> 
> To make "from this test only", it would have to be "DUNNO",
> rather than "OK" for the first two rules.
> 
> --
>   Viktor.

OK.  I wondered about that.  Thanks much!

Michael

RE: whitelist for single reject

[Michael Fox]

> > Suppose I have the following general case:
> >
> > /etc/postfix/whitelist1:
> > OK
> > OK
> >
> > /etc/postfix/whitelist2:
> > OK
> >
> > How would I accomplish the following?
> >
> > smtpd_*_restrictions =
> > . . .
> > reject_[type1] . . .  (except for hosts in whitelist1)
> > reject_[type2] . . .  (except for hosts in whitelist2)
> 
> 
> main.cf:
> smtpd_restriction_classes = whitelist1, whitelist2, unwhitelisted
> whitelist1 = reject_[type2]
> whitelist2 = reject_[type1]
> unwhitelisted = reject_[type1], reject_[type2]
> 
> smtpd_*_restrictions =
>check_client_access pcre:/etc/postfix/whitelisting
>...   (NOT including reject_[type1] or reject_[type2])
> 
> /etc/postfix/whitelisting:
> /^host_a$/   whitelist1
> /^host_b$/   whitelist1
> /^host_c$/   whitelist2
> /.*/ unwhitelisted
 
Ah.  OK.  I see what you're doing.  But, to make the logic more like

smtpd_*_restrictions =
. . .
reject_[type1] . . .  (except for hosts in whitelist1)
reject_[type2] . . .  (except for hosts in whitelist2)

and to take into account Viktor's suggestion for CIDR tables, does this
work?

${config_directory}/main.cf:
smtpd_restriction_classes = reject1, reject2
reject1 = reject_[type1]
reject2 = reject_[type2]

smtpd_*_restrictions = 
. . .
check_client_access cidr:${config_directory}/reject1_map
check_client_access cidr:${config_directory}/reject2_map
. . .

${config_directory}/reject1_map
# These hosts are whitelisted from this test only
192.0.2.1   OK
192.0.2.2   OK
# Everyone else gets this test
0.0.0.0/0   reject1

${config_directory}/reject2_map
# These hosts are whitelisted from this test only
192.0.2.2   OK
192.0.2.3   OK
# Everyone else gets this test
0.0.0.0/0   reject2


So:
-- host 192.0.2.1 is exempted from the first test but must undergo the
second test
-- host 192.0.2.2 is exempted from both tests
-- host 192.0.2.3 is must undergo the first test but is exempted from the
second test
-- all other hosts undergo both tests

Is that correct?


> The reason I'm specifying 'whitelisting' map as pcre type instead of
> hash is that I don't think there's any way to make a hash map default to
> a restriction class or restriction list. One way to read the access(5)
> man page implies that '.' would match any hostname not matched, but I
> have not tried that.

OK.  Understood.

Michael

RE: whitelist for single reject

[Michael Fox]

> Since hostname based whitelists are fragile in the face of transient
> DNS failures, and many users struggle with regular expression correctness.
> A CIDR map is more appropriate here:
>   Viktor.

Excellent.  Thanks.

Michael

RE: whitelist for single reject

[Michael Fox]

> In addition to defining alternative restriction lists and classes as
> Wietse noted, you can keep all of your restrictions in the standard
> smtpd_*_restrictions lists if you prefer and can accept the limitation
> of having each type of whitelisting applied to a trailing sublist of
> restrictions.

Thanks Bill.  But the situation is not "nested" as your example showed.  I
just posted a follow-up to Wietse' response.  Perhaps that will be more
clear.

Michael

whitelist for single reject

[Michael Fox]

I'm pretty sure I've seen this documented somewhere, but I can't find it.

 

What I'd like to do is have a whitelist apply to only a specific reject.
For example:

 

smtpd_*_restrictions = 

  .

  check_*_access .  

  reject_.

  reject_...

  reject_...

 

My understanding is that the above  will cause all
of the following rejects to be skipped for whitelisted hosts.  But suppose
each reject_... test needs different whitelists?  Is there a way to do that?

 

Thanks,

Michael

 

RE: SSL_accept error on just one of several similar servers

[Michael Fox]

> 
> > On Mar 26, 2018, at 1:07 AM, Michael Fox <n...@mefox.org> wrote:
> >
> > Any idea of what's wrong?  Or how to find out what's wrong?
> 
> Most likely a firewall is (mis)configured to block STARTTLS.
> 
> --
>   Viktor.

You were correct!  The IT guys started filtering by domain name in their
firewall, which interrupted STARTTLS negotiation.

Thanks,
Michael

SSL_accept error on just one of several similar servers

[Michael Fox]

I have several Postfix servers with virtually identical configurations.
That is, they have their own hostnames, IP addresses, etc.  But the rest of
main.cf and master.cf and various *_access, etc. files are the same.

I recently started having a problem with SSL_accept errors on just one of
the machines.  Several people report (including me) that from the same
Thunderbird client, we can connect to all of the other servers and send a
message.  But when we try to connect and send to the one server, it fails.

The Thunderbird client displays:  "Sending of the message failed.  The
message could not be sent because the connection to Outgoing server (SMTP)
host.domain timed out.  Try again.

/var/log/mail.log shows:  

Mar 25 21:35:19 w1xsc-gw postfix/submission/smtpd[9565]: connect from
client.domain.org[xx.xx.xx.xx]
Mar 25 21:35:19 w1xsc-gw postfix/submission/smtpd[9565]: SSL_accept error
from client.domain.org[xx.xx.xx.xx]: Connection reset by peer
Mar 25 21:35:19 w1xsc-gw postfix/submission/smtpd[9565]: lost connection
after STARTTLS from client.domain.org[xx.xx.xx.xx]
Mar 25 21:35:19 w1xsc-gw postfix/submission/smtpd[9565]: disconnect from
client.domain.org[xx.xx.xx.xx] ehlo=1 starttls=0/1 commands=1/2

I tried setting smtpd_tls_loglevel = 2, in case the extra information is
helpful:

Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]: connect from
client.domain.org[xx.xx.xx.xx]
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]: setting up TLS
connection from client.domain.org[xx.xx.xx.xx]
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]:
client.domain.org[xx.xx.xx.xx]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]:
SSL_accept:before/accept initialization
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]: SSL_accept:error in
SSLv2/v3 read client hello A
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]: SSL_accept error
from client.domain.org[xx.xx.xx.xx]: Connection reset by peer
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]: lost connection
after STARTTLS from client.domain.org[xx.xx.xx.xx]
Mar 25 21:43:34 w1xsc-gw postfix/submission/smtpd[9906]: disconnect from
client.domain.org[xx.xx.xx.xx] ehlo=1 starttls=0/1 commands=1/2

I re-verified that the configs between the different Postfix machines are
the same (except for the obvious IP address, etc.) and they haven't changed.
I also looked at previous posts about SSL_accept but they didn't seem to be
the same situation.

Any idea of what's wrong?  Or how to find out what's wrong?

Thanks,
Michael
 

postconf -nf:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = yes
biff = no
body_checks = pcre:${config_directory}/body_checks.pcre
bounce_queue_lifetime = 12h
bounce_template_file = ${config_directory}/bounce.cf
broken_sasl_auth_clients = yes
canonical_maps = pcre:${config_directory}/canonical.pcre
compatibility_level = 2
content_filter = amavisfeed:[127.0.0.1]:10024
delay_warning_time = 2h
fast_flush_domains = $relay_domains
header_checks = pcre:${config_directory}/header_checks.pcre
html_directory = /usr/share/doc/postfix/html
inet_interfaces = $xsc_inet_interfaces
mailbox_size_limit = 5120
maximal_queue_lifetime = 12h
message_size_limit = 1024
milter_default_action = accept
milter_protocol = 6
mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre
mua_client_connection_count_limit = 5
mua_client_connection_rate_limit = 10
mua_client_message_rate_limit = 10
mua_client_recipient_rate_limit = 50
mua_client_restrictions = check_sasl_access
hash:${config_directory}/sasl_access
permit_sasl_authenticated reject
mua_discard_ehlo_keyword_address_maps =
cidr:${config_directory}/ehlo_keyword.cidr
mua_helo_restrictions =
mua_recipient_limit = 25
mua_recipient_overshoot_limit = 25
mua_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain check_sasl_access
hash:${config_directory}/sasl_access check_recipient_access
hash:${config_directory}/roleaccount_exceptions check_recipient_access
pcre:${config_directory}/recipient_access.pcre check_recipient_access
pcre:${config_directory}/relay_recipient_access.pcre
check_recipient_access
pcre:${config_directory}/virtual_recipient_access.pcre permit
mua_relay_restrictions = permit_sasl_authenticated reject
mua_sender_restrictions = $mua_tls_client_restrictions
reject_non_fqdn_sender
reject_sender_login_mismatch permit_sasl_authenticated
reject_unknown_sender_domain reject_unlisted_sender permit
mua_tls_client_restrictions = check_client_access
cidr:${config_directory}/tls_clients.cidr
mydestination = $xsc_mydestination
mydomain = $xsc_mydomain
myhostname = $xsc_myhostname
mynetworks = $xsc_mynetworks
myorigin = $xsc_myorigin
non_smtpd_milters = inet:localhost:8891
postscreen_access_list = permit_mynetworks
cidr:${config_directory}/postscreen_access.cidr

RE: Header-Name: capitalization

[Michael Fox]

> https://tools.ietf.org/html/rfc5322#section-1.2.2
> 

Ah!  Thanks Viktor.

Michael

Header-Name: capitalization

[Michael Fox]

I'm working on a milter that checks for certain headers.  The RFCs specify
header names with specific capitalization.  For example:  "Message-ID".  I
don't see anything the RFCs that indicates that alternate capitalization
should be accepted, such as "Message-Id".  But perhaps I missed it.

 

So, I wonder: is it safe to match ONLY on the exact capitalization specified
in the RFCs, or should header name matching be done in a case-insensitive
manner.

 

Thanks,

Michael

 

RE: RESOLVED: RE: wrong From: and Return Path: address

[Michael Fox]

> > On Sep 26, 2017, at 11:23 PM, Michael Fox <n...@mefox.org> wrote:
> >
> > BTW, the mail provider found that the default sendmail config and their
> own
> > customized config both rewrote the From: header when the From: address
> was
> > for a domain that had a CNAME record.  They said this is a config option
> in
> > sendmail and they prefer to operate this way.  Interesting that my other
> > Postfix machines don't do this, nor do many other large email providers.
> 
> This is an obsolete option in Sendmail that violates decades old SMTP
> standards, CNAME canonicalization of recipient domains went away in
> RFC 2821 and there are many email domains that are aliases where the
> mailbox address is expected to remain unmangled by CNAME expansion of
> the domain part.  The operators of the sending system are stuck in the
> distant past.

Thanks Viktor.  Yes, I see section 3.6 now explicitly allows "CNAME RRs
whose targets can be resolved, in turn, to MX or A RRs", which was the case
in my situation.

Good to know that Postfix does it better!

Michael

RESOLVED: RE: wrong From: and Return Path: address

[Michael Fox]

> > Michael Fox skrev den 2017-09-21 19:52:
> > > I have a problem that seems to have started when I upgraded from
> Ubuntu
> > > 14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0.  It involves the
> > > From:
> > > and Return Path: addresses seen by recipients of mail sent from a
> > > virtual
> > > domain on that machine.

This problem turned out to be a DNS issue.  The Postfix 3.1.0 machine's
virtual domain in the From: address was entered in DNS with a CNAME record
pointing to the gateway machine (because they are, indeed, the same
address).  When it was changed to an A record, the problem went away.
Evidently, the user that was certain that the problem only started after the
upgrade was, uhm, mistaken.  The problem also didn't occur on a separate
Postfix 2.11 machine because it's DNS entry was correct.  

BTW, the mail provider found that the default sendmail config and their own
customized config both rewrote the From: header when the From: address was
for a domain that had a CNAME record.  They said this is a config option in
sendmail and they prefer to operate this way.  Interesting that my other
Postfix machines don't do this, nor do many other large email providers.

Michael

RE: wrong From: and Return Path: address

[Michael Fox]

> sorry for late reply on this here,

No problem Benny.  Thanks for taking the time to review ...


> i noted from logs that you use
> mimedefang and amavisd for same mails, why ?

amavisd runs spamassassin and clamav.  No difference in setup between
Postfix 2.11 and 3.1.  

I just added mimedefang to perform some additional message mangling to help
out really old clients (like removing redundant html).  But I'm confident
that's irrelevant to the From: domain problem since I can take out
mimedefang and the problem persists.
 

> and as well that postfix send auth users mails to amavisd inbound so its
> classified as incomming mails, clean that up :=)
>
> -o content-filter override in master.cf on postfix solves this very
> nice, dont use content-filer in postfix main.cf, little hint here

We want all emails to go through amavis (spamassassin and clamav), whether
they are from one of our relay domains, virtual domains, a local user, or
the outside world.  We follow /usr/share/doc/amavisd-new/README.postfix.html
section 3.1 - Filtering E-mail globally.

Are you suggesting something different?  Can you be more explicit?

Regardless, I don't think this is related to the From: domain problem since
the config is the same for Postfix 2.11 and 3.1(unless there's a mistake
that I can't find).

 
> make sure amavisd have same mynetworks settings as postfix have, both
> should know all border ips aswell as rfc1918, and ipv6 dito, basicly all
> in ifconfig as a minimal

If you're referring to the following line:

amavis[2735]: (02735-07) Open relay? Nonlocal recips but not
originating: @

then, yeah, I've struggled with that.  (And based on Internet searches many
others do, too!)  I've verified it's not an open relay.  We're not using
IPv6 and the IPv4 nets are the same in amavis mynetworks and postfix
mynetworks.  Yet it continues to complain.  

I'm not sure what you mean by "... both should know all border IPs ...".
Can you be more explicit?

Regardless, the configuration is the same in postfix 2.11 and 3.1  So I
don't see how that could be causing the difference in behavior either
(unless there's a mistake that I can't find).

 
> and i think you have a problem on how sasl is configured on dovecot, is
> it only local system users auth that can relay mails ?, that way the
> auth only check local part of the mails to allow senders, that explains
> possible to change domain part and still authed for the local part of
> email, check that and ask for help with that on dovecot maillist

Dovecot performs SASL authentication of virtual domain users on the
submission port.  There are only a couple of local accounts for sysadmins,
and they don't use submission or SASL.  Since the problem with the Postfix
3.1 machine DOES involve the virtual domain being changed to the mail
gateway's hostname and this doesn't happen for relay domains, you may be
onto something.  But SASL does check both local part and domain part.  And
the SASL config hasn't changed between 2.11 and 3.1 (unless there's a
mistake that I can't find).

I don't understand what problem you see.  Can you be more specific?

 
> basicly random realm domain
> 
> to big logs make it harder for me to nerrow it more dowm

Well, thanks for taking a look.  I've been over and over the configs using
diff tools and I don't find anything significantly different between the
2.11 and the 3.1 configs.  Yet the 3.1 system results in the recipient
seeing the wrong From: domain at one (so far) email hosting provider.

The email hosting provider took a pcap trace and doesn't see anything wrong
yet with the SMTP session, but will continue to research on Monday.  

Michael

RE: wrong From: and Return Path: address

[Michael Fox]

> Michael Fox skrev den 2017-09-21 19:52:
> > I have a problem that seems to have started when I upgraded from Ubuntu
> > 14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0.  It involves the
> > From:
> > and Return Path: addresses seen by recipients of mail sent from a
> > virtual
> > domain on that machine.
> 
> you should not care of return-path at all, and if you try to make them
> equal with from you have a hard time with that job, no logs no problem,
> but thanks for postconf -n and postconf -Mf anyway

Thanks Benny.

I don't really care about Return-path and I'm not trying to make them equal.
Again, what I reported is that recipients on Gmail, Yahoo, Rackspace and
others see the correct value (user@virtualdomain) in both headers (Return
Path: and From: ), whether I send from the new Postfix 3.1.0 machine or the
older Postfix 2.11.0 machine.  However, recipients at this one (large) email
provider see the wrong value (user@gatewayhostname) in both headers when
sending from Postfix 3.1.0 and the right value (user@virtualdomain) when
sending from Postfix 2.11.0. 

> need more help show logs of a real problem

Here are two sets of logs.  The first is from the Postfix 3.1.0 machine
which results in the recipient seeing the wrong From: address.  The second
is from the Postfix 2.11.0 machine which results in the recipient seeing the
correct address.  In both cases, I included submission of the message
through delivery to the destination.

I'm not very skilled at interpreting the logs, but I've looked at them line
by line and I don't see where the destination server would ever get "From:
n6...@w6xsc-gw.scc-ares-races.org".  I'm hoping that someone here with more
knowledge than me can see where I went wrong.  I'm stumped.

Thanks,
Michael

>From Postfix 3.1.0 - recipient sees From: n6...@w6xsc-gw.scc-ares-races.org,
should be From: n6...@email6.scc-ares-races.org

Sep 21 18:45:41 w6xsc-gw postfix/submission/smtpd[26419]: connect from
n6mef-gw.n6mef.org[173.167.109.217]
Sep 21 18:45:41 w6xsc-gw postfix/submission/smtpd[26419]: Anonymous TLS
connection established from n6mef-gw.n6mef.org[173.167.109.217]: TLSv1.2
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Sep 21 18:45:41 w6xsc-gw dovecot: auth:
passwd-file(n6...@email6.scc-ares-races.org,173.167.109.217): unknown user
Sep 21 18:45:41 w6xsc-gw postfix/submission/smtpd[26419]: 6A9E31F70E:
client=n6mef-gw.n6mef.org[173.167.109.217], sasl_method=CRAM-MD5,
sasl_username=n6...@email6.scc-ares-races.org
Sep 21 18:45:41 w6xsc-gw postfix/pre-cleanup/cleanup[26426]: 6A9E31F70E:
message-id=<4c1afef8-9ab0-738c-a20a-212e7141a...@email6.scc-ares-races.org>
Sep 21 18:45:41 w6xsc-gw opendkim[1408]: 6A9E31F70E: DKIM-Signature field
added (s=mail61709, d=email6.scc-ares-races.org)
Sep 21 18:45:41 w6xsc-gw postfix/qmgr[26352]: 6A9E31F70E:
from=<n6...@email6.scc-ares-races.org>, size=673, nrcpt=1 (queue active)
Sep 21 18:45:41 w6xsc-gw amavis[2735]: (02735-07) LMTP [127.0.0.1]:10024
/var/lib/amavis/tmp/amavis-20170921T061543-02735-H33h2gd8:
<n6...@email6.scc-ares-races.org> -> <n6...@prismatic.com> SIZE=673
BODY=8BITMIME Received: from w6xsc-gw.scc-ares-races.org ([127.0.0.1]) by
localhost (w6xsc-gw.scc-ares-races.org [127.0.0.1]) (amavisd-new, port
10024) with LMTP for <n6...@prismatic.com>; Thu, 21 Sep 2017 18:45:41 -0700
(PDT)
Sep 21 18:45:41 w6xsc-gw postfix/submission/smtpd[26419]: disconnect from
n6mef-gw.n6mef.org[173.167.109.217] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1
data=1 quit=1 commands=8
Sep 21 18:45:41 w6xsc-gw amavis[2735]: (02735-07) dkim: VALID
Author+Sender+MailFrom signature by d=email6.scc-ares-races.org, From:
<n6...@email6.scc-ares-races.org>, a=rsa-sha256, c=simple/simple,
s=mail61709, i=@email6.scc-ares-races.org
Sep 21 18:45:41 w6xsc-gw amavis[2735]: (02735-07) Checking: EmxshYSM9dtH
[173.167.109.217] <n6...@email6.scc-ares-races.org> -> <n6...@prismatic.com>
Sep 21 18:45:41 w6xsc-gw amavis[2735]: (02735-07) Open relay? Nonlocal
recips but not originating: n6...@prismatic.com
Sep 21 18:45:41 w6xsc-gw amavis[2735]: (02735-07) p001 1 Content-Type:
text/plain, size: 10 B, name:
Sep 21 18:45:42 w6xsc-gw postfix/amavisreturn/smtpd[26431]: connect from
localhost.localdomain[127.0.0.1]
Sep 21 18:45:42 w6xsc-gw postfix/amavisreturn/smtpd[26431]: 380AA1F824:
client=localhost.localdomain[127.0.0.1]
Sep 21 18:45:42 w6xsc-gw postfix/cleanup[26432]: 380AA1F824:
message-id=<4c1afef8-9ab0-738c-a20a-212e7141a...@email6.scc-ares-races.org>
Sep 21 18:45:42 w6xsc-gw postfix/amavisreturn/smtpd[26431]: disconnect from
localhost.localdomain[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1
commands=5
Sep 21 18:45:42 w6xsc-gw postfix/qmgr[26352]: 380AA1F824:
from=<n6...@email6.scc-ares-races.org>, size=1552, nrcpt=1 (queue active)
Sep 21 18:45:42 w6xsc-gw amavis[2735]: (02735-07) EmxshYSM9dtH FWD from
<n6...@email6.scc-ares-races.org&g

wrong From: and Return Path: address

[Michael Fox]

I have a problem that seems to have started when I upgraded from Ubuntu
14.04/Postfix 2.11.0 to Ubuntu 16.04/Postfix 3.1.0.  It involves the From:
and Return Path: addresses seen by recipients of mail sent from a virtual
domain on that machine.

Clients of Google, Yahoo, Rackspace, . see the From: and Return Path:
address as @, which is correct.
Clients of one (rather large) email service provider see the From: and
Return Path:  address as @, which is wrong.

The one email provider might have something wrong on their end.  BUT:  The
problem doesn't happen with mail received at that provider from a similarly
configured gateway/virtual domain, which is still running Ubuntu
14.04/Postfix 2.11.0.  And the problem didn't start happening on the machine
in question until the machine was upgraded to Ubuntu 16.04/Postfix 3.1.0.
So my money is on a mistake on my end.  I just can't find it.

I've done file comparisons between the postfix 2.11.0 and 3.1.0 machines,
and between the old and new configs of the 3.1.0 machine, and I just can't
find any significant differences (i.e. other than hostname changes, etc.).

Below is postconf info for the current main.cf and master.cf.  

Thanks in advance for any help.
Michael

$ postconf -pnf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_at_myorigin = yes
append_dot_mydomain = yes
biff = no
body_checks = pcre:${config_directory}/body_checks.pcre
bounce_queue_lifetime = 12h
bounce_template_file = ${config_directory}/bounce.cf
broken_sasl_auth_clients = yes
canonical_maps = pcre:${config_directory}/canonical.pcre
compatibility_level = 2
content_filter = amavisfeed:[127.0.0.1]:10024
delay_warning_time = 2h
fast_flush_domains = $relay_domains
header_checks = pcre:${config_directory}/header_checks.pcre
html_directory = /usr/share/doc/postfix/html
inet_interfaces = $xsc_inet_interfaces
mailbox_size_limit = 5120
maximal_queue_lifetime = 12h
message_size_limit = 1024
milter_default_action = accept
milter_protocol = 6
mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre
mua_client_connection_count_limit = 5
mua_client_connection_rate_limit = 10
mua_client_message_rate_limit = 10
mua_client_recipient_rate_limit = 50
mua_client_restrictions = check_sasl_access
hash:${config_directory}/sasl_access
permit_sasl_authenticated reject
mua_discard_ehlo_keyword_address_maps =
cidr:${config_directory}/ehlo_keyword.cidr
mua_helo_restrictions =
mua_recipient_limit = 25
mua_recipient_overshoot_limit = 25
mua_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain check_sasl_access
hash:${config_directory}/sasl_access check_recipient_access
hash:${config_directory}/roleaccount_exceptions check_recipient_access
pcre:${config_directory}/recipient_access.pcre check_recipient_access
pcre:${config_directory}/relay_recipient_access.pcre
check_recipient_access
pcre:${config_directory}/virtual_recipient_access.pcre permit
mua_relay_restrictions = permit_sasl_authenticated reject
mua_sender_restrictions = $mua_tls_client_restrictions
reject_non_fqdn_sender
reject_sender_login_mismatch permit_sasl_authenticated
reject_unknown_sender_domain reject_unlisted_sender permit
mua_tls_client_restrictions = check_client_access
cidr:${config_directory}/tls_clients.cidr
mydestination = $xsc_mydestination
mydomain = $xsc_mydomain
myhostname = $xsc_myhostname
mynetworks = $xsc_mynetworks
myorigin = $xsc_myorigin
non_smtpd_milters = inet:localhost:8891
postscreen_access_list = permit_mynetworks
cidr:${config_directory}/postscreen_access.cidr
postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_dnsbl_reply_map =
pcre:${config_directory}/postscreen_dnsbl_reply_map.pcre
postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spameatingmonkey.net*2
psbl.surriel.com*2 bl.spamcop.net
hostkarma.junkemailfilter.com=127.0.0.2
dnsbl.sorbs.net bl.mailspike.net swl.spamhaus.org*-4
list.dnswl.org=127.0.[0..255].0*-1 list.dnswl.org=127.0.[0..255].1*-2
list.dnswl.org=127.0.[0..255].2*-3 list.dnswl.org=127.0.[0..255].3*-4
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_ttl = 5m
postscreen_greet_action = enforce
proxy_interfaces = $xsc_proxy_interfaces
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $xsc_relay_domains
relay_recipient_maps = pcre:${config_directory}/relay_recipients.pcre
relay_restrictions = check_sender_access
pcre:${config_directory}/relay_sender_access.pcre
remote_header_rewrite_domain = invalid.domain
smtp_host_lookup = native
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 20
smtpd_client_message_rate_limit = 20
smtpd_client_recipient_rate_limit = 200
smtpd_client_restrictions = permit_mynetworks check_client_access
pcre:${config_directory}/client_access.pcre

RE: chroot setting in master.cf

[Michael Fox]

> I wrote README.postfix.html for amavisd-new many years ago and I don't
> recall
> why master.cf was in the state it was by then. I wouldn't say it the
> documentation is in error - it's has simply not seen any update in many
> years.

Ah, OK.  Thanks.  That explains the differences.


> Personally I don't use content_filter and smtpd_proxy_filter anymore. I
> prefer
> the MILTER interface over the other methods. If you are interested in this
> and
> if you can read German (or are able to handle google translate ;) you may
> read
> my blog https://sys4.de/de/blog/2015/07/31/amavisd-milter-howto/ for
> instructions.

OK. Thanks.


> The all general answer is: If you plan to run Postfix chrooted, chroot as
> much
> as you can. It's a design question. Chrooting a service like Postfix comes
> at
> the price of quite some management overhead. You can automate most of
> that,
> but you need to take care of it.
> 
> Many years ago Wietse wrote chrooting Postfix only makes sense on a
> hardened
> server. I agree with that. If the server isn't hardened, forget to chroot
> the
> service as there are very likely much more easily exploitable "entry
> points"
> to the server.

OK.  That all makes sense and provides me a good recommendation.  

Michael

RE: chroot setting in master.cf

[Michael Fox]

> With Postfix 3, chroot is no longer the default. It remains an
> available option for people who want to go through the effort.
> 
>   Wietse

Yes, but that wasn't my question.  Again, my question was:

I'm configuring master.cf to add amavisd-new.  The amavisd-new documentation
(/usr/share/doc/amavisd-new/README.postfix.html) differs from the default
master.cf file regarding the chroot setting for the cleanup (and
pre-cleanup) service.  I presume that the amavisd-new documentation is in
error and that I should go with the chroot setting that's in the default
master.cf.  But I don't know enough about the implications of one vs. the
other to be sure.

Specifically, I have three questions:

1) Section 4.2.1 of the above web page shows adding a pre-cleanup service
with chroot=n.  But the default master.cf (from Ubuntu) has the cleanup
service configured
with chroot=y.  Should I use the same chroot=y setting for the pre-cleanup
service?  

2) Section 4.2.2 of the above web page shows modifying the existing cleanup
service to add some "-o" options.  But it shows the cleanup service with
chroot=n.  Should I leave chroot=y for the cleanup service?

3) The above web page also shows the new "amavisfeed" and "127.0.0.1:10025"
services with chroot=n.  But similar services in master.cf have chroot=y.
Should these two new services also use chroot=y?

Thanks in advance,
Michael

RE: chroot setting in master.cf

[Michael Fox]

> The default master.cf as distributed by postfix has all services as
> chroot "n", and that is the recommended setting.
> -- Noel Jones

Thanks Noel.

Interesting.  From 
http://www.postfix.org/BASIC_CONFIGURATION_README.html#chroot_setup, the 
recommendation seems to be to use chroot wherever possible.  In fact, it says:  
"The author's own porcupine.org mail server runs all daemons chrooted that can 
be chrooted."  (Maybe this is left over from when the default for chroot was 
"y"?)

The Debian/Ubuntu package defaults seem to be following that advice.  But 
evidently, the default distributed by postfix is going the other way.  

That leaves a basic user like me unsure of what to do.  So, let me ask my 
question this way:  Given that the default master.cf file from Ubuntu (see 
below) has chroot="y" for the cleanup service, then presumably they've also 
done whatever needs to be done to make cleanup work inside the chroot jail.  
So, given all of that, does it make sense to continue using chroot=y for 
cleanup (and pre-cleanup)?  Or should I switch to chroot=n anyway?

Thanks,
Michael


# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (no)(never) (100)
$ postconf -Mf
smtp   inet  n   -   y   -   -   smtpd
pickup unix  n   -   y   60  1   pickup
cleanupunix  n   -   y   -   0   cleanup
qmgr   unix  n   -   n   300 1   qmgr
tlsmgr unix  -   -   y   1000?   1   tlsmgr
rewriteunix  -   -   y   -   -   trivial-rewrite
bounce unix  -   -   y   -   0   bounce
defer  unix  -   -   y   -   0   bounce
trace  unix  -   -   y   -   0   bounce
verify unix  -   -   y   -   1   verify
flush  unix  n   -   y   1000?   0   flush
proxymap   unix  -   -   n   -   -   proxymap
proxywrite unix  -   -   n   -   1   proxymap
smtp   unix  -   -   y   -   -   smtp
relay  unix  -   -   y   -   -   smtp
showq  unix  n   -   y   -   -   showq
error  unix  -   -   y   -   -   error
retry  unix  -   -   y   -   -   error
discardunix  -   -   y   -   -   discard
local  unix  -   n   n   -   -   local
virtualunix  -   n   n   -   -   virtual
lmtp   unix  -   -   y   -   -   lmtp
anvil  unix  -   -   y   -   1   anvil
scache unix  -   -   y   -   1   scache
maildrop   unix  -   n   n   -   -   pipe flags=DRhu
user=vmail argv=/usr/bin/maildrop -d ${recipient}
uucp   unix  -   n   n   -   -   pipe flags=Fqhu
user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
ifmail unix  -   n   n   -   -   pipe flags=F user=ftn
argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp  unix  -   n   n   -   -   pipe flags=Fq.
user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix - n   n   -   2   pipe flags=R
user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop}
${user} ${extension}
mailmanunix  -   n   n   -   -   pipe flags=FR
user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py ${nexthop}
${user}

chroot setting in master.cf

[Michael Fox]

I'm configuring master.cf to add amavisd-new.  The amavisd-new documentation
(/usr/share/doc/amavisd-new/README.postfix.html) differs from the default
master.cf file regarding the chroot setting for the cleanup (and
pre-cleanup) service.  I presume that the amavisd-new documentation is in
error and that I should go with the chroot setting that's in the default
master.cf.  But I don't know enough about the implications of one vs. the
other to be sure.

Specifically, I have three questions:

1) Section 4.2.1 of the above web page shows adding a pre-cleanup service
with chroot=n.  But the default master.cf has the cleanup service configured
with chroot=y.  Should I use the same chroot=y setting for the pre-cleanup
service?  

2) Section 4.2.2 of the above web page shows modifying the existing cleanup
service to add some "-o" options.  But it shows the cleanup service with
chroot=n.  Should I leave chroot=y for the cleanup service?

3) The above web page also shows the new "amavisfeed" and "127.0.0.1:10025"
services with chroot=n.  But similar services in master.cf have chroot=y.
Should these two new services also use chroot=y?

Thanks in advance,
Michael

RE: reloading postfix with systemd

[Michael Fox]

> Well at least in Redhat, if you do systemctl reload postfix it just
> executes postfix reload internally. So it makes absolutely no
> difference.
> 
> # cat /usr/lib/systemd/system/postfix.service
> [Unit]
> Description=Postfix Mail Transport Agent
> After=syslog.target network.target
> Conflicts=sendmail.service exim.service
> 
> [Service]
> Type=forking
> PIDFile=/var/spool/postfix/pid/master.pid
> EnvironmentFile=-/etc/sysconfig/network
> ExecStartPre=-/usr/libexec/postfix/aliasesdb
> ExecStartPre=-/usr/libexec/postfix/chroot-update
> ExecStart=/usr/sbin/postfix start
> ExecReload=/usr/sbin/postfix reload
> ExecStop=/usr/sbin/postfix stop
> 
> [Install]
> WantedBy=multi-user.target

Hmm.  My Ubuntu system has no such file.

~$ sudo systemctl status postfix.service
● postfix.service - LSB: Postfix Mail Transport Agent
   Loaded: loaded (/etc/init.d/postfix; bad; vendor preset: enabled)
  Drop-In: /run/systemd/generator/postfix.service.d
   └─50-postfix-$mail-transport-agent.conf
   Active: active (running) since Wed 2017-08-09 10:20:02 PDT; 1 day 1h ago
 Docs: man:systemd-sysv-generator(8)
Tasks: 4
   Memory: 6.5M
  CPU: 1.836s
   CGroup: /system.slice/postfix.service
   ├─ 1971 /usr/lib/postfix/sbin/master
   ├─20028 qmgr -l -t unix -u
   ├─20030 pickup -l -t unix -u -c
   └─20039 tlsmgr -l -t unix -u -c

I'm a newbie to systemd.  But I guess the above is telling me that the
postfix.service is auto-generated.
Looking at the file listed in "Drop-In", I don't see the reload command.

$ cat
/run/systemd/generator/postfix.service.d/50-postfix-\$mail-transport-agent.c
onf
# Automatically generated by systemd-insserv-generator

[Unit]
Wants=mail-transport-agent.target
Before=mail-transport-agent.target

The logical assumption would be that the auto-generated service would have
the same commands as "postfix ...".  
But I haven't yet figured out how to show/prove whether "postfix reload" =
"systemctl reload postfix"

Michael

reloading postfix with systemd

[Michael Fox]

In v16.04 LTS, Ubuntu has switched to systemd.

"postfix reload" still seems to work just fine.
But I wonder if I should be using "systemctl reload postfix" instead.

Which method is preferred on systems that use systemd?
And if either method works, are there differences or reasons to prefer one
over the other?

Thanks,
Michael
 

RE: postfix check warnings on new Ubuntu 16.04 install

[Michael Fox]

Thanks for the speedy response, Scott.

M

> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Scott Kitterman
> Sent: Wednesday, August 9, 2017 2:54 PM
> To: postfix-users@postfix.org
> Subject: Re: postfix check warnings on new Ubuntu 16.04 install
> 
> 
> 
> On August 9, 2017 2:03:47 PM EDT, Michael Fox <n...@mefox.org> wrote:
> >I'm building a new 16.04 machine using the distro package for postfix
> >(v3.1.0).  The main.cf and master.cf files are still at defaults.
> >
> >I ran "postfix check" and it's listing warnings about some library
> >files.
> >This didn't happen on Ubuntu 14.04.
> >
> >I don't understand what it's trying to tell me or what I need to do
> >about
> >it.  The output is below.  Should I do something about this and, if so,
> >what?
> >
> >Thanks in advance,
> >Michael
> >
> >$ sudo postfix check
> >postfix: Postfix is running with backwards-compatible default settings
> >postfix: See http://www.postfix.org/COMPATIBILITY_README.html for
> >details
> >postfix: To disable backwards compatibility use "postconf
> >compatibility_level=2" and "postfix reload"
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/./sbin/lmtp
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/./libpostfix-dns.so.1
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/./libpostfix-global.so.1
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/./libpostfix-master.so.1
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/./libpostfix-util.so.1
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/./libpostfix-tls.so.1
> >postfix/postfix-script: warning: group or other writable:
> >/usr/lib/postfix/sbin/./lmtp
> >$
> >$ ls -l /usr/lib/postfix
> >total 764
> >lrwxrwxrwx 1 root root 23 Apr 13  2016 libpostfix-dns.so.1 ->
> >libpostfix-dns.so.1.0.1
> >-rw-r--r-- 1 root root  26968 Apr 13  2016 libpostfix-dns.so.1.0.1
> >lrwxrwxrwx 1 root root 26 Apr 13  2016 libpostfix-global.so.1 ->
> >libpostfix-global.so.1.0.1
> >-rw-r--r-- 1 root root 281152 Apr 13  2016 libpostfix-global.so.1.0.1
> >lrwxrwxrwx 1 root root 26 Apr 13  2016 libpostfix-master.so.1 ->
> >libpostfix-master.so.1.0.1
> >-rw-r--r-- 1 root root  39472 Apr 13  2016 libpostfix-master.so.1.0.1
> >lrwxrwxrwx 1 root root 23 Apr 13  2016 libpostfix-tls.so.1 ->
> >libpostfix-tls.so.1.0.1
> >-rw-r--r-- 1 root root 103344 Apr 13  2016 libpostfix-tls.so.1.0.1
> >lrwxrwxrwx 1 root root 24 Apr 13  2016 libpostfix-util.so.1 ->
> >libpostfix-util.so.1.0.1
> >-rw-r--r-- 1 root root 264504 Apr 13  2016 libpostfix-util.so.1.0.1
> >-rwxr-xr-x 1 root root  13052 Apr 13  2016 postfix_groups.pl
> >-rw-r--r-- 1 root root  18560 Apr 13  2016 postfix-pcre.so.1.0.1
> >-rw-r--r-- 1 root root  14504 Apr 13  2016 postfix-sqlite.so.1.0.1
> >drwxr-xr-x 2 root root   4096 Jul 23 08:41 sbin
> >$
> >$ postconf -d | grep mail_version
> >mail_version = 3.1.0
> >milter_macro_v = $mail_name $mail_version
> 
> We (the Debian Postfix maintainers) got this resolved, but not for that
> version (Ubuntu Postfix packages are synched from Debian based on Ubuntu
> schedule).  These are cosmetic and won't cause actual problems.
> 
> Scott K

postfix check warnings on new Ubuntu 16.04 install

[Michael Fox]

I'm building a new 16.04 machine using the distro package for postfix
(v3.1.0).  The main.cf and master.cf files are still at defaults.  

I ran "postfix check" and it's listing warnings about some library files.
This didn't happen on Ubuntu 14.04.  

I don't understand what it's trying to tell me or what I need to do about
it.  The output is below.  Should I do something about this and, if so,
what?

Thanks in advance,
Michael

$ sudo postfix check
postfix: Postfix is running with backwards-compatible default settings
postfix: See http://www.postfix.org/COMPATIBILITY_README.html for details
postfix: To disable backwards compatibility use "postconf
compatibility_level=2" and "postfix reload"
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/./sbin/lmtp
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/./libpostfix-dns.so.1
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/./libpostfix-global.so.1
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/./libpostfix-master.so.1
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/./libpostfix-util.so.1
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/./libpostfix-tls.so.1
postfix/postfix-script: warning: group or other writable:
/usr/lib/postfix/sbin/./lmtp
$
$ ls -l /usr/lib/postfix
total 764
lrwxrwxrwx 1 root root 23 Apr 13  2016 libpostfix-dns.so.1 ->
libpostfix-dns.so.1.0.1
-rw-r--r-- 1 root root  26968 Apr 13  2016 libpostfix-dns.so.1.0.1
lrwxrwxrwx 1 root root 26 Apr 13  2016 libpostfix-global.so.1 ->
libpostfix-global.so.1.0.1
-rw-r--r-- 1 root root 281152 Apr 13  2016 libpostfix-global.so.1.0.1
lrwxrwxrwx 1 root root 26 Apr 13  2016 libpostfix-master.so.1 ->
libpostfix-master.so.1.0.1
-rw-r--r-- 1 root root  39472 Apr 13  2016 libpostfix-master.so.1.0.1
lrwxrwxrwx 1 root root 23 Apr 13  2016 libpostfix-tls.so.1 ->
libpostfix-tls.so.1.0.1
-rw-r--r-- 1 root root 103344 Apr 13  2016 libpostfix-tls.so.1.0.1
lrwxrwxrwx 1 root root 24 Apr 13  2016 libpostfix-util.so.1 ->
libpostfix-util.so.1.0.1
-rw-r--r-- 1 root root 264504 Apr 13  2016 libpostfix-util.so.1.0.1
-rwxr-xr-x 1 root root  13052 Apr 13  2016 postfix_groups.pl
-rw-r--r-- 1 root root  18560 Apr 13  2016 postfix-pcre.so.1.0.1
-rw-r--r-- 1 root root  14504 Apr 13  2016 postfix-sqlite.so.1.0.1
drwxr-xr-x 2 root root   4096 Jul 23 08:41 sbin
$
$ postconf -d | grep mail_version
mail_version = 3.1.0
milter_macro_v = $mail_name $mail_version

RE: simultaneous sessions from old client

[Michael Fox]

> The same client can send the same message a thousand times if it
> wants to, though perhaps not all at the same time.
> 

OK Thanks.

simultaneous sessions from old client

[Michael Fox]

I've got some very old clients that takes a message to multiple recipients
at the same destination domain and separates the TO recipients and the CC
recipients into two messages and then sends them separately.  Until
recently, the message to the TO address would go out in one queue run and
the message to the CC addresses would go out in the next queue run.
Recently a patch was made to allow the client to open multiple sessions to
the destination MX so that both messages could go out at nearly the same
time.

 

While keeping one message as one message would be ideal, the client would
need a substantial overhaul, which is just not realistic.  So, although the
workaround is not an ideal solution, it seems to work.  

 

Question:

I haven't seen anything in Postfix documentation that would indicate that
this is would be a problem.  But is there anything I should be worried
about?  

 

Thanks,

Michael

RE: request improved logging for postfix.

[Michael Fox]

 
> No fixes are necessary, other than maybe I should write a tutorial
> on reading logs.
> 
>   -- Noel Jones

+1  In particular, your writing style is exceptionally clear!

Michael

checking file references

[Michael Fox]

Is there a command that can check if all files referenced in main.cf are
present?  Currently, if my manual/visual review misses something, I don't
find out until postfix tries to process a message and discovers the missing
file.  

 

postfix check doesn't do this.

 

Thanks,

Michael

 

 

RE: milter to decode quoted-printable, base64, ...

[Michael Fox]

> -Original Message-
> An ideal tool for that is MIMEDefang, ...

Thanks.  After a very quick look at the project website, this looks like what I 
need.


> "groff -T ascii" is your friend (if you befriend berserker vandals...)

... and another great hint.  Thanks.


> If you did this with MD or any other milter, the model would be to
> discard the original message pre-queue (i.e. have Postfix "accept" the
> message in SMTP but not queue it) and re-inject the transformed message.

OK.  I'll need to read up a bit more on this level of detail.  But thanks for 
that pointer.


> That raises an alternative option: if there *is* an "original plain text
> message" which something else is encoding, maybe the better approach is
> to fix the busybody encoder.

If I could, I would.  It seems harder and harder these days to find the 
controls to send only plain text in many clients.  So, some of the problem is 
just the sender who wants to send plain text simply can't figure out how to do 
it (or else they think they got it right, but didn't).  Other cases include the 
service provider converting the message without your knowledge.  For example, 
some SMS providers do things like take plain text input, wrap it in HTML, then 
encode it in base64.  Ugh. 

Michael

RE: milter to decode quoted-printable, base64, ...

[Michael Fox]

> > I've got some clients that are really simple and don't understand
> > various
> > message encoding types, such as quoted-printable, base64, possibly
> > others.
> > They understand plain text only.  So, for users in specific domains,
> > I'd
> > like to convert quoted-printable, base64 and possibly other encoded
> > messages
> > to plain text.
> 
> Do you understand why QP, Base64, and other encodings exist?

Yes

> 
> It is because some messages cannot be represented as plain text, due to
> the fact that "plain text" for email is a subset of the US-ASCII
> character set. QP and Base64 exist to translate 8-bit characters and
> arbitrary binary data into a stream of 8-bit characters that are in a
> 'mail safe' subset of US-ASCII.

Yup.  But if the original message content is all plain text, then the encoding 
adds no value and can be removed without changing the message.


> > I presume I need a content-filter to perform this work post-queue.
> 
> One actually should only do anything like this with client-side
> software. You presumably intend to throw away information (such as the
> difference between o, ô, and ö)

Yes.  Although the likelihood of such characters in the original content is 
virtually nil in this application.  And, even if it does exist, such characters 
can't be used by the receiving client anyway.


> and it is best to allow those choices
> to remain with end users.

Generally true.  But not in this case.  The client is what it is.  So I either 
find a way to decode such messages externally before delivering them to the 
client, or else the messages can't be read at all (at least the base64 type).


> > I looked here:  http://www.postfix.org/addon.html
> >
> > . but didn't see anything that addresses the issue.  Any ideas would
> > be
> > helpful.
> 
> Or maybe not, as I'm entirely serious when I say that your best choice
> is to not do this. Solve whatever problem you are trying to solve in
> some other way.

I understand and appreciate what you're saying as a general rule.  But I also 
understand this particular application.  And for this particular application, 
recovering the original plain text message before sending to the client is 
what's needed.  But thanks for your thoughts, Bill.  Your postings on this list 
are always informative.

Michael

milter to decode quoted-printable, base64, ...

[Michael Fox]

I've got some clients that are really simple and don't understand various
message encoding types, such as quoted-printable, base64, possibly others.
They understand plain text only.  So, for users in specific domains, I'd
like to convert quoted-printable, base64 and possibly other encoded messages
to plain text.

 

I presume I need a content-filter to perform this work post-queue.

I looked here:  http://www.postfix.org/addon.html

. but didn't see anything that addresses the issue.  Any ideas would be
helpful.

 

Thanks,

Michael

 

RE: generic main.cf files

[Michael Fox]

> 
> Only the documented behavior is supported. That means that bugs are
> fixed, backwards compatibility is maintained as Postfix evolves.
> 
> ...

You skipped over the apparent discrepancy that I pointed out.  I'll try to
word it differently:

You and Viktor and several others suggest creating custom parameter names to
solve certain problems.  In fact, you did so earlier today, with
$mua_*_restrictions.

I presume you wouldn't suggest solutions that are unsupported.  Correct?
If so, then by the above rule, the ability to create and use custom
parameter names must be documented.  But I have looked and looked and I just
can't find it.  In fact, the quote I provided in my last email seems to
imply the opposite.  I want to add a reference to my configuration notes.
So, will you please point me to where that capability is documented?

Thanks,
Michael

RE: generic main.cf files

[Michael Fox]

> It is not documented, therefore it is not supported.

Thanks and understood.  And BTW, the documentation is excellent -- the best
I've seen anywhere.

Not to quibble, but the reason I double checked was that there DO appear to
be supported features that are either not documented or else I haven't been
able to find where they are documented after extensive searching.  For
example, I have never been able to find where the documentations says we can
make up our own parameter names in main.cf (like mua_*_restrictions), yet
that's something that is recommended on this list.  In fact, the statement
"The remainder of this document is a description of all Postfix
configuration parameters" near the top of
http://www.postfix.org/postconf.5.html implies that no others can exist.

I know it would have been helpful to me if the "Postfix main.cf file format"
section of http://www.postfix.org/postconf.5.html mentioned the ability to
create custom parameters.

Michael

RE: generic main.cf files

[Michael Fox]

> On 25/07/16 05:19, Michael Fox wrote:
> > What about viewing the value which is set by reading a file?
> > For example:  mynetworks = ${config_directory}/filename
> 
> Look at postmap(1) to see how you can do map lookups from the command
> line.

To clarify, I'm not trying to do a map lookup.  I'm trying to display the
configuration, where some values are set by reading from a file.  But I did
try to use a cidr-type table such as:

network_table.cidr:
192.168.1.0/24  OK
192.168.2.0/24  OK
...

main.cf:
mynetworks = cidr:${config_directory}/network_table.cidr

No difference that I can tell.

 
> > Postconf -x will resolve $config_directory.  But I don't see a postconf
> > option that would show me what mynetworks is actually set to.
> 
> postconf mynetworks

That doesn't work.  It shows:

mynetworks = ${config_directory}/text_filename
-or-
mynetworks = cidr:${config_directory}/network_table.cidr

And postconf -x mynetworks shows:  

mynetworks = /etc/postfix/text_filename
-or-
mynetworks = hash:/etc/postfix/network_table.cidr

Again, I'd like to see the *value(s)* assigned to mynetworks, not the
filename or map name that the value came from.  In other words, I'm looking
for the following postconf output:

mynetworks = 192.168.1.0/24, 192.168.2.0/24, ...

Is that possible?


Michael

RE: generic main.cf files

[Michael Fox]

Michael:
> > Ubuntu Postfix package sets myorigin to /etc/mailname, which seems to
work

Weitse:
> The documented behavior is supported, as in, bugs fixed and backwards
> compatibility provided as Postfix evolves. Undocumented behavior is
> unsupported.

Peter:
> This is a debian modification, it is not supported by Postfix.

Wow.  OK.  So, I guess I should remove the /etc/mailname setting.  Strange.
It's been that way since at least Ubuntu 12.04 LTS., perhaps earlier.



What about viewing the value which is set by reading a file?  
For example:  mynetworks = ${config_directory}/filename

Postconf -x will resolve $config_directory.  But I don't see a postconf
option that would show me what mynetworks is actually set to.


 
> There is no 'include' command for main.cf or master.cf files, because
> a) it would complicate how commands like 'postconf -e' work, b)
> it would complicate the 'postfix check' that Postfix parameters
> don't come from a file or directory that is writable by non-root
> users, c) other considerations that were hashed out many years ago.

OK.  Thanks.

 
> I suggest that you have a script on each machine that customizes a
> generic Postfix main.cf and master.cf file.  As of a few releases
> you can use 'postconf -F' to customize each master.cf field and
> 'postconf -P' to customize each '-o name=value' parameter setting
> in master.cf.
> 
> In a distant past I might suggest using rdist to move and customize
> files; nowadays people might use Puppet, Chef, and the like to a
> similar effect.

OK.  Thanks.

Michael

generic main.cf files

[Michael Fox]

I've got several postfix systems which all have the same configuration
except for a few host-specific parameters like:
-- myhostname
-- mynetworks
-- mydestination
-- myorigin
-- inet_interfaces
-- proxy_interfaces
-- relay_domains
-- virtual_mailbox_domains

Typically, I copy the main.cf to another machine and edit the host-specific
values.  What would be nice is to have a generic main.cf that can be copied
to any machine and which references all host-specific values in external
files.  

In http://www.postfix.org/postconf.5.html, there is no general rule at the
top that says a filename can be used for any parameter.  So it is evidently
available only for some parameters.  And some of the above parameters are
indeed documented as allowing filenames (mynetworks, mydestination,
relay_domains, virtual_mailbox_domains).  

But I ran into a few problems and have a few questions:

1) myorigin is not documented as allowing a filename.  But the Ubuntu
Postfix package sets it to /etc/mailname, which seems to work.  Perhaps
http://www.postfix.org/postconf.5.html should be updated?

2) proxy_interfaces is not documented as allowing a filename.  But postfix
check and postfix reload accept it.  Perhaps
http://www.postfix.org/postconf.5.html should be updated?

3) myhostname and inet_interfaces do not accept a filename.  Is there a way
to set them from a source outside of main.cf (i.e., a file)?

4) When an external filename is used, postconf shows the filename, not the
value.  That's good when sending postconf -n to this list.  But I'd also
like to be able to see the actual values Postfix has configured.  I can't
find a way to do that.  Postconf -x only expands $variablename, not the
contents filenames.  Is there a way to show the actual value assigned to a
parameter if it comes from a file?

5) Alternatively, I could place all of the host-specific parameters in a
file that is then included into main.cf, such as "!include
host-specific-main.cf".  But I don't see an include mechanism listed.  Does
it exist?

Thanks for any suggestions.
Michael

RE: smtpd restrictions on mail that comes from certain servers

[Michael Fox]

> Does anyone have any ideas how I'd specify this?  Would I have to use a
> pcre like the following?
> 
> /[^e][^x][^a][^m][^p][^l][^e][^\.][^c][^o][^m]$/WARN

If you choose to use pcre, see:  http://www.postfix.com/pcre_table.5.html
It includes an example:  !//  
Note that by default, matches are case insensitive (see -i flag)

Michael

RE: (OT)Ham Radio + SMTP (was Re: How to restrict encrypted email)

[Michael Fox]

> My understanding is that packet radio has been allowed in part of the
> HAM band and in part of the Marine SSB band for quite a long time.  
>
> Curtis

That's correct Curtis.  In fact, worldwide electronic mail was possible with
packet and the worldwide BBS network long before commercial Internet email
was available.  And we've been using Postfix to relay between our packet
network and Internet email for years.

AX.25 doesn't really have much to do with it.  It's a reasonable choice for
a link layer protocol for operation over a low-speed, lossy (radio) medium.
That makes it useful in the HF/VHF/UHF bands where channel bandwidth is
limited.  In fact, we run SMTP over AX.25 all the time.

It is really the channel speed, not the link layer protocol, that limits
message size and the use of native email clients and email client protocols
like IMAP, since they are far more chatty than the packet radio protocol for
sending/receiving messages.

But hams also have frequency allocations in the microwave (read WiFi) bands
and can run just as fast as any other commercial product there.  Those high
speed links enable the use of native email clients.  And that drove my
questions about controlling TLS and encryption.

I guess the ON-topic part of this is understanding the reason behind the
need to control the use of TLS and encryption on a client-by-client or
IP-address or other basis.  It's very real and very current, and not just
for "old" or "legacy" stuff.

But, before Wietse kicks me off the list ;-)  please let's get back to
Postfix.  Folks can contact me off list about amateur radio if desired at
n6mef at mefox dot org.

Michael
N6MEF

smtpd_relay_restrictions clarification

[Michael Fox]

Moving from a pre-v2.10 to post-v2.10 environment, I'd like make sure I
understand the meaning/context of smtpd_relay_restrictions.  Can someone
give me a sanity check?

http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions says:

"By default, the Postfix SMTP server accepts:
* Mail from clients whose IP address matches $mynetworks, or: 
* Mail to remote destinations that match $relay_domains, except for
addresses that contain sender-specified routing (user@elsewhere@domain), or:

* Mail to local destinations that match $inet_interfaces or
$proxy_interfaces, $mydestination, $virtual_alias_domains, or
$virtual_mailbox_domains."

So, does smtpd_relay_restrictions apply to everything else?  That is, all
other mail that does not meet those three requirements?

Also, shouldn't the first condition be:
"* Mail from clients whose IP address matches $mynetworks, or from SASL
authenticated clients, or:"
... given that the default config for smtpd_relay_restrictions is:
permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination?

Thanks,
Michael

RE: How to restrict encrypted email

[Michael Fox]

> You could use iptables to look for:
> "--BEGIN"
> "--END"
> "/signed"
> "/encrypted"
> "/pkcs7"
> "/pgp"


Thanks to all.  I've got enough to get me started with my homework.  Lots to
learn.

Regards,
Michael

RE: How to restrict encrypted email

[Michael Fox]

Michael Fox:
> > So, are there other obvious ways to recognize encrypted contents, other
> than
> > "Content-Type: multipart/encrypted"?

Albrecht:
> Basically, you need to check for
> - OpenPGP/Inline (inspect every body, see rfc 2440, sect. 6.2)
> - OpenPGP/Mime (multipart/encrypted, see rfc 3156, sect. 4)
> - S/MIME (application/pkcs7-mime with a proper protocol type, see rfc
> 2633, sect. 3.8)

Ah, OK.  That will give me a good start.  Thanks.


Rob0:
> you can use an alternate cleanup service on an alternate 
> smtpd instance, see postconf.5.html#cleanup_service_name and also 
> cleanup.8.html .

Interesting.  I hadn't thought of that.  I'll check into that.


And thanks to everyone for the rest of the comments, legal or otherwise.

I don't want to hijack this list with amateur radio stuff.  But to briefly
respond to those who took the time to respond to me:

-- Encryption should be encouraged:  Generally agreed.  But it's not allowed
on US amateur radio frequencies.

-- All comments about the FCC rules:  I have talked to the FCC and am
confident that I understand the requirements.  

-- You can never block it all:  Understood.  I'm looking to block the
obvious stuff to avoid inadvertent mistakes.  Those who resort to subterfuge
(which hasn't been a problem so far) can be dealt with on an individual
basis as a violation of the acceptable use policy.

Thanks again to all,
Michael

RE: How to restrict encrypted email

[Michael Fox]

> minimize it with some filtering for the obvious cases
> as you propose.

Thanks Marco.  I hadn't thought of some of those cases.  
But I would still like to block the obvious cases, as you say.

So, are there other obvious ways to recognize encrypted contents, other than
"Content-Type: multipart/encrypted"?

Thanks,
Michael

How to restrict encrypted email

[Michael Fox]

I'd like to be able to reject mail that contains encrypted content.  This is
to satisfy US FCC rules against encrypted content on amateur radio
frequencies.  Some of our clients may connect via amateur radio.

I'd like to be able to restrict it only for certain clients.  But, as I
understand it, header checks can only be applied globally, to all mail.

Sorry if this is a dumb question.  But, unfortunately, I don't have any
experience with encrypted mail.  From what I've read, I'm thinking I need:

main.cf:

  mime_header_checks = pcre:${config_directory}/mime_header_checks.pcre


mime_header_checks.pcre:

  # Block encrypted mail
  /^Content-Type\:.*multipart\/encrypted/   REJECT Encrypted
content not allowed



Is that sufficient?
Any better ideas or other issues to consider?

Thanks,
Michael

RE: auth/tls combinations sanity check

[Michael Fox]

> > I can make up any variable name I want and assign a value to
> > it main.cf, and then reference its value in main.cf and master.cf?
> 
> Yes.
> 
> --
>   Viktor.

Ah.  That is indeed powerful.  

And now I understand your suggested solution, Viktor.  It even solves a
problem I didn't mention in that it allows me to offer both STARTTLS (with
enforced TLS for external clients) on port 457 and wrapper mode on port 465
(for internal or external clients that don't speak STARTTLS). 

Brilliant.  Thanks much!

Michael

RE: auth/tls combinations sanity check

[Michael Fox]

> > But looking at http://www.postfix.org/postconf.5.html, I don't find
> > mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions.  Are
> > those
> > literal names?  Where can I find documentation?
> 
> trick here is that we only ask for postconf -n, this will not display
> postconf -Mf :=)
> 
> with the above config its not needed to provide both
> 
> and its more readeble to see what happends when one edit main.cf, and
> not needing edit master.cf eath day

I'm not sure I understand you Benny.

Are you saying I can make up any variable name I want and assign a value to
it main.cf, and then reference its value in main.cf and master.cf?

If so, is that capability documented somewhere?  (When I couldn't find mua_*
in http://www.postfix.org/postconf.5.html, I looked for a statement to that
effect on http://www.postfix.org/  but could not find any indication that
that was allowed.)

Thanks,
Michael

RE: auth/tls combinations sanity check

[Michael Fox]

> > So, I'm thinking I need three submission ports:
> > * one for AUTH but no TLS
> > * one for AUTH with opportunistic TLS
> > * one for AUTH with enforced TLS
> 
> You can combine these into just one service by using:
> 
> main.cf:
>   mua_discard_ehlo_keyword_address_maps =
> cidr:${config_directory}/ehlo.cidr
> 
> master.cf:
>   submission inet ... smtpd
>   -o
> smtpd_discard_ehlo_keyword_address_maps=$mua_discard_ehlo_keyword_address_
> maps
> 
> ehlo.cidr:
>   192.0.2.1/32 starttls,silent-discard
> 
> to suppress TLS for some clients, and:
> 
> main.cf:
>mua_sender_restrictions =
> check_client_access cidr:${config_directory}/tlsclient.cidr
> 
> master.cf:
>submission inet ... smtpd
>   -o smtpd_sender_restrictions=$mua_sender_restrictions
> 
> tlsclient.cidr:
>   192.0.2.0/24 DUNNO
>   0.0.0.0/0   reject_plaintext_session
> 
> --
>   Viktor.

Wow.  Thank you!  That looks elegant and powerful.  It will take me some
time for me to absorb.

But looking at http://www.postfix.org/postconf.5.html, I don't find
mua_discard_ehlo_keyword_address_maps or mua_sender_restrictions.  Are those
literal names?  Where can I find documentation?

Thanks,
Michael

auth/tls combinations sanity check

[Michael Fox]

I have a possibly unusual AUTH/TLS combination requirement.  As a newbie, I
could use a sanity check.

Requirements:
* All virtual mail clients will use SASL AUTH
* Virtual mail clients on specific internal networks MUST NOT be offered
TLS.  This is to satisfy FCC requirements prohibiting the use of encryption
on certain radio frequencies.
* Other virtual mail clients on internal networks may choose to use TLS or
not.  (Some simple network appliances don't support TLS at all, or don't
support STARTTLS)
* Virtual mail clients from external networks (outside the firewall) MUST
use TLS. 


So, I'm thinking I need three submission ports:
* one for AUTH but no TLS
* one for AUTH with opportunistic TLS
* one for AUTH with enforced TLS

So, I'm thinking:

/etc/postfix/master.cf:

  # Submission for internal, radio clients; access controlled by IP address
in iptables
  2525 inet ...
-o smtpd_tls_security_level=none
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

  # Submission for internal, non-radio clients
  submission inet ...
-o smtpd_tls_security_level=may
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

  # Submission for external clients
  smtps inet ...
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
...

Does that make sense?
Is there a better way?
Is there anything I should keep in mind?

All comments and suggestions would be helpful.

Thanks,
Michael

RE: smtpd_sasl_security_options clarification

[Michael Fox]

> Yes, again from the quote from Wietse that you snipped out:
> 
> > Dovecot tells Postfix the supported mechanism names and their
> > security properties.

O.K.  Thanks.

I read but did not understand the quote above.  Your explanation was clearer
and I understood it the first time.

Thanks again,
Michael

RE: smtpd_sasl_security_options clarification

[Michael Fox]

> >
> > I think the actual security features list is dependant on the SASL
> > implementation, and which mechs satisfy each security feature is defined
> > in cyrus and dovecot sasl.

Ah.  So you're saying that for each auth mechanism configured in the SASL
implementation (dovecot in my case), the SASL implementation is sending
Postfix a tuple which includes the mechanism name and which categories it
fits into, rather than Postfix keeping a list of which mechanisms are in
each category.

Is that right?  If so, then that's clear enough.  

Michael

RE: smtpd_sasl_security_options clarification

[Michael Fox]

> 
> This is standard terminology, and therefore not defined in either
> Postfix or SASL RFC.
> 
> Active network attack: an attacker modifies the communication between
> parties.
> 
> Mutual authentication: each party authenticates to the other party.

Thanks.  But again, the question is *NOT* about the terminology or the
general meaning or definition of the categories.  The question is
specifically asking which authentication mechanisms Postfix places in those
categories.

> For more info I suggest a web search engine.

If I could find the answer, I wouldn't need to ask the question.  And
frankly, it doesn't matter what might be written elsewhere (which may or may
not be correct).  All that matters is what is actually implemented in
Postfix, i.e. which mechanisms are effected by the various
smtpd_sasl_security_options categories. 

Does anyone here know which mechanisms are effected by noactive,
nodictionary, forward_secrecy and mutual_auth?  Or does everyone stick with
"noanonymous, noplaintext".   

Thanks,
Michael

RE: smtpd_sasl_security_options clarification

[Michael Fox]

> In other words, how do I know which mechanisms will be
> > disallowed with "noactive" or "nodictionary" or allowed by
> "forward_secrecy"
> > or "mutual_auth"?  I'm unable to connect the dots.
> 
> You can find out about SASL active etc. attacks in RFC 4422
> https://tools.ietf.org/html/rfc4422
> 
>   Wietse

Thanks.  Yes, that describes the attack categories.  But it doesn't answer
the above question.  Is the categorization documented somewhere?  If not,
how are we to know?

Michael

RE: smtpd_sasl_security_options clarification

[Michael Fox]

> 
> Michael Fox:
> > http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says
> "the
> > following security features are defined for the cyrus server .".
> Dovecot is
> > not mentioned.  So, is it correct to interpret this to mean that this
> > postfix setting is a noop when dovecot is used for sasl authentication?
> 
> Hmm. that file hasn't been updated in a while. The list appears to
> be the same for dovecot.
> 
> > And how does Postfix know which authentication mechanisms to offer the
> > client?  Does dovecot communicate this to postfix somehow?
> 
> Dovecot tells Postfix the supported mechanism names and their
> security properties.  Postfix intersects that with the main.cf
> settings, and announces the mechanisms that remain.
> 
>   Wietse

O.K.  Thanks. 

Can be more specific about which SASL mechanisms are allowed or disallowed
by each option?  In other words, how do I know which mechanisms will be
disallowed with "noactive" or "nodictionary" or allowed by "forward_secrecy"
or "mutual_auth"?  I'm unable to connect the dots.

Thanks,
Michael

smtpd_sasl_security_options clarification

[Michael Fox]

http://www.postfix.org/postconf.5.html#smtpd_sasl_security_options says "the
following security features are defined for the cyrus server .".  Dovecot is
not mentioned.  So, is it correct to interpret this to mean that this
postfix setting is a noop when dovecot is used for sasl authentication?

 

And how does Postfix know which authentication mechanisms to offer the
client?  Does dovecot communicate this to postfix somehow?

 

Thanks,

Michael

 

 

 

RE: Newbie SASL Auth with Dovecot problem

[Michael Fox]

> 
> > I also tried port 25 and 587 from a separate machine that has an IP
> > address
> > in mynetworks.  In that case, EHLO is not even recognized:
> >
> > telnet  587
> > 220  ESMTP Postfix (Ubuntu)
> > EHLO client.example.com
> > 502 5.5.2 Error: command not recognized
> > HELO client.example.com
> > 250 
> > QUIT
> 
> FWIW: that's sometimes a symptom of a broken firewall that thinks it
> knows SMTP but does not, with the canonical example being a Cisco PIX in
> its default configuration.
> 
> That particular form doesn't look exactly like PIX-mangling, and I don't
> think PIX (or its ASA spawn) interfere with port 587 by default, so it's
> probably something else, but that something else may be something
> claiming to be providing you network security while in the process
> directly breaking the spec for port 587 mail submission. A port 587
> service that doesn't support EHLO is just antique SMTP on a weird port.

Thanks Bill,

I discovered it was actually due to a setting in PuTTY .  Under the Telnet
settings, the default for "Telnet negotiation mode" is "Active".  Setting it
to "Passive" cleared the problem.  Also, issuing a second EHLO also worked
(which led me to check the telnet settings).

Michael

RE: reject_sender_login_mismatch

[Michael Fox]

> 
> Specify, for example:
> 
> smtpd_sender_login_maps = hash:/etc/postfix/sasl_senders,
>pcre:/etc/postfix/sasl_default_senders
> 
> Where the contents of sasl_default_senders is, for example:
> 
> root# cat sasl_default_senders
> /^(.*)@domain$/ $1
> 
> Which restricts user@domain to the login "user".
> 
> The contents of sasl_senders would be for those cases that do not match
> the regular expression.
> 
> Mike
> 

Brilliant!  Thanks Mike.

Michael

reject_sender_login_mismatch

[Michael Fox]

 

I'm confused about how the reject_sender_login_mismatch restriction works.

 

"reject_sender_login_mismatch

Reject the request when $smtpd_sender_login_maps
  specifies
an owner for the MAIL FROM address, but the client is not (SASL) logged in
as that MAIL FROM address owner; or when the client is (SASL) logged in, but
the client login name doesn't own the MAIL FROM address according to
$smtpd_sender_login_maps
 ."

 

I also tried "reject_authenticated_sender_login_mismatch".

 

Assume a submission client logs in with SASL as "user@domain" and sends mail
with a MAIL FROM address of "user@domain".

 

If either $smtpd_sender_login_maps is null, or it points to a file that is
empty, then neither of the two conditions described for
reject_sender_login_mismatch are true.  (Note:  the conditions do not state
that the client login or the MAIL FROM address must be listed in
$smtpd_sender_login_maps.)  So, it seems to me that the mail should be
allowed.  But it is being blocked:

 

Jul  1 09:42:39 myhost postfix/submission/smtpd[10750]: NOQUEUE: reject:
RCPT from unknown[192.168.7.180]: 553 5.7.1 : Sender address
rejected: not owned by user user@domain; from=
to= proto=ESMTP helo=<[192.168.7.180]>

 

If $smtpd_sender_login_maps does exist, and the file includes an entry of:
"user@domain user@domain".  Then the mail is allowed.  But this means that
every valid MAIL FROM address has to be listed (twice) in the file.  

 

I can understand the value of this mapping if you want to allow a given SASL
login to use multiple MAIL FROM addresses.  But is there a way to require
that the MAIL FROM address must match the SASL logged in address, whatever
that address may be, without having to explicitly list each and every
address?

 

Thanks,

Michael

 

RE: how to prevent MX lookup of virtual_mailbox_domain

[Michael Fox]

> > Jun 30 20:12:31 myhost postfix/submission/smtpd[28379]: warning: Unable
> to
> > look up MX host for my.virtual.domain: Host not found, try again
> >
> > Why is this happening?
> 
> Because YOU configured something that requires MX lookups:
> check_*_mx_access, reject_unknown_sender_domain,
> reject_unknown_recipient_domain, and so on.
> 
>   Wietse

Thanks (and sorry -- trying hard but still learning).
Reject_unknown_sender_domain was the culprit.  I guess I've got to
reconsider the smtpd restriction order.

Michael

how to prevent MX lookup of virtual_mailbox_domain

[Michael Fox]

I have defined:

virtual_alias_maps = hash:/etc/postfix/virtual

virtual_mailbox_domains = my.virtual.domain  (sanitized)

virtual_mailbox_maps = hash:/etc/postfix/vmailbox

virtual_transport = lmtp:unix:private/dovecot-lmtp

 

I'm still testing/configuring locally, so I haven't created the DNS MX
record for my.virtual.domain yet.

 

When a client submits a message to a mailbox in that domain
(user@my.virtual.domain), I get the following in /var/log/mail.log

 

Jun 30 20:12:31 myhost postfix/submission/smtpd[28379]: warning: Unable to
look up MX host for my.virtual.domain: Host not found, try again

 

Why is this happening?

In other words, with virtual_mailbox_domains defined, doesn't Postfix know
that it is responsible for handling that domain?  And, if so, then why is it
trying to find an MX? 

Is there a way to tell Postfix not to bother looking for an MX?

 

Thanks,

Michael

 

RE: Newbie SASL Auth with Dovecot problem

[Michael Fox]

> 
> I don't see any
> 
>  smtpd_sasl_auth_enable = yes
> 
> in your `postconf -n` output although you claim to have set it.  The
> default would be "no".
> 
> Matthias

Oh, jeez.  How embarrassing.  Thanks Matthias.

I had entered smtp_... instead of smtpd_... 

And no matter how many times I looked, I just didn't see it.

Michael

RE: Newbie SASL Auth with Dovecot problem

[Michael Fox]

> 
> There is no AUTH on port 25, take 587.
> 
> Suomi

According to http://www.postfix.org/SASL_README.html#server_sasl_authc I
should see AUTH on port 25.

I also tried port 587.  Same result.

$ telnet localhost 587
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220  ESMTP Postfix (Ubuntu)
EHLO client.example.com
250-
250-PIPELINING
250-SIZE 102400
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
Connection closed by foreign host.
$

I also tried port 25 and 587 from a separate machine that has an IP address
in mynetworks.  In that case, EHLO is not even recognized:

telnet  587
220  ESMTP Postfix (Ubuntu)
EHLO client.example.com
502 5.5.2 Error: command not recognized
HELO client.example.com
250 
QUIT

Mail.log:
Jun 27 23:23:32 n6mef-gw postfix/smtpd[28356]: connect from
unknown[192.168.7.180]
Jun 27 23:24:32 n6mef-gw postfix/smtpd[28356]: disconnect from
unknown[192.168.7.180]
Jun 27 23:27:29 n6mef-gw postfix/submission/smtpd[28387]: connect from
unknown[192.168.7.180]
Jun 27 23:28:10 n6mef-gw postfix/submission/smtpd[28387]: disconnect from
unknown[192.168.7.180]

Apparently there's something more fundamental that I'm missing.  But I sure
can't figure it out.

Michael

Newbie SASL Auth with Dovecot problem

[Michael Fox]

I've been using Postfix for a while with no client submission.  I'm trying
to set up SASL for the first time, using Dovecot, to support virtual users.


When I connect with EHLO, I do NOT see "AUTH" capabilities.

 

Of course, I'm following:  http://www.postfix.org/SASL_README.html

 

First of all, Dovecot is installed and authentication works

$ telnet localhost 110

Trying 127.0.0.1...

Connected to localhost.localdomain.

Escape character is '^]'.

+OK Dovecot ready.

user @

+OK

pass secret

+OK Logged in.

quit

+OK Logging out.

Connection closed by foreign host.

$

 

And mail is delivered to the virtual mailboxes just fine.  This tells me
that the Dovecot passdb and userdb are working.

 

Now, following the SASL_README:

 

$ postconf -a

cyrus

dovecot

$ postconf -A

cyrus

 

I followed the instructions in SASL_README for "Configuring Dovecot SASL",
plus .

smtpd_sasl_type = dovecot

smtpd_sasl_path = private/auth

smtpd_sasl_auth_enable = yes

 

The socket exists

 

~$ sudo ls -l /var/spool/postfix/private

total 0

.

srw-rw 1 postfix postfix 0 Jun 27 18:55 auth

.

$

 

After reload, the next step in the README is to try a connection.  But I
don't get any AUTH options:

 

$ telnet localhost 25

Trying 127.0.0.1...

Connected to localhost.localdomain.

Escape character is '^]'.

220 x ESMTP Postfix (Ubuntu)

EHLO client.example.com

250-x

250-PIPELINING

250-SIZE 102400

250-VRFY

250-ETRN

250-ENHANCEDSTATUSCODES

250-8BITMIME

250 DSN

QUIT

221 2.0.0 Bye

Connection closed by foreign host.

$

 

I don't know what to do next.  Thanks for any help.

 

Thanks,

Michael

 

 

$ postconf -n

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

anvil_rate_time_unit = 60s

append_at_myorigin = yes

append_dot_mydomain = yes

biff = no

bounce_queue_lifetime = 8h

bounce_template_file = /etc/postfix/bounce.cf

broken_sasl_auth_clients = yes

canonical_maps = pcre:/etc/postfix/canonical.pcre

config_directory = /etc/postfix

content_filter = amavisfeed:[127.0.0.1]:10024

delay_warning_time = 2h

fast_flush_domains = $relay_domains

header_checks = pcre:/etc/postfix/header_checks.pcre

html_directory = /usr/share/doc/postfix/html

inet_interfaces = all

mailbox_size_limit = 512

maximal_queue_lifetime = 8h

message_size_limit = 102400

mydestination = $myhostname localhost.$mydomain localhost.localdomain
localhost

mydomain = 

mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.8.0/24

myorigin = /etc/mailname

postscreen_access_list = permit_mynetworks
cidr:/etc/postfix/postscreen_access.cidr

postscreen_blacklist_action = drop

postscreen_dnsbl_action = enforce

postscreen_dnsbl_reply_map =
pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre

postscreen_dnsbl_sites = zen.spamhaus.org*3 bl.spameatingmonkey.net*2
psbl.surriel.com*2 bl.spamcop.net hostkarma.junkemailfilter.com=127.0.0.2
dnsbl.sorbs.net bl.mailspike.net swl.spamhaus.org*-4
list.dnswl.org=127.0.[0..255].0*-1 list.dnswl.org=127.0.[0..255].1*-2
list.dnswl.org=127.0.[0..255].2*-3 list.dnswl.org=127.0.[0..255].3*-4

postscreen_dnsbl_threshold = 3

postscreen_dnsbl_ttl = 5m

postscreen_greet_action = enforce

proxy_interfaces = 

readme_directory = /usr/share/doc/postfix

recipient_delimiter = +

relay_domains = n6mef.ampr.org

relay_recipient_maps = pcre:/etc/postfix/relay_recipients.pcre

relay_restrictions = check_sender_access
pcre:/etc/postfix/relay_sender_access.pcre

remote_header_rewrite_domain = invalid.domain

smtp_host_lookup = native

smtp_sasl_auth_enable = yes

smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)

smtpd_client_connection_count_limit = 10

smtpd_client_connection_rate_limit = 10

smtpd_client_restrictions = permit_mynetworks
reject_unknown_reverse_client_hostname check_client_access
pcre:/etc/postfix/client_access.pcre reject_rbl_client zen.spamhaus.org
permit

smtpd_data_restrictions = reject_unauth_pipelining
reject_multi_recipient_bounce permit

smtpd_delay_reject = yes

smtpd_error_sleep_time = 5s

smtpd_etrn_restrictions = permit_mynetworks reject

smtpd_hard_error_limit = 10

smtpd_helo_required = yes

smtpd_helo_restrictions = reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname permit_mynetworks reject_unknown_helo_hostname
check_helo_access pcre:/etc/postfix/helo_access.pcre permit

smtpd_junk_command_limit = 2

smtpd_recipient_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
check_recipient_access pcre:/etc/postfix/recipient_access.pcre
check_recipient_access pcre:/etc/postfix/relay_recipient_access.pcre permit

smtpd_reject_unlisted_recipient = yes

smtpd_restriction_classes = relay_restrictions

smtpd_sasl_path = private/auth

smtpd_sasl_type = dovecot

smtpd_sender_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain permit_mynetworks check_sender_access

RE: RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

Got it.  Thanks much Peter!


Michael


> -Original Message-
> From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
> us...@postfix.org] On Behalf Of Peter
> Sent: Saturday, June 4, 2016 11:30 PM
> To: postfix-users@postfix.org
> Subject: Re: RBLs in postscreen AND smtpd_*_restrictions
> 
> On 05/06/16 17:10, Michael Fox wrote:
> > Right.  As I mentioned, I understand that part.  My question was about
> v3.1+
> > where the default for postscreen_dnsbl_min_ttl is only 60s.  And, as I
> > understand it, the defaults for v3.1 would cause both the postscreen
> cache
> > ttl and the system resolver's cache ttl to be based on the same ttl from
> the
> > actual DNSBL record, thus rendering the same result for both, and the
> same
> > timeout for both.
> >
> > Unless I've got that wrong, no need to respond.
> 
> I think you have it mostly right, but there are some cases where the
> results could differ between postscreen and smtpd:
> 
> 1.  There will be a very small window of time (we're talking
> milliseconds) between when postscreen checks the expire time and when
> smtpd attempts to lookup the record.  The DNS record could expire during
> this very small window of time and if it has changed since the last time
> that the resolver fetched the record the result could be different.
> 
> 2.  The resolver might be broken and not caching the record, or caching
> it for a shorter or longer period of time than the TTL states.
> 
> 3.  You could (as is common) have two different resolvers listed in your
> resolv.conf (or your OSes equivalent) file.  These resolvers could have
> cached the record at different times, and if the record was updated in
> between they could have different results.  It is possible that
> postscreen could have randomly hit one resolver and smtpd hits the other
> thereby giving different results.
> 
> 
> Peter

RE: RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

> If postscreen_dnsbl_ttl or postscreen_dnsbl_min_ttl is 3600 (1 hour) but
> the minimum TTL field of the DNSBL's SOA record is 10 (as it is for the
> SBL) then postscreen will cache the lack of a DNSBL entry for as much as
> 59 minutes and 50 seconds longer than a proper caching resolver, which
> will keep the negative response for 10 seconds at most (unless it's an
> older Microsoft DNS server or a broken Unbound instance that has been
> given a minimum TTL...)

Right.  As I mentioned, I understand that part.  My question was about v3.1+
where the default for postscreen_dnsbl_min_ttl is only 60s.  And, as I
understand it, the defaults for v3.1 would cause both the postscreen cache
ttl and the system resolver's cache ttl to be based on the same ttl from the
actual DNSBL record, thus rendering the same result for both, and the same
timeout for both.

Unless I've got that wrong, no need to respond.  


> > Also, for pre v3.1 users, is there a best practice recommended value
> > for
> > postscreen_dnsbl_ttl that is better than the default of 1 hour?
> 
> I cannot tell you who you are... :)

Of course not.  But we can all learn from the experience and reasoning of
others.  What you're doing doesn't necessarily apply to what I need.  But
your willingness to explain both what you did and WHY you did it helps me to
understand the choices and consequences that I might also need to consider.
VERY helpful.


> However, for almost everyone, an hour is too long. [clipped]

O.K.  Your description helped verify that my own reasoning was on the right
track.

Thanks again for taking the time to explain.

Michael

RE: RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

> > And, conversely, DNSBLs with
> > weights < postscreen_dnsbl_threshold should not be listed in
> > smtpd_*_restrictions because they could block an email on their own,
> > even
> > though they are not trusted to do so by postscreen.
> 
> Not in all cases. Where postscreen by necessity offers limited ability
> to whitelist sessions from DNSBL interference, the threshold mechanism
> allows lists with different sorts of exceptional cases to block mail
> only when multiple lists concur on a listing, effectively whitelisting
> IPs based on how many lists of what scores they appear on. Yet you may
> want to trust those lists as a basis to reject mail by default on their
> own, with exceptions based on criteria that postscreen cannot use.
 
[hypothetical example clipped]

Thank you very much Bill!  I had not thought of that type of situation and
that's exactly the type of example that I needed to help me understand the
nuance.

> 
> > If a DNSBL in postscreen_dnsbl_sites has a weight >=
> > postscreen_dnsbl_threshold, then is there any advantage to also
> > listing it
> > in smtpd_*_restrictions?  For example, is there some failure mode that
> > having the DNSBL listed in both places would protect against?
> 
> As noted by Allen Coates, if postscreen_dnsbl_ttl (v2.8-v3.0) or
> postscreen_dnsbl_min_ttl (3.1) is higher than the negative cache TTL for
> a DNSBL, postscreen can 'PASS OLD' an IP which has been listed in the
> period since its prior connection during which the resolver cache of the
> negative result has expired, so smtpd can see a listing that postscreen
> does not.

This is what I'm still a little fuzzy on.

In v2.8-3.0, and assuming the postscreen_dnsbl_ttl default of 1 hour, I can
understand Alan's example.  A new bad guy starts up and gets through the
first time, which postscreen caches for a default of 1 hour.  The bad guy
then starts his attacks within that hour of time and gets added to DNSBLs.
But postscreen doesn't see it for an hour, while smtpd does (assuming the
actual DNSBL's TTL is < 1 hour).  I think I understand that part.

But in v3.1, with the default postscreen_dnsbl_min_ttl of 60 seconds, and
postscreen using the actual TTL from the DNSBL, it seems like that issue no
longer exists.  Here's my understanding:  Using the same scenario,
postscreen caches the positive answer on the first connect.  And, according
to Wietse, smtpd uses the same caching resolver.  So when smtpd does the
lookup probably less than a second later, it should get the answer from the
resolver's cache, which should be the same answer that postscreen got.  Now
the bad guy starts his attacks and gets added to the DNSBLs.  If the TTL has
not yet expired, then postscreen uses it's positive cached value and smtpd
will still get a positive answer from the resolver's cache.  If the TTL has
expired, then both postscreen and smtpd would get a new, negative answer.
There may be miniscule differences in timing.  But I would think the results
would be virtually identical.

Is that right?  If not, what am I missing?

Also, for pre v3.1 users, is there a best practice recommended value for
postscreen_dnsbl_ttl that is better than the default of 1 hour?

Thanks,
Michael

RE: RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

> postscreen will query the DNS when the client connects after
> postscreen_dnsbl_ttl has expired. With Postfix 3.1 and later,
> that time is (also) determined by a TTL in the DNS response.

Thanks for the clarification Wietse.  2 questions:

1)  Given that DNSBLs in postscreen_dnsbl_sites and smtpd_*_restrictions use
the same caching resolver and the same timeouts, they should produce the
same result.  Correct?  If so, then is there any reason at all for putting a
DNSBL in smtpd_*_restrictions if postscreen is already set up with a set of
weighted DNSBLs?  Or, put another way, is there any failure mode that
listing the DNSBL in both places might prevent?  Please explain.

2)  Please confirm my understanding of the postscreen_cache_retention_time:
2a)  A client that previously passed the pre-greet test will face the
pre-greet test again if postscreen_greet_ttl has expired, even if
postscreen_cache_retention_time has not expired.  Correct?
2b)  A client that previously passed the DNSBL test will be face the DNSBL
test again if postscreen_dnsbl_ttl has expired, even if
postscreen_cache_retention_time has not expired.  Correct?
2c)  A client that has previously passed the pre-greet and DNSBL tests, and
connects again before postscreen_cache_retention_time has expired, will be
logged as "PASS OLD" instead of "PASS NEW", regardless of whether or not the
pre-greet and/or DNSBL tests had to be rerun this time.  Correct?
2d)  The result of "tests after the 220 SMTP server greeting" are cached for
postscreen_cache_retention_time.  Correct?

Thanks,
Michael

RE: RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

> On 02/06/16 17:45, Michael Fox wrote:
> > If a DNSBL in postscreen_dnsbl_sites has a weight >=
> > postscreen_dnsbl_threshold, then is there any advantage to also
> > listing it in smtpd_*_restrictions? For example, is there some failure
> > mode that having the DNSBL listed in both places would protect
> > against? Michael
> 
> I frequently have remote hosts which pass the pregreet and DNSBL tests,
> and then repeatedly access the server with a "PASS OLD" result from
> postscreen.  Usually they try to send unauthorised relay messages.
> 
> The entry in smtpd_*_restrictions would pick these up as their DNSBL
> status changes.
> 
> Allen C

Thanks Allen.

Ahhh.  
So, taking into account what Wietse just said about DNSBL lookups in
postscreen and smtpd sharing the same caching resolver, then, if I
understand you correctly, adding the same DNSBL to smtpd_*_restrictions
would catch the case where postscreen_dnsbl_ttl has expired for a given
client, but postscreen_cache_retention_time (default=7d) has not.  Is that
correct?

Michael

RE: RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

> Michael Fox:
> > Clarification:  I seem to recall someone asking whether they should
> leave
> > RBLs in the smtpd_*_restrictions now that they've added them to
> postscreen.
> > And I seem to recall that the answer was something like "why not, it
> doesn't
> > hurt".  But it seems to me that if would hurt because: a) it adds a
> > redundant lookup (unless the postscreen cache is shared with postfix)
> and,
> > b) unless they all have the same weight in postscreen, then postfix
> would
> > reject on any one RBL, which would make the weighting in postscreen
> moot.
> > Hence, my question.
> 
> smtpd and postscreen use the same caching resolver, so the "extra"
> queries don't travel far over the network. So the anser is "it
> should not hurt".
> 
> That said, postscreen versions before 3.1 ignore the DNS reply TTL
> (or its equivalent for NXDOMAIN replies) and use postscreen_dnsbl_ttl=1h
> by default. That was fine when I wrote postscreen 5 years ago, but
> it may be longer than the TTLs that some DNS reputations use these
> days.

Thanks Wietse.

So, as I understand it:  as long as the weight assigned to a DNSBL in
postscreen is >= postscreen_dnsbl_threshold, then there is no harm in also
adding the same DNSBL to smtpd_*_restrictions.  And, conversely, DNSBLs with
weights < postscreen_dnsbl_threshold should not be listed in
smtpd_*_restrictions because they could block an email on their own, even
though they are not trusted to do so by postscreen.

If a DNSBL in postscreen_dnsbl_sites has a weight >=
postscreen_dnsbl_threshold, then is there any advantage to also listing it
in smtpd_*_restrictions?  For example, is there some failure mode that
having the DNSBL listed in both places would protect against?

Michael

RBLs in postscreen AND smtpd_*_restrictions

[Michael Fox]

I think I recall seeing something about this a while ago, but I can't find
it in the archives.

 

If I'm using several RBLs in postscreen_dnsbl_sites, each with its own
weighting, then what is the best practice for using at least some of those
RBLs in smtpd_*_restrictions, or not?  

 

Thanks,

Michael

 

 

RE: Need clarification of lookup table result values

[Michael Fox]

> The access(5) manpage is for the Postfix SMTP DAEMON. It says so
> on the first line of the manpage, and it says so again in the first
> paragraph.
>
> The postscreen_access_list parameter, as the name suggests, is for
> the POSTSCREEN DAEMON. This name is as explicit as it can be, without
> changing the name to this_is_not_smtpd_this_is_postscreen_access_list.

Ah. O.K.  My original post said that I'm trying to configure
postscreen_access.cidr, but also want to understand things more generally.
I didn't see any differentiation between the two parts in your answer.  In
fact, "... an access table expects results as described in the access(5)
manpage ..." led me in the opposite direction, thinking that, since
postscreen_access.cider is "an access table", then access(5) must apply.
Now I understand.  Thanks.

> 
> Here is a summary of the definition in the postconf(5) manpage:
> 
> postscreen_access_list (default: permit_mynetworks)
>Permanent   white/blacklist   for  remote  SMTP  client  IP
> addresses.
>postscreen(8) searches this list immediately after a remote SMTP
> client
>   ...
> 
> permit_mynetworks
>   ...
> 
> type:table
>   ...
> 
> permit
>   ...
> 
> reject
>   ...

Yes.  If it helps, my confusion started here.  The above paragraph lists
permit, reject and dunno.  But doesn't say they are the only values.  It
also says to use a CIDR table.  And the CIDR table page shows an example
using "OK".  It does not say that "OK" doesn't work for postscreen.  Hence,
my original question about "OK" vs. "permit".  Now I understand.  Thanks.

What about case?  The other result values in various table examples
(including the CIDR table example) are in caps ("OK", "REJECT",...).  But
postconf(5) shows the values of postscreen_access_list to be in lower case.
Should permit/reject/dunno be strictly lowercase in the
postscreen_access.cider table, or does upper case also work?

Thanks,
Michael 

RE: Need clarification of lookup table result values

[Michael Fox]

 
> What is a valid result depends on what the result is used for: an
> access table expects results as described in the access(5) manpage,
> a virtual aliases table expects  the results as described in the
> virtual(5) manpage, a transport table expects results as described
> in the transport(5) manpage, a the local aliases table expects
> results as described in the aliases(5) manpage. You get the idea.

Generally speaking, yes.  But it's not so clear (to me) when applying to a
specific case, like postscreen_access.

> 
> > 2)  Is there a difference between "OK" and "permit"?  If so, what?
> > 3)  When can/should text follow the "reject"
> 
> Those things are described in the access(5) manpage.

Hmmm ... I don't see it.

The access(5) manpage lists many valid result formats, including OK.
Regarding OK and permit, it says:

OK Accept the address etc. that matches the pattern.

... and then the only mention of permit is:

restriction...
  Applythe   named   UCE   restriction(s)   (permit,
reject,
  reject_unauth_destination, and so on).


So I don't see the answer.  In fact, OK doesn't seem to make sense for
postscreen_access.  After all, OK what?  OK blacklist the address?  OK
whitelist the address?  

I realize the difficulty of documenting something that's so infinitely
flexible.  But without saying more explicitly what's allowed and what's not,
there's just too much indirection (for me) to follow. 

So, back to my original question ... for postscreen_access.cidr:
-- what would be the difference in behavior between using "OK" vs. "permit"?
-- when can/should text follow the reject?

Also, I can't find anywhere that says if the case matters.  Is "PERMIT"
equivalent to "permit"?

Thanks,
Michael

Need clarification of lookup table result values

[Michael Fox]

I need some help understanding the valid "result" values that can be used in
Postfix lookup tables and what the result values do.  The examples I see in
various places in the docs seem to contradict each other.

 

As just one example, I'd like to configure postscreen_access.cidr.  But I
also need a broader understanding.

 

http://www.postfix.org/DATABASE_README.html says nothing about result values

http://www.postfix.org/POSTSCREEN_README.html shows an example that uses
"permit" and reject" for a CIDR table.

But http://www.postfix.org/cidr_table.5.html shows only an example that uses
"OK" and "REJECT" without explaining their meaning/effect. 

http://www.postfix.org/access.5.html describes the effect of a variety of
results for access-type tables.  It says it works for DB, REGEXP and PCRE
tables and smtpd, but it doesn't say that it works for CIDR tables nor for
postscreen.

 

So this leaves me with the following questions:

1)  How can I tell which result values can be used in any given lookup
table?

2)  Is there a difference between "OK" and "permit"?  If so, what?

3)  When can/should text follow the "reject"

4)  Does "dunno" work the same as described in
http://www.postfix.org/access.5.html

5)  More generally, for any given table, how would I determine which
result values are allowed and what they will do?

 

Thanks in advance,

Michael

 

RE: Header Filtering

[Michael Fox]

  /^Received:\s+from\s+domain\.example\s+/ ...

I may be the least expert on this list so take what I say with a grain of
salt.  But this observation may be helpful:

I have seen several cases where there was no space between the
Header-name: and the header value.  In particular, I have seen this in
both the From: and Message-ID: headers.  I know this because I wrote a
little script to read a mail file and report the From:, To:, Subject:, and
Message-ID: values on some mailboxes I was watching.  My script expected a
space after the Header-name.  Occasionally it would return null for a
header value.  Looking at the actual mail file, I found it to be missing the
space after the header name.  In all cases that I'm aware of, the messages
were handled just fine by Postfix.  I don't know if the same is true of
Received: header since my script wasn't looking at that header line.

My point:  perhaps you want to use :\s* instead of :\s+ or else you might
miss an occasional message.

Michael

RE: Bandwidth choke issue between remote offices and SMPT server.

[Michael Fox]

 



I am facing problem of bandwidth choke issue between remote location and
SMPT server. 
Please giude for below. Want to know how the other busy servers are handling
such issues. 

Jayesh, this is what QoS/prioritization are for on your routers.  The
specifics will depend on what type of router/firewall you have (and beyond
the scope of this list).  But generally, set your email traffic to a lower
priority.  Your interactive traffic will be much more consistent and your
email traffic will never know the difference.

 

Michael

RE: postscreen vs. fail2ban

[Michael Fox]

Sebastian, Wietse, Noel:  thanks for your responses re Postscreen vs.
Fail2ban.

Michael

postscreen vs. fail2ban

[Michael Fox]

I haven't implemented postscreen yet, but plan to.  So this question is for
the postscreen experts here.

 

As I understand it from the documentation, postscreen protects postfix from
having to deal with most attack vectors, including higher volume attacks.
So, does it make sense to also use something like fail2ban to block IPs that
postscreen (or postfix) logs repeatedly as offenders?  Or is postscreen
sufficient to protect posfix?  

 

Thanks much,

Michael

 

RE: Recipient address rejected: Domain not found

[Michael Fox]

Thanks Victor.  This is exactly what I was looking for.

Thanks Noel:  yes, I messed up and wrote the wrong parameter.  Yes,
reject_unknown_recipient_domain is what I meant.  But thanks for the
additional details.

Thanks li...@rhsoft.net:  I didn't make it clear that I was referring to
outgoing, not incoming.  Hence the reference to DNS.  But thanks for
responding.

I've got what I need, now.  Thanks all.

Michael


 -Original Message-
 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] On Behalf Of Viktor Dukhovni
 Sent: Monday, January 19, 2015 12:43 PM
 To: postfix-users@postfix.org
 Subject: Re: Recipient address rejected: Domain not found
 
 On Mon, Jan 19, 2015 at 12:12:34PM -0800, Michael Fox wrote:
 
  450 4.1.2 u...@nohow.noway.org: Recipient address rejected: Domain not
 found
 
 Turn off the default safety net, I have:
 
 unknown_address_reject_code = 550
 unknown_client_reject_code = 550
 unknown_hostname_reject_code = 550
 unverified_recipient_reject_code = 550
 unverified_sender_reject_code = 550
 
 I've left plaintext_reject_code at its default value.  See:
 
 http://www.postfix.org/postconf.5.html#unknown_address_reject_code
 http://www.postfix.org/postconf.5.html#unknown_client_reject_code
 http://www.postfix.org/postconf.5.html#unknown_hostname_reject_code
 
 http://www.postfix.org/postconf.5.html#unverified_recipient_reject_code
 http://www.postfix.org/postconf.5.html#unverified_sender_reject_code
 
  What seems reasonable to me is the following:
 
  -- If postfix receives a response from DNS that the domain does not
 exist,
  then reject with 550
 
 That's the behaviour without the safety net.
 
  -- Otherwise, delay with 450 (DNS failure, etc.)
 
  http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient says
 one
  can use unverified_recipient_reject_code to change the 450 (temporary)
  failure to a 550 (permanent) failure when you trust Postfix's
 judgments.
 
 The reject_code's should be changed in production systems once the
 configuration is otherwise correct.
 
  As a newbie, I'm cautious about changing values from their default
 because
  I'm sure the default was chosen for a reason.
 
 In this case an initial deployment safety net, that should be removed once
 the configuration is believed correct.
 
  1)  Can someone explain what when you trust Postfix's judgments means,
  specifically?
 
 Your DNS is not broken.  Your main.cf settings are not broken.
 
  2)  What do you gurus do/recommend with
 unverified_recipient_reject_code?
 
 See above.
 
  3)  If you do recommend changing unverified_recipient_reject_code to
 550,
  is there anything to watch out for?
 
 Rejection of mail you wanted accepted, but the best time to watch
 out for that is while the safety net is still in place.
 
 --
   Viktor.

Recipient address rejected: Domain not found

[Michael Fox]

I have a question about the situation where postfix receives a connection
from a client trying to send to an invalid recipient address such as
u...@nohow.noway.org.

 

Currently, postfix responds with:

 

450 4.1.2 u...@nohow.noway.org: Recipient address rejected: Domain not
found

 

What seems reasonable to me is the following:

-- If postfix receives a response from DNS that the domain does not exist,
then reject with 550

-- Otherwise, delay with 450 (DNS failure, etc.)

 

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient says one
can use unverified_recipient_reject_code to change the 450 (temporary)
failure to a 550 (permanent) failure when you trust Postfix's judgments.

 

As a newbie, I'm cautious about changing values from their default because
I'm sure the default was chosen for a reason.  But, I don't why the default
would be to send back a temporary failure (450) if we get an answer from DNS
that the domain doesn't exist.  It seems like this needlessly leaves the
message in the client's queue, where it tries to send over and over, just
because maybe the domain might exist sometime in the future.  But I'm a
newbie and certainly don't know what all of the subtleties and unintended
consequences would be if I were to change unverified_recipient_reject_code
to 550.  

 

So:

1)  Can someone explain what when you trust Postfix's judgments means,
specifically?

2)  What do you gurus do/recommend with unverified_recipient_reject_code?

3)  If you do recommend changing unverified_recipient_reject_code to 550,
is there anything to watch out for?

 

Thanks much,

Michael

 

 

 

RE: header checks for a relay client

[Michael Fox]

  What you can do is create a restriction class to check the sender
  and the recipient, and reject the message if both match.  The
  general procedure is outlined here, with some examples similar to
  what you're asking:
  http://www.postfix.org/RESTRICTION_CLASS_README.html

I don't see how this addresses the problem of rejecting messages that are
both:
-- From: a certain address (or domain), and
-- To: a certain address (or domain).

For example, I'd like to block messages if:
The sender matches /.*@yahoogroups\.com/
-and-
The recipient matches /.*@client[1-6]\.domain2\.com/

Would you be so kind as to provide an example?

Thanks much,
Michael

RE: header checks for a relay client

[Michael Fox]

 -Original Message-
 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] On Behalf Of Michael Fox
 Sent: Wednesday, September 24, 2014 10:24 AM
 To: 'postfix users'
 Subject: RE: header checks for a relay client
 
   What you can do is create a restriction class to check the sender
   and the recipient, and reject the message if both match.  The
   general procedure is outlined here, with some examples similar to
   what you're asking:
   http://www.postfix.org/RESTRICTION_CLASS_README.html
 
 I don't see how this addresses the problem of rejecting messages that are
 both:
 -- From: a certain address (or domain), and
 -- To: a certain address (or domain).
 
 For example, I'd like to block messages if:
   The sender matches /.*@yahoogroups\.com/
   -and-
   The recipient matches /.*@client[1-6]\.domain2\.com/
 
 Would you be so kind as to provide an example?
 
 Thanks much,
 Michael

I really could use more examples in the documentation to help me synthesize
how all the parts fit together.  But I'm trying.  Would the following work?

main.cf:
smtpd_recipient_restrictions =
check_recipient_access
pcre:/etc/postfix/no_yahoo_groups_recipients.pcre


smtpd_restriction_classes = reject_yahoo_groups_sender
reject_yahoo_groups_sender = check_sender_access
pcre:/etc/postfix/reject_yahoo_groups_sender.pcre


/etc/postfix/no_yahoo_group_recipients.pcre:
/client[1-6]\.domain2\.com/ reject_yahoo_groups_sender


/etc/postfix/reject_yahoo_groups_sender.pcre
/@yahoogroups\.com/ REJECT


Michael

RE: header checks for a relay client

[Michael Fox]

Thanks much.

 That looks about right.
 
 Good Practice Note: anchor/narrow your expressions to make them as
 specific as possible to prevent unexpected behavior. This is
 especially important if you intend to discard mail:
 /@client[1-6]\.domain2\.com$/
 /@yahoogroups\.com$/
 
 
   -- Noel Jones

header checks for a relay client

[Michael Fox]

Sanity check please:

 

I have a relay machine:  relay.domain1.com

And a client:  client.domain2.com

 

I'd like to filter (silently discard) messages at the relay machine from
going to any account on the client machine if the From: address is:
groupsupda...@yahoogroups.com mailto:groupsupda...@yahoogroups.com .  But
such messages going to accounts on the relay machine are o.k.

 

So, is it correct that I could use something like this:

 

main.cf:

smtp_header_checks = pcre:/etc/postfix/smtp_header_checks.pcre

 

smtp_header_checks.pcre:

/^From: .*groupsupda...@yahoogroups.com.*/
mailto:.*groupsupda...@yahoogroups.com.*/   DISCARD optional-log-text

 

 

Thanks,

Michael

 

RE: header checks for a relay client

[Michael Fox]

 What you can do is create a restriction class to check the sender
 and the recipient, and reject the message if both match.  The
 general procedure is outlined here, with some examples similar to
 what you're asking:
 http://www.postfix.org/RESTRICTION_CLASS_README.html
 
 Alternately, you can use a policy service such as postfwd to reject
 mail with a combination of sender and recipient.
 http://www.postfix.org/SMTPD_POLICY_README.html
 http://postfwd.org/

O.K.  Thanks.  I'll read up on those.

BTW, I do realize that silent discard is not really correct.  But the
problem is that Yahoo groups isn't behaving correctly.  It has been
configured to send no e-mail to the accounts in question.  And it doesn't
send regular group discussion e-mail.  But it still sends announcement
e-mails, such as when someone posts a file.  Evidently, no e-mail isn't
really no e-mail.  If I bounce the emails, there's the potential that the
Yahoo system may delist the accounts because of bounces.  So I plan to
silently discard the mail that Yahoo shouldn't be sending in the first
place.

Thanks again,
Michael

Restricting relay of attachments

[Michael Fox]

Sorry if this is a bit simple, but I can't seem to figure out how the
components fit together.

 

Given the following:

1)  MX/Relay machine running postfix:  relay.domain1.com

2)  Client machine:  client.domain2.com

 

I'd like to restrict/deny (5xx permanent error) incoming messages from the
Internet to client.domain2.com if they contain attachments.  But no such
restriction should be applied to other clients or to users on
relay.domain1.com.

 

I presume this would be done with some type of header check plus some type
of restriction class.  If that's true, then I need some help with both.  If
I don't even have that right, I'll need a some more help.   ;-)

 

Thanks,

Michael

 

RE: Restricting relay of attachments

[Michael Fox]

Hmmm.  O.K.  Thanks to both of you.  It will take me some time to think this
through.

The level of indirection between main.cf and master.cf sure adds
flexibility.  But, as someone who doesn't work in postfix every day or even
every week, it also leaves my head spinning.  ;-)

Thanks again.
Michael


 -Original Message-
 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] On Behalf Of Wietse Venema
 Sent: Wednesday, September 10, 2014 6:54 AM
 To: Postfix users
 Subject: Re: Restricting relay of attachments
 
 On 9/10/2014 1:24 AM, Michael Fox wrote:
  I'd like to restrict/deny (5xx permanent error) incoming messages
  from the Internet to client.domain2.com if they contain
  attachments.  But no such restriction should be applied to other
  clients or to users on relay.domain1.com.
 
 Noel Jones:
  Header_checks and/or restriction classes are the wrong tool for
  this.  You'll need some external
  milter/content_filter/smtpd_proxy_filter with per-destination controls.
 
 Correct. However, if you have separate mail streams for mail clients
 (TCP port submission/587 or smtps/465) and for MX service (TCP port
 25), then you can apply different policies to each stream.
 
 /etc/postfix/main.cf:
 mua_cleanup_service =  mua_cleanup
 mua_header_checks = ...
 mua_body_checks = ...
 
 /etc/postfix/master.cf:
 smtp  inet  n   -   n   -   -   smtpd
 mua_cleanup unix n  -   n   -   0   cleanup
 -o header_checks=mua_header_checks
 -o body_checks=mua_body_checks
 submission inet n   -   n   -   -   smtpd
 -o cleanup_service=$mua_cleanup_service
 -o syslog_name=postfix/submission
 ...[see sample master.cf file for more]...
 smtps inet  n   -   n   -   -   smtpd
 -o cleanup_service=$mua_cleanup_service
 -o syslog_name=postfix/smtps
 -o smtpd_tls_wrappermode=yes
 ...[see sample master.cf file for more]...
 
 By keeping the mua_xxx parameter settings in main.cf, configuration
 is not as ugly as it would be with settings in master.cf.
 
   Wietse

RE: Restricting relay of attachments

[Michael Fox]

That's helpful.  Thanks.

 -Original Message-
 From: owner-postfix-us...@postfix.org [mailto:owner-postfix-
 us...@postfix.org] On Behalf Of Viktor Dukhovni
 Sent: Wednesday, September 10, 2014 10:11 AM
 To: postfix-users@postfix.org
 Subject: Re: Restricting relay of attachments
 
 On Wed, Sep 10, 2014 at 09:55:16AM -0700, Michael Fox wrote:
 
  Hmmm.  O.K.  Thanks to both of you.  It will take me some time to think
 this
  through.
 
  The level of indirection between main.cf and master.cf sure adds
  flexibility.  But, as someone who doesn't work in postfix every day or
 even
  every week, it also leaves my head spinning.  ;-)
 
 The easiest way to understand this is that main.cf is just a lookup
 table that preempts built-in defaults and is loaded at the start
 of each Postfix daemon process.  This lookup table is in turn
 preempted by -o command-line switches.
 
 However, both on the command-line and in main.cf itself, parameters
 can be recursively defined in terms of other parameters or just
 ad-hoc made up macros.
 
 Since the master.cf file is does not support white-space in argument
 values, and is not a good place for maintaining complex parameter
 settings, the best practice approach to master.cf overrides is to
 define them indirectly in terms of sensibly named macros that
 are actually defined in main.cf.
 
   main.cf:
   some_override =
   ... too complex to specify directly in master.cf ...
 
   master.cf
   service type ... daemon-program
   -o some_parameter=$some_override
   ...
 
 Even if the override value is very simple, it may be better to use
 indirection via main.cf, so that someone reading just main.cf can
 infer that there are likely master.cf overrides and it may be wise
 to look there also.
 
 --
   Viktor.

Need help with canonical maps

[Michael Fox]

I'm having difficulty getting the canonical_maps function to work as needed
to repair some incorrect addresses from a legacy client.  Here's the
situation and what I've tried so far:

Legacy client (oldhost.legacy.org) does not append its domain (legacy.org)
to addresses in the envelope or the message when sending them via SMTP.  So,
if the user on oldhost types an address such as user@oldhost, it goes out
with SMTP as user@oldhost instead of u...@oldhost.legacy.org.

A machine with postfix (newhost.standard.org) has a different domain
(standard.org) from the legacy machine.  It acts as MX and relay for the
oldhost.legacy.org domain.  Relaying in both directions works fine.  Only
the address rewriting function which I'm trying to add is not working
properly.

When messages from the legacy client arrive at the postfix machine with
addresses such as user@oldhost (missing .legacy.org), I'd like to rewrite
those to read u...@oldhost.legacy.org.  It's my understanding that the
canonical_maps function is intended for this purpose.

In /etc/postfix/canonical.pcre I have:
/^(.*@oldhost)$/$1.legacy.org

If I test with:  postmap -q user@oldhost pcre:/etc/postfix/canonical.pcre
the answer is:  u...@oldhost.legacy.org.  Perfect.

In /etc/postfix/main.cf I have
canonical_maps = pcre:/etc/postfix/canonical.pcre

Then, on the legacy host, I send a message such as:
To:  user@someotherhost.domain
Cc:  user@oldhost

The message arrives at the postfix machine, but the CC line is not
rewritten.

The documentation for canonical_maps says that in order for the headers to
be rewritten, the client needs to either match the
local_header_rewrite_clients or else the remote_header_rewrite_domain must
be non-null.  I tried both but neither produces the output that I need.
Here's what I found:

If I set local_header_rewrite_clients = static:all or permit_mynetworks or
some other option that would cause a match of the legacy client, then the
append_dot_domain option takes over and appends the domain of the postfix
host, rewriting the address as u...@oldhost.standard.org.  The canonical
table is apparently ignored.

If I instead leave local_header_rewrite_clients at its default (which does
not match the legacy client) and turn on remote_header_rewrite_domain =
invalid.domain, then the address is rewritten as user@oldhost.invalid.domain
and, once again, the canonical table is apparently ignored.

So the documentation for the canonical table is correct, in that rewriting
only occurs if the local_header_rewrite_clients matches the client or if
remote_header_rewrite_domain is set.  And the rewrites are indeed occurring.
But the rewriting that takes place completely ignores the canonical table.
This seems like a catch-22 situation.

I don't want to turn off append_dot_domain or append_at_myorigin because I
need that for the local linux machine where postfix is running.  If the
canonical table rewrites were applied first, then the append_... functions
would not apply.  So how do I get postfix to apply the canonical table first
(or at all)?

Michael

RE: Need help with canonical maps

[Michael Fox]

Thanks much, Wietse.

A couple of follow-ups:

 As documented in ADDRESS_REWRITING_README, canonical mapping happens
 after append_dot_mydomain.

O.K.  I read that document but did not see that statement.  I just went back
and read it again and I still don't see that.  Perhaps the order of
processing can be more explicitly stated?

 Thus, either turn off append_dot_mydomain (which may also change
 the handling of other email addresses, which may break something),
 or change canonical_maps to rewrite the address that results from
 append_dot_mydomain, i.e.  u...@oldhost.standard.org

I presume there is a reason for the current processing order.  But it seems
it causes the need to rewrite a rewrite.  In other words, as you described,
I either have to turn off a feature (append_dot_mydomain) and then fix the
problem that that creates in canonical_maps, or else use canonical to
rewrite an address that has already been rewritten.  

The reverse order seems more intuitive and useful (at least to me).  If
canonical was processed first, one would have the opportunity to fix the
error as it is coming in, before it is further manipulated and, perhaps,
becomes harder to distinguish from other addresses.  Then, anything left
over could be handled by append_dot_mydomain or the
remote_header_rewrite_domain, wherever they apply.  

For backward compatibility, perhaps a switch could be provided to control
the order.  Just a thought.  

Once again, thanks for the quick reply.

Michael

RE: Need help with canonical maps

[Michael Fox]

Thanks again Wietse.

 Hmm. ADDRESS_REWRITING_README describes the address manipulations
 in the order as executed. Presenting these descriptions in a different
 order would be misleading.

Yes.  And it's very well written.  But assuming or inferring information
that is not in a technical document is usually not a wise move.  Currently,
the processing order is implied by the order mentioned in the document.  But
I didn't want to assume that.  I would respectfully suggest an explicit
statement in the document so the reader doesn't need to infer the processing
order.


 That would require not a switch, but a mechanism to specify the
 order of all five cleanup server's address manipulations.

Yes, good point.  Perhaps that's too complex to address what may be a
shrinking problem today (cleaning up legacy client addresses).

Best regards, and thanks again for the quick help!

Michael