Re: dnsblog filtering?

[Patrick Proniewski]

Hi,

> On 10 juin 2020, at 05:22, PGNet Dev  wrote:
> 
> On 6/9/20 8:15 PM, Noel Jones wrote:
>> Postfix assumes the logs are private.
> 
> They generally are.  The very-recent switch to BLs with Acct-ID's is new, and 
> complicated that a bit.
> 
>> To sanitize the log, you'll need to use an external process
> 
> ok.  easy enough -- just an additional bit of kit.


depending on your log aggregation solution it might be quite easy. Splunk will 
allow this kind of sanitization with a transform stanza on the indexer (you 
must do it at indexing time, not search time). IIRC Logstash will allow that 
also.
Otherwise rsyslogd (if you use linux) allows some filters/actions before 
sending logs to the aggregator, but I'm not too sure about this one.

patpro

Re: Postfix restrictions

[yuv]

On Tue, 2020-06-09 at 01:16 -0600, @lbutlr wrote:
> > On 08 Jun 2020, at 16:21, yuv  wrote:
> > 
> > Some of [the alternatives to internet email] will achieve scale as
> > well.  At some point, the cost/benefit analysis of maintaining
> > internet email vs. using alternatives such as SMS will tilt
> > obviously against email
> 
> Sure it will. It hasn't happened yet, and I don't think it will
> happen (SMS is garbage), but it is still irrelevant to the topic.

It may be irrelevant to the topic, but your statement characterizes the
troll perfectly well.

The admins working for the fine companies on the list at the URL below
may be of a different opinion on relevance and on occurence of the
cost/benefit tipping point.

https://en.wikipedia.org/wiki/List_of_mobile_network_operators

Some of them may even opine that your internet email is garbage.

I am personally agnostic regarding garbage...


> > and that's where "most admins" will regret their narrow view. 
> 
> How do you figure? You think we run Mailservers because we are
> emotionally invested in the idea of email as the ONE TRUE INFORMATION
> EXCHANGE? Nope. We are mail admins because we and our users need
> email. As soon as that is no longer the case I will gleefully switch
> to the better thing.

... but I have zero tolerance for the arrogant attribution of your
preconceived notions.

My thoughts are far from your wishful dreaming.  All things being
equal, internet email is less interesting when it is less reliable and
more spammy, both of which are direct consequences of your myopia.  I
care little whether my communication is carried by pigeons, by fax, or
by internet email.  The question is not "do you want to receive that
email?"  The question is "do you want your message delivered reliably
according to protocol" and if email does not cut it, there are
competing protocols that do.

Here is one for you:
https://siarchives.si.edu/history/featured-topics/postcard/postcard-history

By the time "your" users will no longer need you, you may find that the
competitive landscape has shifted under your feet.  And they may
gleefully leave you and your baggage behind.  Abandonware.
 
--
Yuval Levy, JD, MBA, CFA
Ontario-licensed lawyer

Re[2]: The historical roots of our computer terms

[Peter Evans]

I have zero interest in making your documentation "politically correct"
that is an agenda of evil wrapped in a delusion of not offending  and this discussion could not possibly end soon enough.


On 2020-06-08 17:43:19, stse+post...@rootsland.net wrote:


On Mo, Jun 08, 2020 at 07:52:34 +0200, Claus R. Wickinghoff wrote:

What about redlist (stop) and greenlist (go)? Traffic lights are pretty
international

They aren’t. As far as I know you have a blue light for go in Japan.

Sorry to ruin your delusion but this is a fallacy.
Now, we _do_ have stuff like "shingo ha ao ni narimashita" but
that traffic light is categorically green.

Under some circumstances, "ao" means "blue" under others it means 
"green."

Please try not to worry about it.

For a real delusion, we think we are the only country with 4 seasons.

PATCH: Handle TLS 1.3 Hello retry requests (was: SNI problem)

[Viktor Dukhovni]

> On Jun 9, 2020, at 7:22 PM, Viktor Dukhovni  
> wrote:
> 
> This predates support for automatic negotiated EC curve selection
> in OpenSSL, and is now just a bad idea.  The default "auto" setting
> is the only correct one to use.  That said, how this breaks loading
> of RSA certificate chains is rather a deep mystery I shall pursue
> with the OpenSSL team.

Turns out the problem is that my SNI code in Postfix did not expect
to be called twice for the same connection as happens with TLS 1.3
HRR (hello retry requests) when the client's key share guess does
not match the server's supported signature algorithms (e.g. only P384
with "smtpd_tls_eecdh_grade = ultra").

Git commit at:

  
https://github.com/vdukhovni/postfix/commit/851b525c5c09405c48b8cd697d14cb0d2edbb68b

Raw patch:

  
https://github.com/vdukhovni/postfix/commit/851b525c5c09405c48b8cd697d14cb0d2edbb68b.patch

This applies to Postfix 3.4, 3.5 and 3.6 snapshots.

-- 
Viktor.

Re: dnsblog filtering?

[PGNet Dev]

On 6/9/20 8:15 PM, Noel Jones wrote:
> Postfix assumes the logs are private.

They generally are.  The very-recent switch to BLs with Acct-ID's is new, and 
complicated that a bit.

> To sanitize the log, you'll need to use an external process

ok.  easy enough -- just an additional bit of kit.

> or patch the source.

unwise, at best.

> Postfix has default_rbl_reply and rbl_reply_maps to sanitize what is sent to 
> the offending client, but does not modify what's logged. Hopefully you're 
> using this already...

Yep, all sorted with some quick regex help from list.

Re: dnsblog filtering?

[Noel Jones]

On 6/9/2020 8:46 PM, PGNet Dev wrote:

does dnsblog have a log map/filter/somesuch?

or does the capability exist elsewhere in postfix?

currently, with spamhaus dqs in the rbl/dnsbl mix, dnsblog spits out, e.g.

/var/log/postfix/postfix.log:Jun  9 13:27:56 ms postfix/dnsblog[5378]: addr 
72.43.215.122 listed by domain .zen.dq.spamhaus.net as 127.0.0.4

i send logs to a central log server, & simply want to anonymize -- i.e., 
remove/obfuscate the  -- from the logs.

it can be done externally to postfix; within postfix config (map?), would be 
nice.





Postfix assumes the logs are private. To sanitize the log, you'll 
need to use an external process or patch the source.


Postfix has default_rbl_reply and rbl_reply_maps to sanitize what is 
sent to the offending client, but does not modify what's logged. 
Hopefully you're using this already...



  -- Noel Jones

dnsblog filtering?

[PGNet Dev]

does dnsblog have a log map/filter/somesuch?

or does the capability exist elsewhere in postfix?

currently, with spamhaus dqs in the rbl/dnsbl mix, dnsblog spits out, e.g.

/var/log/postfix/postfix.log:Jun  9 13:27:56 ms postfix/dnsblog[5378]: 
addr 72.43.215.122 listed by domain .zen.dq.spamhaus.net as 127.0.0.4

i send logs to a central log server, & simply want to anonymize -- i.e., 
remove/obfuscate the  -- from the logs.

it can be done externally to postfix; within postfix config (map?), would be 
nice.

Re: SNI problem

[Ján Máté]

Hi Victor,

many thanks for finding out the cause of the problem - I hope the information 
about smtpd_tls_eecdh_grade will be useful for other Postfix users!


JM


