Feedback on Tutorial

[da-postfixusers-15]

Hello Postfix users,

I made a relatively comprehensive tutorial[1] on how to set up a mail server 
(Postfix, Dovecot, Rspamd,..) and integrate it with Nextcloud. My goal was to 
create a all-in-one, step-by-step tutorial from beginning to end.

I partly used other tutorials as a basis, but also did a lot of research and 
e.g. used much stricter smtpd_*_restrictions than I have seen anywhere else.

It's a hobby project, I am not a full-time mail admin, so probably not useful 
for large companies.

I would greatly appreciate your feedback and hints on possible errors or 
oversights.

A direct link to the Postfix section: https://123qwe.com/tutorial/#postfix

Thank You

Alexey

[1] http://123qwe.com

Re: Postfix-3.3.0_1 Can't assign requested address

[James B. Byrne]

On Fri, June 15, 2018 15:40, Ralf Hildebrandt wrote:
>> 84A19B389  1256 Wed Jun 13 16:03:45  byrn...@harte-lyne.ca
>> (delivery temporarily suspended: connect to
>> inet07.hamilton.harte-lyne.ca[216.185.71.27]:25: Can't assign
>> requested address)
>
> ...
>
>> smtp_bind_address = 127.0.31.1
>
> That's why. I think.
>

Thank you. That was the problem.

Regards,

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: Postfix-3.3.0_1 Can't assign requested address

[Wietse Venema]

James B. Byrne:
> I am setting up a new mail hub in a FreeBSD-11.1 jail.  When routing
> traffic through this host to our existing IMAP service I see this
> error in the maillog file:
> 
> 84A19B389  1256 Wed Jun 13 16:03:45  byrn...@harte-lyne.ca
> (delivery temporarily suspended: connect to
> inet07.hamilton.harte-lyne.ca[216.185.71.27]:25: Can't assign
> requested address)

Fix your inet_interfaces or smtp_bind_address settings.

Wietse

Re: Postfix-3.3.0_1 Can't assign requested address

[Ralf Hildebrandt]

> 84A19B389  1256 Wed Jun 13 16:03:45  byrn...@harte-lyne.ca
> (delivery temporarily suspended: connect to
> inet07.hamilton.harte-lyne.ca[216.185.71.27]:25: Can't assign
> requested address)

...

> smtp_bind_address = 127.0.31.1

That's why. I think. 

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Postfix-3.3.0_1 Can't assign requested address

[James B. Byrne]

I am setting up a new mail hub in a FreeBSD-11.1 jail.  When routing
traffic through this host to our existing IMAP service I see this
error in the maillog file:

84A19B389  1256 Wed Jun 13 16:03:45  byrn...@harte-lyne.ca
(delivery temporarily suspended: connect to
inet07.hamilton.harte-lyne.ca[216.185.71.27]:25: Can't assign
requested address)
 byrn...@harte-lyne.ca

But, if I telnet from the same host then I see this:

# telnet 216.185.71.27 25
Trying 216.185.71.27...
Connected to inet07.hamilton.harte-lyne.ca.
Escape character is '^]'.
220 inet07.hamilton.harte-lyne.ca ESMTP Postfix
ehlo mx31.harte-lyne.ca
250-inet07.hamilton.harte-lyne.ca
250-PIPELINING
250-SIZE 2048
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
quit
221 2.0.0 Bye
Connection closed by foreign host.

Likewise swaks run on the same host connects and delivers:

# swaks --from=byrn...@harte-lyne.ca --to=byrn...@harte-lyne.ca
--server=216.185.71.27
=== Trying 216.185.71.27:25...
=== Connected to 216.185.71.27.
<-  220 inet07.hamilton.harte-lyne.ca ESMTP Postfix
 -> EHLO mx31.harte-lyne.ca
<-  250-inet07.hamilton.harte-lyne.ca
<-  250-PIPELINING
<-  250-SIZE 2048
<-  250-ETRN
<-  250-STARTTLS
<-  250-ENHANCEDSTATUSCODES
<-  250-8BITMIME
<-  250 DSN
 -> MAIL FROM:
<-  250 2.1.0 Ok
 -> RCPT TO:
<-  250 2.1.5 Ok
 -> DATA