> On 10 Jun 2020, at 01:22, Viktor Dukhovni  wrote:
> 
> 
> 
>> On Jun 9, 2020, at 1:07 PM, Viktor Dukhovni  
>> wrote:
>> 
>>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in 
>>> SNI data for smtp.myserver.eu does not match next certificate
>>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library 
>>> problem: error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
>>> certificate:../ssl/ssl_rsa.c:1107:
>> 
>> The second message is the real problem, OpenSSL believes it already has
>> a certificate loaded for that algorithm, which should not be the case.
>> The new key then does not match the already installed certificate.  But
>> there shouldn't be one already loaded.
> 
> Amazingly enough the issue seems to be caused by an obsolete, and
> seemingly unrelated setting in the OP's main.cf file:
> 
>   smtpd_tls_eecdh_grade = ultra
> 
> This predates support for automatic negotiated EC curve selection
> in OpenSSL, and is now just a bad idea.  The default "auto" setting
> is the only correct one to use.  That said, how this breaks loading
> of RSA certificate chains is rather a deep mystery I shall pursue
> with the OpenSSL team.
> 
> The OP also has other excessive fine-tuning of the TLS stack that
> is somewhat counter-productive.
> 
>  * 4096 bit RSA cert
>  * TLS 1.0 disabled
>  * Overly specific cipherlist
>  * ...
> 
> For SMTP, try to have modest, but broadly interoperable expectations
> of security that raise the ceiling rather than the floor.
> 
>   https://tools.ietf.org/rfc7435
> 
> -- 
>   Viktor.
> 

Re: SNI problem

[Viktor Dukhovni]

> On Jun 9, 2020, at 1:07 PM, Viktor Dukhovni  
> wrote:
> 
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in 
>> SNI data for smtp.myserver.eu does not match next certificate
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library problem: 
>> error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
>> certificate:../ssl/ssl_rsa.c:1107:
> 
> The second message is the real problem, OpenSSL believes it already has
> a certificate loaded for that algorithm, which should not be the case.
> The new key then does not match the already installed certificate.  But
> there shouldn't be one already loaded.

Amazingly enough the issue seems to be caused by an obsolete, and
seemingly unrelated setting in the OP's main.cf file:

smtpd_tls_eecdh_grade = ultra

This predates support for automatic negotiated EC curve selection
in OpenSSL, and is now just a bad idea.  The default "auto" setting
is the only correct one to use.  That said, how this breaks loading
of RSA certificate chains is rather a deep mystery I shall pursue
with the OpenSSL team.

The OP also has other excessive fine-tuning of the TLS stack that
is somewhat counter-productive.

  * 4096 bit RSA cert
  * TLS 1.0 disabled
  * Overly specific cipherlist
  * ...

For SMTP, try to have modest, but broadly interoperable expectations
of security that raise the ceiling rather than the floor.

https://tools.ietf.org/rfc7435

-- 
Viktor.

Re: combining ldap and smtp-lookahead for recipient validation

[Wietse Venema]

Jonathan Engbrecht:
> Thank you!
> 
> The only thing that's a little odd is that the embedded-space construct:
> static:{reject 5.1.1 user unknown} doesn't seem to work in this context.  I
> get:
> 
> ... postfix/smtpd[31453]: generic_checks: name={reject
> ... postfix/smtpd[31453]: warning: unknown smtpd restriction: "{reject"
> 
> Changing this to static:reject works well enough for my purposes here, so
> that's excellent.  Thanks again.

Postfix versions before 3.2 are no longer supported.

$ postmap -q test 'static:{reject 5.1.1 user unknown}'
reject 5.1.1 user unknown

As you see, no '{reject' in the result.

Wietse

Re: Questions about the master.cf file

[Doug Hardie]

Having recently gone through this same confusion, perhaps some of what I 
figured out might help.  The first column of the master.cf file is the port 
number for each of the ports that postfix will listen to, or the name of an 
internal postfix process.  In the distributed file, the names from the 
/etc/services file are used rather than the port numbers.  For example, smtp is 
port 25.  However, looking down you will see one line for port 628 (commented 
out though).

The last argument on each line tells postfix which process to send the request 
to.  Thats why postscreen replaces the smtp line with the postscreen process.  
Postscreen is smart - it injects messages into the system by sending them to 
smtpd.  There is an entry for smtpd (the postfix process) that lets you add 
restrictions for smptd.

Here is a portion of my master.cf:

smtpd  pass  -   -   n   -   50   smtpd
  -o smtpd_recipient_restrictions=$incoming_smtpd_restrictions
smtp   inet  n   -   n   -   1   postscreen
dnsblogunix  -   -   n   -   0   dnsblog
tlsproxy   unix  -   -   n   -   0   tlsproxy
submission inet n   -   n   -   10   smtpd
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o syslog_name=postfix-submission
dovecotunix -   n   n   -   -   pipe
  flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f 
${sender} -d ${recipient}

I use macros defined in main.cf for the restrictions on port 25 (smtp after 
postscreen) and port 587 (submission).  dnsblog and tlsproxy are internal 
postscript processes.  dovecot is a local delivery via dovecot.

It's a bit difficult at first to see the forrest through the trees as the 
documentation is detailed and complete.  However, once you discover the 
forrest, then the documentation will be quite helpful.


-- Doug

> On 9 June 2020, at 14:26, Scott A. Wozny  wrote:
> 
> In the context of looking at implementing Postscreen, I’ve read through the 
> postscreen readme, the master.cf man page, and postfix architectural overview 
> docs, but I have some remaining service related questions I might appeal to 
> one of the gurus on the list to help me with.
> 
> In a default master.cf file’s first non-comment line, the smtp service uses 
> the smtpd command. I’m not clear why the smtp (client) service would use the 
> smtpd (server) binary. Is there an old convention that drives the naming to 
> be apparently contradictory or am I missing something in my interpretation?
> 
> In the postscreen instructions, one of the first steps is to comment out the 
> smtp service line above and uncomment the one that uses the postscreen 
> command instead. I get why, since postscreen is supposed to “screen” out bad 
> clients before letting them talk to smtpd later. Is there anything in this 
> configuration file that indicates this or is the handoff to smtpd built into 
> postscreen itself?
> 
> Why is there an smtpd service that gets enabled during a postscreen 
> implementation when there wasn’t one before? More specifically, without an 
> smtpd service before, what service was serving smtpd for new smtp 
> connections? The “smtp” service (that seems to actually be smtpd) listed 
> first in the file?
> 
> In the smtpd service I just mentioned, this type is pass and not unix. When I 
> looked up the 2 service types in the documentation, they both say, “The 
> service listens on a UNIX-domain stream socket, and is accessible to local 
> clients only.” but the pass type goes on to say, “It receives one open 
> connection (file descriptor passing) per connection request.” I’ve done some 
> further googling, but I can’t figure out what this means in terms of 
> practical use. Can someone explain the practical difference between a unix 
> type service and a pass type service?
> 
> Finally, there is ANOTHER service named smtp further down the file between 
> proxywrite and relay that ACTUALLY uses smtp as the command but is of type 
> unix (which, for a client, makes sense). What is the purpose of this instance 
> of service named smtp (like, is it the “real” smtp service used for packaging 
> and sending smtp messages?) and how is it that it does not “conflict” with 
> the instance of smtp service discussed above? Under what conditions am I 
> allowed to create services that have names which conflict? Only when the 
> types are different (and then, only with certain “different type” 
> combinations)? Or is there a first use rule on services which means that the 
> smtp service above is the only one that get used?
> 
> I’m sorry if I’m being obtuse, but some elements of this file are a real 
> head-scratcher for me. If this is covered somewhere outside of 
> http://www.postfix.org/master.5.htmlhttp://www.postfix.org/OVERVIEW.html 
> orhttp://www.postfix.org/POSTSCREEN_README.html or is discussed in more 
> detail elsewhere on 

Re: Questions about the master.cf file

[Noel Jones]

On 6/9/2020 4:26 PM, Scott A. Wozny wrote:
In the context of looking at implementing Postscreen, I’ve read 
through the postscreen readme, the master.cf man page, and postfix 
architectural overview docs, but I have some remaining service 
related questions I might appeal to one of the gurus on the list to 
help me with.



In a default master.cf file’s first non-comment line, the smtp 
service uses the smtpd command. I’m not clear why the smtp (client) 
service would use the smtpd (server) binary. Is there an old 
convention that drives the naming to be apparently contradictory or 
am I missing something in my interpretation?


This is an inet type service, so the first column refers to an 
ip:port to listen on, or a service name from /etc/services.


Unix type are transports, the first column is a name for selecting 
that transport.





In the postscreen instructions, one of the first steps is to comment 
out the smtp service line above and uncomment the one that uses the 
postscreen command instead. I get why, since postscreen is supposed 
to “screen” out bad clients before letting them talk to smtpd later. 
Is there anything in this configuration file that indicates this or 
is the handoff to smtpd built into postscreen itself?



Why is there an smtpd service that gets enabled during a postscreen 
implementation when there wasn’t one before? More specifically, 
without an smtpd service before, what service was serving smtpd for 
new smtp connections? The “smtp” service (that seems to actually be 
smtpd) listed first in the file?


The inet smtpd is replaces with a pass smtpd.

The unix type smtp outgoing is not involved.





In the smtpd service I just mentioned, this type is pass and not 
unix. When I looked up the 2 service types in the documentation, 
they both say, “The service listens on a UNIX-domain stream socket, 
and is accessible to local clients only.” but the pass type goes on 
to say, “It receives one open connection (file descriptor passing) 
per connection request.” I’ve done some further googling, but I 
can’t figure out what this means in terms of practical use. Can 
someone explain the practical difference between a unix type service 
and a pass type service?



Postscreen hands off the connection to the smtpd process using the 
pass type.






Finally, there is ANOTHER service named smtp further down the file 
between proxywrite and relay that ACTUALLY uses smtp as the command 
but is of type unix (which, for a client, makes sense). What is the 
purpose of this instance of service named smtp (like, is it the 
“real” smtp service used for packaging and sending smtp messages?) 
and how is it that it does not “conflict” with the instance of smtp 
service discussed above? Under what conditions am I allowed to 
create services that have names which conflict? Only when the types 
are different (and then, only with certain “different type” 
combinations)? Or is there a first use rule on services which means 
that the smtp service above is the only one that get used?


The smtp transport is a unix type service and is responsible for 
sending out mail.




  -- Noel Jones

Questions about the master.cf file

[Scott A. Wozny]

In the context of looking at implementing Postscreen, I’ve read through the 
postscreen readme, the master.cf man page, and postfix architectural overview 
docs, but I have some remaining service related questions I might appeal to one 
of the gurus on the list to help me with.


In a default master.cf file’s first non-comment line, the smtp service uses the 
smtpd command. I’m not clear why the smtp (client) service would use the smtpd 
(server) binary. Is there an old convention that drives the naming to be 
apparently contradictory or am I missing something in my interpretation?


In the postscreen instructions, one of the first steps is to comment out the 
smtp service line above and uncomment the one that uses the postscreen command 
instead. I get why, since postscreen is supposed to “screen” out bad clients 
before letting them talk to smtpd later. Is there anything in this 
configuration file that indicates this or is the handoff to smtpd built into 
postscreen itself?


Why is there an smtpd service that gets enabled during a postscreen 
implementation when there wasn’t one before? More specifically, without an 
smtpd service before, what service was serving smtpd for new smtp connections? 
The “smtp” service (that seems to actually be smtpd) listed first in the file?


In the smtpd service I just mentioned, this type is pass and not unix. When I 
looked up the 2 service types in the documentation, they both say, “The service 
listens on a UNIX-domain stream socket, and is accessible to local clients 
only.” but the pass type goes on to say, “It receives one open connection (file 
descriptor passing) per connection request.” I’ve done some further googling, 
but I can’t figure out what this means in terms of practical use. Can someone 
explain the practical difference between a unix type service and a pass type 
service?


Finally, there is ANOTHER service named smtp further down the file between 
proxywrite and relay that ACTUALLY uses smtp as the command but is of type unix 
(which, for a client, makes sense). What is the purpose of this instance of 
service named smtp (like, is it the “real” smtp service used for packaging and 
sending smtp messages?) and how is it that it does not “conflict” with the 
instance of smtp service discussed above? Under what conditions am I allowed to 
create services that have names which conflict? Only when the types are 
different (and then, only with certain “different type” combinations)? Or is 
there a first use rule on services which means that the smtp service above is 
the only one that get used?


I’m sorry if I’m being obtuse, but some elements of this file are a real 
head-scratcher for me. If this is covered somewhere outside of 
http://www.postfix.org/master.5.htmlhttp://www.postfix.org/OVERVIEW.html or 
http://www.postfix.org/POSTSCREEN_README.html or is discussed in more detail 
elsewhere on the Internet, please let me know and I’ll keep reading, but I’ve 
really tried to figure this out on my own to no success.


Any assistance would be appreciated.


Thanks,


Scott


P.S. Knowing that the default files drift from version to version and distro to 
distro, here is my default master.cf file. I put it down here since those who 
know the file best probably already know what it says. :) It came from a 
Centos7 minimal install.




# Postfix master process configuration file.  For details on the format
# of the file, see the master(5) manual page (command: "man 5 master").
#
# Do not forget to execute "postfix reload" after editing this file.
#
# ==
# service type  private unpriv  chroot  wakeup  maxproc command + args
#   (yes)   (yes)   (yes)   (never) (100)
# ==
smtp  inet  n   -   n   -   -   smtpd
#smtp  inet  n   -   n   -   1   postscreen
#smtpd pass  -   -   n   -   -   smtpd
#dnsblog   unix  -   -   n   -   0   dnsblog
#tlsproxy  unix  -   -   n   -   0   tlsproxy
#submission inet n   -   n   -   -   smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
#smtps inet  n   -   n   -   -   smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o 

Re: SNI problem

[Ján Máté]

Ups,

the correct

openssl s_client -servername smtp.example.com -starttls smtp -connect 
smtp.example.com:25 

output:


CONNECTED(0003)
140192932344960:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert 
internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 326 bytes and written 726 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---


JM


> On 9 Jun 2020, at 22:36, Ján Máté  wrote:
> 
> Hi Victor,
> 
> yes, I looked at /etc/ssl/openssl.cnf and found nothing related to default or 
> preloaded chain.
> 
> See the result of the debug from strace - only 3 cert related files are 
> opened = the private key, full chain and DH param:
> 
> openat(AT_FDCWD, "pid/inet.smtp", O_RDWR) = 9
> openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 12
> openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 13
> openat(AT_FDCWD, "/etc/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or 
> directory)
> openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 13
> openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 14
> openat(AT_FDCWD, "/usr/lib/postfix/postfix-ldap.so", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/usr/lib/postfix/libldap_r-2.4.so.2", O_RDONLY|O_CLOEXEC) = 
> -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libldap_r-2.4.so.2", 
> O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/usr/lib/postfix/liblber-2.4.so.2", O_RDONLY|O_CLOEXEC) = 
> -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/liblber-2.4.so.2", 
> O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgnutls.so.30", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libp11-kit.so.0", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 
> 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libunistring.so.2", 
> O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 
> 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnettle.so.6", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libhogweed.so.4", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgmp.so.10", O_RDONLY|O_CLOEXEC) = 
> 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libffi.so.6", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2", 
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgssapi_krb5.so.2", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 
> 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libk5crypto.so.3", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcom_err.so.2", O_RDONLY|O_CLOEXEC) 
> = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5support.so.0", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkeyutils.so.1", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libscram.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgs2.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/etc/gss/mech.d", 
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/liblogin.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 
> 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libplain.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/etc/ldap/ldap.conf", O_RDONLY) = 12
> openat(AT_FDCWD, "ldaprc", O_RDONLY)= -1 ENOENT (No such file or 
> directory)
> openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_alias_maps", O_RDONLY) = 12
> openat(AT_FDCWD, 

Re: SNI problem

[Ján Máté]

Hi Victor,

yes, I looked at /etc/ssl/openssl.cnf and found nothing related to default or 
preloaded chain.

See the result of the debug from strace - only 3 cert related files are opened 
= the private key, full chain and DH param:

openat(AT_FDCWD, "pid/inet.smtp", O_RDWR) = 9
openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 12
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 13
openat(AT_FDCWD, "/etc/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 13
openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 14
openat(AT_FDCWD, "/usr/lib/postfix/postfix-ldap.so", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/postfix/libldap_r-2.4.so.2", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libldap_r-2.4.so.2", 
O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/postfix/liblber-2.4.so.2", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/liblber-2.4.so.2", O_RDONLY|O_CLOEXEC) 
= 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgnutls.so.30", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libp11-kit.so.0", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libunistring.so.2", O_RDONLY|O_CLOEXEC) 
= 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnettle.so.6", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libhogweed.so.4", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgmp.so.10", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libffi.so.6", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgssapi_krb5.so.2", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libk5crypto.so.3", O_RDONLY|O_CLOEXEC) 
= 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcom_err.so.2", O_RDONLY|O_CLOEXEC) = 
15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5support.so.0", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) 
= 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libscram.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgs2.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/gss/mech.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) 
= 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/liblogin.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libplain.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/ldap/ldap.conf", O_RDONLY) = 12
openat(AT_FDCWD, "ldaprc", O_RDONLY)= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_alias_maps", O_RDONLY) = 12
openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_alias_maps-alternate", 
O_RDONLY) = 12
openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_mailbox_maps", O_RDONLY) = 12
openat(AT_FDCWD, "/usr/lib/postfix/postfix-pcre.so", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/postfix/libpcre.so.3", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/postfix/tables/pcre-check_helo_access", O_RDONLY) = 12
openat(AT_FDCWD, "/etc/postfix/sasl/smtpd.conf", O_RDONLY) = 12
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 15
openat(AT_FDCWD, "/etc/postfix/tables/hash-tls_server_sni_maps.db", O_RDONLY) = 
12
openat(AT_FDCWD, 

Re: combining ldap and smtp-lookahead for recipient validation

[Jonathan Engbrecht]

Thank you!

The only thing that's a little odd is that the embedded-space construct:
static:{reject 5.1.1 user unknown} doesn't seem to work in this context.  I
get:

... postfix/smtpd[31453]: generic_checks: name={reject
... postfix/smtpd[31453]: warning: unknown smtpd restriction: "{reject"

Changing this to static:reject works well enough for my purposes here, so
that's excellent.  Thanks again.



On Thu, 4 Jun 2020 at 14:36, Wietse Venema  wrote:

> Jonathan Engbrecht:
> > I route mail for a number of relay_domains - recipient addresses are
> > validated using verify via address_verify_transport
> >
> > For *one* of these domains, I'd like to validate addresses using an ldap
> > map configured with relay_recipient_maps rather than smtp lookahead.
> >
> > I have the ldap connection working based on postmap -q ..., but I'm not
> > sure how to configure to make some domains work using the lookahead, and
> > one to work using relay_recipient_maps.
>
> This should be easier, but 1) relay_recipient_maps is global, so you
> have to leave that 'empty' and use check_recipient_access instead
> (*); and 2) restriction_classes is needed for a nested table lookup.
>
> Untested example!
>
> restriction_classes = verify_with_lookup
> verify_with_lookup =
> check_recipient_access ldap:/some/file static:{reject 5.1.1 user
> unknown}
> # Where the LDAP returns 'permit' or 'ok' for a user that exists.
>
> smtpd_recipient_restrictions =
> ...
> reject_unauth_destination
> ...
> # Needs to go last, because verify_with_lookup returns permit or
> reject.
> check_recipient_access pcre:/etc/postfix/rcpt_access
>
> /etc/postfix/rcpt_access:
>/@example\.com$/ verify_with_lookup
>/./ reject_unverified_recipient
>
> More at http://www.postfix.org/RESTRICTION_CLASS_README.html
>
> (*) relay_recipient_maps can be changed to be not global,
> but doing that would complicate other things.
>
> Wietse
>