<-  354 End data with .
 -> Date: Fri, 15 Jun 2018 14:29:04 -0400
 -> To: byrn...@harte-lyne.ca
 -> From: byrn...@harte-lyne.ca
 -> Subject: test Fri, 15 Jun 2018 14:29:04 -0400
 -> Message-Id: <20180615142904.092...@mx31.harte-lyne.ca>
 -> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
 ->
 -> This is a test mailing
 ->
 -> .
<-  250 2.0.0 Ok: queued as D22B48A345
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.

Our set-up requires authenticated senders and this is accomplished by
using saslauthd configured to connect to a remote IMAP service.
However, we do this over an encrypted pipe to the IMAP server.
Saslauthd is therefore configured thus:

root 55176  0.0  0.0  43928  0  -  IWsJ -   0:00.00
/usr/local/sbin/saslauthd -a rimap -O localhost

# ping localhost
PING localhost (127.0.31.1): 56 data bytes

We also use dkim and this is running as well:

mailnull 69811  0.0  0.0  33952  0  -  IWsJ -   0:00.00
/usr/local/sbin/opendkim -l -u mailnull:mailnull -P /var/run/milter
mailnull 70080  0.0  0.1  52004   3388  -  SJ   Thu10   0:03.22
/usr/local/sbin/opendkim -l -u mailnull:mailnull -P /var/run/milter


Likewise we use amavisd-new:

vscan60254  0.0  0.1 250264   4440  -  SsJ  Thu10   0:02.62
/usr/local/sbin/amavisd (master) (perl)

I have searched for an answer to this but have not found anything that
I find useful.  Can anyone give me a clue as to what I have
misconfigured and where?


The sockets using port 25 on mx31.harte-lyne.ca are:

# sockstat -l | grep 25
root master 304   105 tcp4  127.0.31.1:10025  *:*
root master 304   108 tcp4  127.0.31.1:25 *:*
root master 304   109 tcp4  216.185.71.31:25  *:*
root master 304   110 tcp4  192.168.216.31:25 *:*


My main.cf settings are reproduced below:

# postconf -nf
alias_database = hash:/usr/local/etc/postfix/aliases.main,
hash:/usr/local/etc/postfix/aliases.domains,
hash:/usr/local/etc/postfix/private/aliases.byrnejb
alias_maps = hash:/usr/local/etc/postfix/aliases.main,
hash:/usr/local/etc/postfix/aliases.domains,
hash:/usr/local/etc/postfix/private/aliases.byrnejb
broken_sasl_auth_clients = yes
command_directory = /usr/local/sbin
compatibility_level = 2
content_filter = smtp-amavis:[127.0.31.1]:10024
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
$daemon_directory/$process_name $process_id & sleep 5
delay_warning_time = 15m
disable_vrfy_command = yes
header_checks = regexp:$config_directory/header_checks.regexp
html_directory = /usr/local/share/doc/postfix
ignore_mx_lookup_error = no
inet_interfaces = 127.0.31.1, 192.168.216.31, 216.185.71.31
inet_protocols = all
local_transport = smtp
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 2048
meta_directory = /usr/local/libexec/postfix
milter_default_action = accept
milter_protocol = 2
mydestination =
mydomain = harte-lyne.ca
myhostname = mx31.harte-lyne.ca
mynetworks = 216.185.71.0/26, 216.185.71.64/27, 209.47.176.0/26,
192.168.216.0/24, 192.168.209.0/24, 192.168.8.0/24,
192.168.7.0/24,
192.168.6.0/24, 127.0.0.0/8
mynetworks_style = subnet
newaliases_path = /usr/local/bin/newaliases
non_smtpd_milters = $smtpd_milters
policyd-spf_time_limit = 3600
postscreen_access_list = permit_mynetworks,
cidr:/usr/local/etc/postfix/postscreen_access.cidr
postscreen_dnsbl_sites = zen.spamhaus.org*2 bl.spamcop.net*1
dun.dnsrbl.net*1
escalations.dnsbl.sorbs.net*1

Re: Update to recommended TLS settings

[Viktor Dukhovni]

> On Jun 15, 2018, at 8:28 AM, micah anderson  wrote:
> 
> In 2015, Viktor wrote an email detailing the current recommended TLS
> settings[0].
> 
> Now that we are three years later, are these still the best settings? Is
> there something better we can be recommending?
> 
> If anything, I think that 'smtp_tls_security_level = may' should be
> recommended (it actually should be *default*), but I'm wondering about
> the other recommended ciphers/protocols/excludes etc. as well.