Re: SNI problem

[Viktor Dukhovni]

On Tue, Jun 09, 2020 at 08:31:27PM +0200, Ján Máté wrote:

> Thanks for the explanation what's happening in the internals of
> Postfix, but the problem is still a mystery for me ...
> 
> I use the default Debian (Buster) /etc/ssl/openssl.cnf without any
> modifications, so I don't think that there is any default certificate
> chain that might be preloaded into each new SSL_CTX.

Have you looked at that file?  Any mention of any default certificate
chain files there?

> It looks like SNI works for you, but I cannot get it working - and
> tried really hard for more than a week (I read everything I found on
> Google and it looks like there are few people with working setup, and
> the remaining say that it does not work) :-/
> 
> Any idea how to debug it myself? ... or even better - I can allow you
> root access to the test server to check it yourself (just send me a
> private e-mail with your ssh public key).

Can you strace the SMTP server process?  Add a "-D" flag to the
smtpd(8) entry in master.cf after setting:

debugger_command =
PATH=/usr/bin:/bin:/usr/sbin:/sbin
strace -o /tmp/tr.$process_name.$process_id -p $process_id & sleep 1

Then 'grep open' in the trace file, looking for unexpected reads of
certificate chain files.

To get closer to your config, I just built Postfix 3.4.12, against
OpenSSL 1.1.1, which also works:

# postfix start
postfix/postfix-script: starting the Postfix mail system

# openssl s_client -CAfile rootcert.pem -servername mx1.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# openssl s_client -CAfile rootcert.pem -servername mx2.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx2.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# openssl s_client -CAfile rootcert.pem -servername mx1.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# openssl s_client -CAfile rootcert.pem -servername mx2.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx2.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# cat ../log/maillog
Jun 09 15:35:23 vpro postfix/postfix-script[2294]: starting the Postfix 
mail system
Jun 09 15:35:23 vpro postfix/master[2296]: daemon started -- version 
3.4.12, configuration /var/tmp/postfix/etc
Jun 09 15:35:28 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:28 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
Jun 09 15:35:30 vpro postfix/smtpd[2301]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=1 quit=1 commands=3
Jun 09 15:35:31 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:31 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx2.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
Jun 09 15:35:33 vpro postfix/smtpd[2301]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=1 quit=1 commands=3
Jun 09 15:35:34 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:34 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
Jun 09 15:35:35 vpro postfix/smtpd[2301]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=1 quit=1 commands=3
Jun 09 15:35:37 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:37 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx2.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) 

Re: Best practices virtual hosts email naming setup

[Ralph Seichter]

* Robin Rowe:

> Let's say my domains are virtual1.com and virtual2.com. Both the same IP.
>
> /etc/hosts: virtual1.com
> rDNS: virtual1.com
>
> What is the best mail server naming approach to use in DNS PTR, DKIM and 
> SPF? Configure virtual2.com DNS for a mail server name of 
> mail.virtual1.com or mail.virtual2.com? Same question for DKIM and
> SPF.

The way I always do it, and recommend for my customers:

* Decide on a single, permanent name, which may but need not be related
  to the virtual domains, for each mail server, e.g. "host.example.com".
  Generate your SSL certificate for host.example.com.

* Ensure that forward and reverse DNS resolution matches, so if "dig
  host.example.com" returns 11.22.33.44, "dig -x 11.22.33.44" returns
  host.example.com (the same for the  record).

* Define "host.example.com" as the MX for your virtual domains.

* If host.example.com has several network interfaces, make sure to bind
  Postfix to outgoing IP addresses that match your SPF records.

The "host" part need not be "mail" or "mx", just a valid hostname. The
domain can be any valid (sub)domain; you may even want to choose a
deliberately neutral domain name unrelated to the virtual domains.

> Ok to sign all the DKIM mail with the same key, not generate a key for
> every virtual domain?

Yes, sharing a key has no negative effect when signatures are
verified. I am not going into possible security concerns here.

-Ralph

Re: SNI problem

[Ján Máté]

Hi Victor,

thanks for the explanation what's happening in the internals of Postfix, but 
the problem is still a mystery for me ...

I use the default Debian (Buster) /etc/ssl/openssl.cnf without any 
modifications, so I don't think that there is any default certificate chain 
that might be preloaded into each new SSL_CTX.

It looks like SNI works for you, but I cannot get it working - and tried really 
hard for more than a week (I read everything I found on Google and it looks 
like there are few people with working setup, and the remaining say that it 
does not work) :-/

Any idea how to debug it myself? ... or even better - I can allow you root 
access to the test server to check it yourself (just send me a private e-mail 
with your ssh public key).


Many thanks!


JM


> On 9 Jun 2020, at 19:07, Viktor Dukhovni  wrote:
> 
> On Wed, May 27, 2020 at 12:40:25AM +0200, Ján Máté wrote:
> 
>> The error is "SNI data for smtp.myserver.eu does not match next
>> certificate" even if I am 100% sure that the key+cert+chain is OK,
>> because I use the same key+cert+chain (loaded from same files) for the
>> smtpd_tls_chain_files (and there it works).
> 
> This is the symptom, the cause is indicated by the message one logged
> next to it.
> 
>> /etc/postfix/main.cf:
>> tls_server_sni_maps = hash:/etc/postfix/table_hash-tls_server_sni_maps
>> smtpd_tls_chain_files =
>>/etc/letsencrypt/live/eu.server.smtp/privkey.pem
>>/etc/letsencrypt/live/eu.server.smtp/fullchain.pem
>> 
>> /etc/postfix/table_hash-tls_server_sni_maps
>> smtp.myserver.eu /etc/letsencrypt/live/eu.myserver.smtp/privkey.pem 
>> /etc/letsencrypt/live/eu.myserver.smtp/fullchain.pem
>> smtp.myserver2.eu /etc/letsencrypt/live/eu.myserver2.smtp/privkey.pem 
>> /etc/letsencrypt/live/eu.myserver2.smtp/fullchain.pem
> 
> I just tested with:
> 
>main.cf:
>smtpd_tls_loglevel = 1
>smtpd_tls_security_level = may
>smtpd_tls_chain_files =
>${config_directory}/ee1pkey.pem
>${config_directory}/ee1cert.pem
>${config_directory}/cacert.pem
>tls_server_sni_maps = hash:${config_directory}/sni
> 
>sni
>mx1.example.com
>.../ee1pkey.pem
>.../ee1cert.pem
>.../cacert.pem
>mx2.example.com
>.../ee2pkey.pem
>.../ee2cert.pem
>.../cacert.pem
> 
> My logs below...
> 
>> May 26 22:38:58 myserver postfix/smtpd[72379]: maps_file_find: 
>> tls_server_sni_maps: 
>> hash:/etc/postfix/table_hash-tls_server_sni_maps(0,lock|fold_fix|src_rhs_is_file):
>>  smtp.myserver.eu  = 
>> LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9J...
> 
> You generally don't want to log this data (your log level is too high),
> and should not publish it, it is liable to reveal part of your private
> key, though luckily, in this case, only some of the fixed header bits
> and none of the key material.
> 
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in 
>> SNI data for smtp.myserver.eu does not match next certificate
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library problem: 
>> error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
>> certificate:../ssl/ssl_rsa.c:1107:
> 
> The second message is the real problem, OpenSSL believes it already has
> a certificate loaded for that algorithm, which should not be the case.
> The new key then does not match the already installed certificate.  But
> there shouldn't be one already loaded.
> 
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: error loading 
>> private keys and certificates from: SNI data for smtp.myserver.eu: aborting 
>> TLS handshake
> 
> And so things go wrong.  On the other hand, my logs show:
> 
>postfix/postfix-script[95733]: starting the Postfix mail system
>postfix/master[95735]: daemon started -- version 3.6-20200511, 
> configuration /var/tmp/postfix/etc
> 
>-- No SNI servername used
>postfix/smtpd[95756]: connect from localhost[127.0.0.1]
>postfix/smtpd[95756]: Anonymous TLS connection established from 
> localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 
> bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest 
> SHA256
>postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1 
> starttls=1 quit=1 commands=3
> 
>-- SNI servername: mx1.example.com
>postfix/smtpd[95756]: connect from localhost[127.0.0.1]
>postfix/smtpd[95756]: Anonymous TLS connection established from 
> localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher 
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
> RSA-PSS (2048 bits) server-digest SHA256
>postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1 
> starttls=1 quit=1 commands=3
> 
>-- SNI servername: mx2.example.com
>postfix/smtpd[95756]: connect from 

Re: Reject RCPT TO addresses with no domain

[Viktor Dukhovni]

On Wed, Jun 10, 2020 at 12:29:04AM +1200, Nathan Ward wrote:

> > put "reject_non_fqdn_recipient" into your smtpd_recipient_restrictions
> > - if you want to deny everyone from doing that, put it before common 
> > permit_mynetworks
> > and permit_sasl_authenticated 
> 
> Hi - thanks for your reply. I have explored that option, as noted
> later in my message - but I’d like to be able to accept email for
> user@gtld - where there is no dot in the domain, but there is still a
> domain. I’ve not seen that today, but, I would be surprised if people
> don’t start doing it at some point. Looks like there’s a handful of
> ccTLDs with MX records, for example.