There's nothing in that post that has yet been subject to much bitrot.
You could probably disable RC4 at this point, it is by default gone
as an SSL cipher from OpenSSL 1.1.0 and later, or leave it on for
interoperability with an tiny fraction of obsolete Windows 2003
systems.

I hope to modernize the OpenSSL supporting code this year, perhaps
I'll have new recommendations for Postfix 3.4 in 2019.  The idea
will be to accommodate TLS 1.3, Ed25519, support SNI on the server
side, and on the client side also when not using DANE, ...

-- 
Viktor.

Update to recommended TLS settings

[micah anderson]

In 2015, Viktor wrote an email detailing the current recommended TLS
settings[0].

Now that we are three years later, are these still the best settings? Is
there something better we can be recommending?

If anything, I think that 'smtp_tls_security_level = may' should be
recommended (it actually should be *default*), but I'm wondering about
the other recommended ciphers/protocols/excludes etc. as well.

thanks!

-- 
micah

0. 
http://postfix.1071664.n5.nabble.com/Update-to-recommended-TLS-settings-td78583.html

Re: masquerade_domains map?

[Marco]

On 15/06/2018 12:58 CEST, Wietse Venema wrote:
[...]

And here is an example from several other Postfix features:

 Specify a list of [things], "/file/name" or "type:table" patterns,
 separated by commas and/or whitespace. The list is matched left to
 right, and the search stops on the first match. A "/file/name" pattern
 is replaced by its contents; a "type:table" lookup table is matched
 when a name matches a lookup key (the lookup result is ignored). Con-
 tinue long lines by starting the next line with whitespace. Specify
 "!pattern" to exclude a name from the list.

Would that work for you?


Yes, of course.
Many thanks for considering this.

  Marco

Re: masquerade_domains map?

[Wietse Venema]

Marco:
> Hello Postfix users,
> 
>   while "masquerade_exceptions" supports "type:table" patterns, 
> "masquerade_domains" supports only a static list of domain names in main.cf.
> 
> http://www.postfix.org/ADDRESS_REWRITING_README.html#masquerade
> 
> 
> For me, it could be useful to manage also these domains in a file, 
> mysql, tcp or ldap... It should be nice if a future release of Postfix 
> could support "type:table" on "masquerade_domains".

This is an example from the postconf(5) manpage:

masquerade_domains = !foo.example.com example.com

And here is an example from several other Postfix features:

Specify a list of [things], "/file/name" or "type:table" patterns,
separated by commas and/or whitespace. The list is matched left to
right, and the search stops on the first match. A "/file/name" pattern
is replaced by its contents; a "type:table" lookup table is matched
when a name matches a lookup key (the lookup result is ignored). Con-
tinue long lines by starting the next line with whitespace. Specify
"!pattern" to exclude a name from the list.

Would that work for you?

Wietse

masquerade_domains map?

[Marco]

Hello Postfix users,

 while "masquerade_exceptions" supports "type:table" patterns, 
"masquerade_domains" supports only a static list of domain names in main.cf.


http://www.postfix.org/ADDRESS_REWRITING_README.html#masquerade


For me, it could be useful to manage also these domains in a file, 
mysql, tcp or ldap... It should be nice if a future release of Postfix 
could support "type:table" on "masquerade_domains".


Thank you very much
Marco

Re: spamming mailbox ?

[Tom Hendrikx]

On 14-06-18 15:27, Poliman - Serwis wrote:
> I check the mail queue and the logs and this time I found some strange
> thing. I used command "grep -r "emailemailemail.com
> " /var/log/mail.log" and result is in
> attached .txt file. If I understand properly there is many tries to send
> from do_not_re...@s1.poliman.net  to
> emailemailemailemailemailem...@emailemailemail.com
>  but nothing
> happens later because of failing connection to emailemailemail.com
>  on port 25.
> 

Yes, that are many attempts to deliver the same email. Because the
receiving server does not exist, the message is kept in the queue and
retried later.

This is easily visible because all log messages show the same queue id
(9438613CE9E). This will continue until maximal_queue_lifetime (default
5d) is reached.

Kind regards,
Tom