That's an admirably principled position, but entirely without practical
merit.  Mail to user@tld is not happening any time soon, and jumping
through hoops to avoid breaking this is not worth anyone else spending
time to help you find work-arounds, even if you're willing to spend some
of your own time in pursuit of such lofty goals... :-(

Good luck.  My advice is to take the pragmatic path and break user@tld,
just like everyone else does.

-- 
Viktor.

Re: Reject RCPT TO addresses with no domain

[Jaroslaw Rafa]

Dnia 10.06.2020 o godz. 00:29:04 Nathan Ward pisze:
> 
> Hi - thanks for your reply. I have explored that option, as noted later in
> my message - but I’d like to be able to accept email for user@gtld - where
> there is no dot in the domain, but there is still a domain.

"user@something-with-no-dot" won't be interpreted the way you suggest.

Original format of e-mail address is "user@hostname", not "user@domain". And
a hostname may have no domain part.

So if you put something without a dot to the right of ".", it will be
interpreted as hostname, and that hostname will be resolved according to
current resolver configuration in effect. Ie. the hostname will usually
either be searched in the local domain, whatever it is, or - if the resolver
configuration permits - the name will also be searched in /etc/hosts. If the
hostname is not found, the address will be treated as non-existent and the
message rejected.

Shortly said, "user@com" will mean user at a host named "com" in your local
domain - whatever it is - or another host you called "com" in your
/etc/hosts file, and not user at a MX for TLD domain .com (even if such a MX
exists).
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: SNI problem

[Viktor Dukhovni]

On Wed, May 27, 2020 at 12:40:25AM +0200, Ján Máté wrote:

> The error is "SNI data for smtp.myserver.eu does not match next
> certificate" even if I am 100% sure that the key+cert+chain is OK,
> because I use the same key+cert+chain (loaded from same files) for the
> smtpd_tls_chain_files (and there it works).

This is the symptom, the cause is indicated by the message one logged
next to it.

> /etc/postfix/main.cf:
> tls_server_sni_maps = hash:/etc/postfix/table_hash-tls_server_sni_maps
> smtpd_tls_chain_files =
> /etc/letsencrypt/live/eu.server.smtp/privkey.pem
> /etc/letsencrypt/live/eu.server.smtp/fullchain.pem
> 
> /etc/postfix/table_hash-tls_server_sni_maps
> smtp.myserver.eu /etc/letsencrypt/live/eu.myserver.smtp/privkey.pem 
> /etc/letsencrypt/live/eu.myserver.smtp/fullchain.pem
> smtp.myserver2.eu /etc/letsencrypt/live/eu.myserver2.smtp/privkey.pem 
> /etc/letsencrypt/live/eu.myserver2.smtp/fullchain.pem

I just tested with:

main.cf:
smtpd_tls_loglevel = 1
smtpd_tls_security_level = may
smtpd_tls_chain_files =
${config_directory}/ee1pkey.pem
${config_directory}/ee1cert.pem
${config_directory}/cacert.pem
tls_server_sni_maps = hash:${config_directory}/sni

sni
mx1.example.com
.../ee1pkey.pem
.../ee1cert.pem
.../cacert.pem
mx2.example.com
.../ee2pkey.pem
.../ee2cert.pem
.../cacert.pem

My logs below...

> May 26 22:38:58 myserver postfix/smtpd[72379]: maps_file_find: 
> tls_server_sni_maps: 
> hash:/etc/postfix/table_hash-tls_server_sni_maps(0,lock|fold_fix|src_rhs_is_file):
>  smtp.myserver.eu  = 
> LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9J...

You generally don't want to log this data (your log level is too high),
and should not publish it, it is liable to reveal part of your private
key, though luckily, in this case, only some of the fixed header bits
and none of the key material.

> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in SNI 
> data for smtp.myserver.eu does not match next certificate
> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library problem: 
> error:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
> certificate:../ssl/ssl_rsa.c:1107:

The second message is the real problem, OpenSSL believes it already has
a certificate loaded for that algorithm, which should not be the case.
The new key then does not match the already installed certificate.  But
there shouldn't be one already loaded.

> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: error loading private 
> keys and certificates from: SNI data for smtp.myserver.eu: aborting TLS 
> handshake

And so things go wrong.  On the other hand, my logs show:

postfix/postfix-script[95733]: starting the Postfix mail system
postfix/master[95735]: daemon started -- version 3.6-20200511, 
configuration /var/tmp/postfix/etc

-- No SNI servername used
postfix/smtpd[95756]: connect from localhost[127.0.0.1]
postfix/smtpd[95756]: Anonymous TLS connection established from 
localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) 
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1 
starttls=1 quit=1 commands=3

-- SNI servername: mx1.example.com
postfix/smtpd[95756]: connect from localhost[127.0.0.1]
postfix/smtpd[95756]: Anonymous TLS connection established from 
localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1 
starttls=1 quit=1 commands=3

-- SNI servername: mx2.example.com
postfix/smtpd[95756]: connect from localhost[127.0.0.1]
postfix/smtpd[95756]: Anonymous TLS connection established from 
localhost[127.0.0.1] to mx2.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1 
starttls=1 quit=1 commands=3

> In short: if a connection from the client is performed without SNI (or
> SNI hostname not present in the tls_server_sni_maps) then everything
> works as expected (key+cert+chain from smtpd_tls_chain_files is used),
> but if I connect using a valid SNI hostname (the new
> tls_server_sni_maps is used) then the same key+cert+chain not works.

It seems that somehow, a certificate of the same type is already loaded
into the SSL handle under construction.  It is unclear how that
happened.

> postmap -Fq smtp.myserver.eu hash:/etc/postfix/table_hash-tls_server_sni_maps
> 
> returns the correct 

Re: Multiple server for one domain

[Matteo Cazzador]

Thanks a lot i try to follow your suggest.

best regards.

Il 09/06/2020 10:17, Claus R. Wickinghoff ha scritto:

Hi Matteo,


On berlin.example.com server how you define the users?

Local user like user2 user3 .. without virtual domain is correct?


Yes. When not using any database/ldap you create just system accounts, 
login is primary-e-mail-address, i.e. user2


When setting mydestination to berlin.example.com postfix strips the 
domain part and looks for a local user with the name part of the e-mail.


So all alias configuration like bob.us...@example.com or 
sa...@example.com has to be done in the virtual a the central server. 
Which is quite handy as you only have to deal with one virtual file.


You need to do something extra mydestination (on berlin) to 
receive correctly mail from


us...@berlin.example.com to  user2 ?


No, just make sure to strip out example.com on server berlin. He is 
not in charge for this domain, only for berlin.example.com.


BTW: The users don't need to know about the subdomains. They just send 
out as us...@example.com.


For berlin.example.com which smtp server you use it self or external 
(for send mail ?


On all branch servers always set the central server as relayhost. 
Every e-mail has to make a loop, because the central one knows all the 
aliases, makes the routing decisions and can probably filter if needed.


The central server is the only one to receive and send to the outside 
world. Another bonus here: Only one place with a logfile to search for 
lost communication.


Groetjes
   Claus



--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.

Le informazioni contenute in questa e-mail e nei files eventualmente allegati 
sono destinate unicamente ai destinatari della stessa e
sono da considerarsi strettamente riservate. E' proibito copiare, salvare, 
utilizzare,  inoltrare a terzi e diffondere il contenuto della presente
senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 
196/2003. Se avete ricevuto questo messaggio per errore siete
pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di 
cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**

Re: Reject RCPT TO addresses with no domain

[Wietse Venema]

Wietse Venema:
> Nathan Ward:
> > Hi all,
> > 
> > I am trying to figure out the best way to reject RCPT TO addresses with no
> > domain part - i.e. "RCPT TO: " or similar. I do not want to rewrite
> > to $myhostname or $mydomain or similar.
> 
> There is no Postfix setting to allow or deny every possible syntax
> error.
> 
> Postfix converts addresses into a standard form, otherwise a bad
> actor could easily circumvent access restrictions by playing games
> with quotes, backslash, or other transformations. The downside is
> that Postfix access checks don't get the original address form.
> 
> You can use smtpd_command_filter to convert a domainless address into
> a form that can be blocked by an access restriction.
> 
>/etc/postfix/main.cf:
>smtpd_command_filter = pcre:/etc/postfix/command_filter
># Require RCPT TO:.
>strict_rfc821_envelopes = yes
> 
>/etc/postfix/command_filter:
># Tag addresses that have no @ with @domain.invalid.
>/^(RCPT\s+TO:\s*<)[^@]+)(>.*)/ $1$2@domain.invalid$3

 /^(RCPT\s+TO:\s*<)([^@]+)(>.*)/ $1$2@domain.invalid$3

There was a '(' nissing.

> Combine with an access map that rejects mail from domain.invalid.
> 
> Just like "example" and "localhost", the name "invalid" is reserved
> by the Internet Engineering Task Force (IETF) as a domain name that
> may not be installed as a top-level domain in the Domain Name System
> (DNS) of the Internet.
> 
> Wietse
> 

Re: Reject RCPT TO addresses with no domain

[Matus UHLAR - fantomas]

On 09.06.20 23:41, Nathan Ward wrote:

I am trying to figure out the best way to reject RCPT TO addresses with no
domain part - i.e. "RCPT TO: " or similar. I do not want to rewrite
to $myhostname or $mydomain or similar.

I am on postfix 2.10.



On 10/06/2020, at 00:07, Matus UHLAR - fantomas  wrote:
put "reject_non_fqdn_recipient" into your smtpd_recipient_restrictions
- if you want to deny everyone from doing that, put it before common 
permit_mynetworks
and permit_sasl_authenticated


On 10.06.20 00:29, Nathan Ward wrote:

Hi - thanks for your reply.  I have explored that option, as noted later in
my message - but I’d like to be able to accept email for user@gtld - where
there is no dot in the domain, but there is still a domain.  I’ve not seen
that today, but, I would be surprised if people don’t start doing it at
some point.  Looks like there’s a handful of ccTLDs with MX records, for
example.


I am not sure whether this is allowed by RFCs, but it's no issue now.


Is that likely to break for a lot of people - yes of course.  I don’t want
to be one of the people who it breaks for :-)


sorry, I have misunderstood your original request.

what you want should be doable by using smtpd_command_filter.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.

Re: Reject RCPT TO addresses with no domain

[Wietse Venema]

Nathan Ward:
> Hi all,
> 
> I am trying to figure out the best way to reject RCPT TO addresses with no
> domain part - i.e. "RCPT TO: " or similar. I do not want to rewrite
> to $myhostname or $mydomain or similar.

There is no Postfix setting to allow or deny every possible syntax
error.

Postfix converts addresses into a standard form, otherwise a bad
actor could easily circumvent access restrictions by playing games
with quotes, backslash, or other transformations. The downside is
that Postfix access checks don't get the original address form.

You can use smtpd_command_filter to convert a domainless address into
a form that can be blocked by an access restriction.

   /etc/postfix/main.cf:
   smtpd_command_filter = pcre:/etc/postfix/command_filter
   # Require RCPT TO:.
   strict_rfc821_envelopes = yes

   /etc/postfix/command_filter:
   # Tag addresses that have no @ with @domain.invalid.
   /^(RCPT\s+TO:\s*<)[^@]+)(>.*)/ $1$2@domain.invalid$3

Combine with an access map that rejects mail from domain.invalid.

Just like "example" and "localhost", the name "invalid" is reserved
by the Internet Engineering Task Force (IETF) as a domain name that
may not be installed as a top-level domain in the Domain Name System
(DNS) of the Internet.

Wietse

Re: lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

[Marvin Renich]

* PGNet Dev  [200608 19:19]:
>https://savannah.nongnu.org/projects/spamass-milt/
>https://github.com/mpaperno/spampd
>https://gitlab.com/glts/spamassassin-milter
> 
> anyone have any current experience with any of these?

I also use the first one (Debian package spamass-milter) along with
milter-greylist (only greylisting messages with a spam score in the
lower end of the "positive" range to avoid rejecting false
positives from spamassassin while not greylisting clearly legitimate
email).

...Marvin

Re: Reject RCPT TO addresses with no domain

[Nathan Ward]

> On 10/06/2020, at 00:07, Matus UHLAR - fantomas  wrote:
> 
> On 09.06.20 23:41, Nathan Ward wrote:
>> I am trying to figure out the best way to reject RCPT TO addresses with no
>> domain part - i.e. "RCPT TO: " or similar. I do not want to rewrite
>> to $myhostname or $mydomain or similar.
>> 
>> I am on postfix 2.10.
> 
> put "reject_non_fqdn_recipient" into your smtpd_recipient_restrictions
> - if you want to deny everyone from doing that, put it before common 
> permit_mynetworks
> and permit_sasl_authenticated 

Hi - thanks for your reply. I have explored that option, as noted later in my 
message - but I’d like to be able to accept email for user@gtld - where there 
is no dot in the domain, but there is still a domain. I’ve not seen that today, 
but, I would be surprised if people don’t start doing it at some point. Looks 
like there’s a handful of ccTLDs with MX records, for example.

Is that likely to break for a lot of people - yes of course. I don’t want to be 
one of the people who it breaks for :-)

--
Nathan Ward

Re: Reject RCPT TO addresses with no domain

[Matus UHLAR - fantomas]

On 09.06.20 23:41, Nathan Ward wrote:

I am trying to figure out the best way to reject RCPT TO addresses with no
domain part - i.e. "RCPT TO: " or similar. I do not want to rewrite
to $myhostname or $mydomain or similar.

I am on postfix 2.10.


put "reject_non_fqdn_recipient" into your smtpd_recipient_restrictions
- if you want to deny everyone from doing that, put it before common 
permit_mynetworks
and permit_sasl_authenticated 



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watkins.  -- Daffy Duck & Porky Pig

Reject RCPT TO addresses with no domain

[Nathan Ward]

Hi all,

I am trying to figure out the best way to reject RCPT TO addresses with no
domain part - i.e. "RCPT TO: " or similar. I do not want to rewrite
to $myhostname or $mydomain or similar.

I am on postfix 2.10.

This is for an MSA function - if email passes validation checks and is
authenticated, it is immediately sent to another system for delivery or
transmission to remote networks. There is no local delivery on this server.
Due to the nature of the system, any incoming mail without a domain is due
to end user errors - so we want to reject it and present the client with an
error message in the SMTP exchange.

I have come up with some solutions which feel a lot like workarounds /
hacks - i.e. checking for .*@$myhostname as a recipient and rejecting it,
or something like that.

Are there any better ways to achieve this? I was expecting to find an
option, like "reject_no_domain" in recipient restrictions or something.
What I've found is that recipient_restrictions checks the resolved
recipient - not what the client presented.

I note that reject_non_fqdn_recipient exists, however, I'd like to be able
to accept mail addressed to user@gtld - for when people inevitably start
doing that if they're not already.

Thanks in advance !

--
Nathan Ward

Re: lightweight/milter Spamassassin-integtration options for Postfix -- current experience / faves?

[Jaroslaw Rafa]

Dnia  8.06.2020 o godz. 16:18:14 PGNet Dev pisze:
> 
>https://savannah.nongnu.org/projects/spamass-milt/
>https://github.com/mpaperno/spampd
>https://gitlab.com/glts/spamassassin-milter
> 
> anyone have any current experience with any of these?

I use the first one as it came by default in Debian repositories. It's OK
for me.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Best practices virtual hosts email naming setup

[Robin Rowe]

If I have a server with 2 virtual hosts, what is the best approach to 
naming the mail server for the second virtual host?


Let's say my domains are virtual1.com and virtual2.com. Both the same IP.

/etc/hosts: virtual1.com
rDNS: virtual1.com

What is the best mail server naming approach to use in DNS PTR, DKIM and 
SPF? Configure virtual2.com DNS for a mail server name of 
mail.virtual1.com or mail.virtual2.com? Same question for DKIM and SPF.


In other words, better that every virtual domain use the same mail 
server virtual1.com or better that each domain have a mail.domain name 
that matches its domain name? Do spam filters care if rDNS of 
virtual1.com doesn't match when looking up some...@virtual2.com?


Ok to sign all the DKIM mail with the same key, not generate a key for 
every virtual domain?


Robin

Re: Multiple server for one domain

[Claus R. Wickinghoff]

Hi Matteo,


On berlin.example.com server how you define the users?

Local user like user2 user3 .. without virtual domain is correct?


Yes. When not using any database/ldap you create just system accounts, 
login is primary-e-mail-address, i.e. user2


When setting mydestination to berlin.example.com postfix strips the 
domain part and looks for a local user with the name part of the e-mail.


So all alias configuration like bob.us...@example.com or 
sa...@example.com has to be done in the virtual a the central server. 
Which is quite handy as you only have to deal with one virtual file.


You need to do something extra mydestination (on berlin) to receive 
correctly mail from


us...@berlin.example.com to  user2 ?


No, just make sure to strip out example.com on server berlin. He is not 
in charge for this domain, only for berlin.example.com.


BTW: The users don't need to know about the subdomains. They just send 
out as us...@example.com.


For berlin.example.com which smtp server you use it self or external 
(for send mail ?


On all branch servers always set the central server as relayhost. Every 
e-mail has to make a loop, because the central one knows all the 
aliases, makes the routing decisions and can probably filter if needed.


The central server is the only one to receive and send to the outside 
world. Another bonus here: Only one place with a logfile to search for 
lost communication.


Groetjes
   Claus


--
--
Claus R. Wickinghoff, Dipl.-Ing.
using Linux since 1994 and still happy... :-)

Re: Multiple server for one domain

[Matteo Cazzador]

Hi thanks, some clarification please

On berlin.example.com server how you define the users?

Local user like user2 user3 .. without virtual domain is correct?

You need to do something extra mydestination (on berlin) to receive 
correctly mail from


us...@berlin.example.com to  user2 ?

For berlin.example.com which smtp server you use it self or external 
(for send mail ?


Thanks !

Il 09/06/2020 09:25, Claus R. Wickinghoff ha scritto:

Hi,

I sometimes encounter similar setups.

I usually solve this by identifying one server as a central system 
(example.com) and then using sudomomains for mail-routing to the 
branches (paris.example.com, berlin.example.com).


On the central system you'll have to maintain the virtual:

us...@example.com   us...@paris.example.com
us...@example.com   us...@berlin.example.com

routing is done in the transport file:

paris.example.com   smtp:192.168.10.3
berlin.example.com   smtp:192.168.20.3
(You can use external addresses, but I prefer to use vpn connections 
so all traffic is encrypted between the branches.)


On each branch system you'll have to set the mydestination in main.cf 
to paris.example.com or berlin.example.com, respectively.


And you should set the central system as relay host in main.cf at the 
branches. You just have to create the users working at this place, no 
need for a virtual.


This way all traffic initiated in a branch is relayed to the central 
(because mydestination does not match for @example.com), there the 
virtual entry forwards it back to the branch. So all traffic within a 
branch takes a loop via the central system.


The advantage is that you can easily install and maintain all filter 
stuff (anti-virus, anti-spam, e-mail-archive) at the central system, 
as any e-mail has to pass by here.


I hope you'll get the idea :-) Otherwise please feel free to ask.

Groetjes
   Claus






--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.

Le informazioni contenute in questa e-mail e nei files eventualmente allegati 
sono destinate unicamente ai destinatari della stessa e
sono da considerarsi strettamente riservate. E' proibito copiare, salvare, 
utilizzare,  inoltrare a terzi e diffondere il contenuto della presente
senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 
196/2003. Se avete ricevuto questo messaggio per errore siete
pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di 
cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**

Re: Multiple server for one domain

[Claus R. Wickinghoff]

Hi,

I sometimes encounter similar setups.

I usually solve this by identifying one server as a central system 
(example.com) and then using sudomomains for mail-routing to the 
branches (paris.example.com, berlin.example.com).


On the central system you'll have to maintain the virtual:

us...@example.com   us...@paris.example.com
us...@example.com   us...@berlin.example.com

routing is done in the transport file:

paris.example.com   smtp:192.168.10.3
berlin.example.com   smtp:192.168.20.3
(You can use external addresses, but I prefer to use vpn connections so 
all traffic is encrypted between the branches.)


On each branch system you'll have to set the mydestination in main.cf to 
paris.example.com or berlin.example.com, respectively.


And you should set the central system as relay host in main.cf at the 
branches. You just have to create the users working at this place, no 
need for a virtual.


This way all traffic initiated in a branch is relayed to the central 
(because mydestination does not match for @example.com), there the 
virtual entry forwards it back to the branch. So all traffic within a 
branch takes a loop via the central system.


The advantage is that you can easily install and maintain all filter 
stuff (anti-virus, anti-spam, e-mail-archive) at the central system, as 
any e-mail has to pass by here.


I hope you'll get the idea :-) Otherwise please feel free to ask.

Groetjes
   Claus





--
Claus R. Wickinghoff, Dipl.-Ing.
using Linux since 1994 and still happy... :-)

Re: Postfix restrictions

[@lbutlr]

> On 08 Jun 2020, at 16:21, yuv  wrote:
> 
> On Sun, 2020-06-07 at 20:36 -0600, @lbutlr wrote:
>> On 07 Jun 2020, at 06:38, yuv  wrote:
>>> Is there a valid reason for a sender not to fix something so
>>> essential as DNS configuration?
>> 
>> That’s not the question.
> 
> Oh, yes it is.

Really not.

> Making room for degraded configurations is detrimental to the protocol and to 
> the federation of internet email server operators if internet email is ever 
> to mature into a reliable messaging system on par with snailmail.

Yes, you can take a political "this is wrong" stance if you want. Or you can 
get the mail. The choice is yours. Certainly my blocking yahoo serves is a 
political decision.

If you have users, you have less of a choice.

>> The question is, do you want to receive the mail or not? If you do,
>> then don’t use reject_unknown_helo_hostname 
>> 
>> It’s a question only you can answer, but it seems most admins find
>> that this results in too much lost mail.
> 
> The consequence of this narrow framing is that internet email is
> serving the interest of spammers more than the interest of recipients.

Completely irrelevant.

> Spammers pay admins better than recipients, so we get what we pay for. 

I don't know what this means.

> Meanwhile, alternative messaging systems with more rigid controls, some
> of which are proprietary, achieve maturity much faster.

Uh huh. I've been hearing about the death of email for 20 years. I look forward 
to it, but I don't think it's happening in my lifetime.

> Some of them achieve scale as well.  At some point, the cost/benefit analysis 
> of maintaining internet email vs. using alternatives such as SMS will tilt
> obviously against email

Sure it will. It hasn't happened yet, and I don't think it will happen (SMS is 
garbage), but it is still irrelevant to the topic.

> and that's where "most admins" will regret their narrow view. 

How do you figure? You think we run Mailservers because we are emotionally 
invested in the idea of email as the ONE TRUE INFORMATION EXCHANGE? Nope. We 
are mail admins because we and our users need email. As soon as that is no 
longer the case I will gleefully switch to the better thing.





-- 
Disorder is merely the order you were not looking for." Henri Bergson

Multiple server for one domain

[Matteo Cazzador]

Hi I am writing to you for an old question that I had already asked.

I want to understand if it is possible to optimize the configuration 
that I am using now.


I'm using virtual mail server configuration.

I've 4 mail servers (that send and receive mail) for one domain only 
"example.com", each mail server in a different location (with different 
account) but with the same domain.


I use different dns name for every server, mail.server1.example.com, 
mail.server2.example.com and so on.


In my actual solution i made a "forward" for every users on every 
server. I have over 100 users.


On every server i do :

On server 1 (where user2 doesn't exist)

us...@example.com -> us...@mail.server2.example.com

On server 2 (where user2 exist)

us...@mail.server2.example.com -> us...@example.com

with virtual_alias_maps = hash:/etc/postfix/virtual on every servers

Which is the best practice to manage this situation?

*## For receive *

I think is a good idea to have an external mailgateway that receive all 
domain email and forward to every "backend" servers with no MX (server1, 
server1)?


*##*

*## For SMTP
*

Which is the best solution for send email from every servers?

I need to set an unique external "relayhost" for every server or is 
better to use every servers like smtp server?


_Is it possible to avoid having to define _

virtual_alias_maps = hash:/etc/postfix/virtual

on every servers or set a condition like if user is not local send to 
external "relayhost" or something like that.


*##*

I hope I explained myself

Thanks


--

Rispetta l'ambiente: se non ti è necessario,  non stampare questa mail.


Le informazioni contenute in questa e-mail e nei files eventualmente
allegati sono destinate unicamente ai destinatari della stessa
e sono da considerarsi strettamente riservate.
E' proibito copiare, salvare, utilizzare,  inoltrare a terzi e diffondere
il contenuto della presente senza il preventivo consenso, ai sensi
dell'articolo 616 c.p. e della Legge n. 196/2003.
Se avete ricevuto questo messaggio per errore siete pregati di comunicarlo
immediatamente all'indirizzo mittente, nonché di cancellarne il contenuto
senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**