Re: Understanding master.cf

[Gerben Wierda]

> On 5 Oct 2019, at 18:43, Viktor Dukhovni  wrote:

Thank you. That helped (more to point out I had made a stupid mistake).

> On Sat, Oct 05, 2019 at 11:51:24AM +0200, Gerben Wierda wrote:
> 
>> [...], my log says:
>> 
>> Oct 05 11:35:21 mail postfix/smtpd[2218]: cannot load Certification
>>  Authority data, 
>> CAfile="/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem":
>>  disabling TLS support
> 
> Are you sure this is a CAfile (containing certificates of root CAs,
> a.k.a. trust anchors)?  Based on the name, I would have guessed
> this to be a certificate chain file for the server's own certificate,
> possibly also including the server's private key?

Yes, it works with postfix when it can be read. It is a full letsencrypt chain. 

It turns out I forgot that I had decided not to install in /etc/certificates 
(where macOS Server maintains certificates)

> 
> Please post the output of (and/or errors reported by):
> 
>  # 
> chain=/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem
>  # egrep '^- ' "$chain"
>  # openssl crl2pkcs7 -nocrl -certfile "$chain" |
>openssl pkcs7 -print_certs -noout -text |
>egrep '(Certificate|Subject|Issuer):'
> 
> this should show the types of PEM objects stored in that file, without
> disclosing any sensitive content.

On the system I copied it from:

dumbledore:postfix gerben$ openssl crl2pkcs7 -nocrl -certfile 
/etc/certificates/www.rna.nl.F1BCD75E0F6DD3B3B0145CB328699BDEEF21FA5C.chain.pem 
| openssl pkcs7 -print_certs -noout -text | egrep 
'(Certificate|Subject|Issuer):'
Certificate:
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Subject: CN=www.rna.nl
Certificate:
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Certificate:
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3

But on the new system I was testing I had indeed made an error, because it no 
longer lives in /etc/certificates (where macOS Server maintains everything) but 
only in /etc/letsencrypt. There I got cert, chain and full chain and while the 
chain that macOS Server creates has all of them, the letsencrypt ones are 
separate:

bash-3.2#  openssl crl2pkcs7 -nocrl -certfile 
/etc/letsencrypt/live/www.rna.nl/cert.pem | openssl pkcs7 -print_certs -noout 
-text | egrep '(Certificate|Subject|Issuer):'
Certificate:
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Subject: CN=www.rna.nl 
bash-3.2# openssl crl2pkcs7 -nocrl -certfile 
/etc/letsencrypt/live/www.rna.nl/chain.pem | openssl pkcs7 -print_certs -noout 
-text | egrep '(Certificate|Subject|Issuer):'
Certificate:
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
bash-3.2# openssl crl2pkcs7 -nocrl -certfile 
/etc/letsencrypt/live/www.rna.nl/fullchain.pem | openssl pkcs7 -print_certs 
-noout -text | egrep '(Certificate|Subject|Issuer):'
Certificate:
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Subject: CN=www.rna.nl
Certificate:
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

>> Does chrooting smtpd require a local copy of certificates inside the chroot
>> jail?
> 
> No.  The SMTP server loads its CAfile before entering the chroot
> jail (while still running as root).  There must be something wrong
> with that file,

Indeed. It just wasn’t there. I need to make sure the _postfix user can read 
the files. Normally, _postscript cannot read /etc/letsencrypt/live so I’ll have 
to figure a way around that that doesn’t break on every future ech-90-days 
letsencrypt update. Probably easiest is to give the postfix user read access to 
/etc/letsencrypt/live/www.rna.nl  and it’s content. 
Otherwise it is a deplyhook in letsencrypt.

But for now, I can copy and go on with testing.

G

Only logging from a connection when an unrelated error is forced in main.cf

[Gerben Wierda]

Using postfix 3.4.6 on macOS. Using maillog as syslog is broken on macOS.

The postfix server is running on 192.168.2.66, dovecot and other parts of the 
mail setup not yet. I am connecting from 192.168.2.67 on port 25, using telnet. 
I’m issuing an HELO and a VRFY (turned on temporarily in main.cf). I’ve set 
192.168.2.67 in the debug_peer_list.

When I introduce an error in main.cf (the file for check_client_access does not 
exist), 

debug_peer_level = 2
debug_peer_list = 192.168.2.67
check_client_access 
regexp:/opt/local/etc/postfix/error/rna_rbl_whitelist_clients

I see debugging info when I connectusing telnet.

Oct 06 13:16:17 mail /postfix-script[11198]: refreshing the Postfix mail system
Oct 06 13:16:17 mail postfix/master[11129]: reload -- version 3.4.6, 
configuration /opt/local/etc/postfix
Oct 06 13:16:37 mail postfix/smtpd[11208]: error: open 
/opt/local/etc/postfix/error/rna_rbl_whitelist_clients: No such file or 
directory
Oct 06 13:16:40 mail postfix/smtpd[11208]: connect from unknown[192.168.2.67]
Oct 06 13:16:40 mail postfix/smtpd[11208]: smtp_stream_setup: maxtime=300 
enable_deadline=0
Oct 06 13:16:40 mail postfix/smtpd[11208]: match_hostname: 
smtpd_client_event_limit_exceptions: unknown ~? 127.0.0.0/8
Oct 06 13:16:40 mail postfix/smtpd[11208]: match_hostaddr: 
smtpd_client_event_limit_exceptions: 192.168.2.67 ~? 127.0.0.0/8
Oct 06 13:16:40 mail postfix/smtpd[11208]: match_hostname: 
smtpd_client_event_limit_exceptions: unknown ~? 192.168.2.0/24
Oct 06 13:16:40 mail postfix/smtpd[11208]: match_hostaddr: 
smtpd_client_event_limit_exceptions: 192.168.2.67 ~? 192.168.2.0/24
Oct 06 13:16:40 mail postfix/smtpd[11208]: report connect to all milters
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: "j"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: result 
"mail.rna.nl"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: "{daemon_name}"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: result 
"mail.rna.nl"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: "{daemon_addr}"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: result 
"192.168.2.66"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: "v"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter_macro_lookup: result "Postfix 
3.4.6"
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter8_connect: non-protocol events 
for protocol version 6: 
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter8_connect: transport=unix 
endpoint=/opt/local/var/run/rspamd/milter.sock
Oct 06 13:16:40 mail postfix/smtpd[11208]: warning: connect to Milter service 
unix:/opt/local/var/run/rspamd/milter.sock: No such file or directory
Oct 06 13:16:40 mail postfix/smtpd[11208]: milter8_conn_event: skip milter 
unix:/opt/local/var/run/rspamd/milter.sock
Oct 06 13:16:40 mail postfix/smtpd[11208]: > unknown[192.168.2.67]: 220 
mail.rna.nl ESMTP Postfix
Oct 06 13:16:40 mail postfix/smtpd[11208]: watchdog_pat: 0x7fdc9c42ed90
Oct 06 13:17:08 mail postfix/smtpd[11208]: < unknown[192.168.2.67]: quit
Oct 06 13:17:08 mail postfix/smtpd[11208]: > unknown[192.168.2.67]: 221 2.0.0 
Bye
Oct 06 13:17:08 mail postfix/smtpd[11208]: match_hostname: 
smtpd_client_event_limit_exceptions: unknown ~? 127.0.0.0/8
Oct 06 13:17:08 mail postfix/smtpd[11208]: match_hostaddr: 
smtpd_client_event_limit_exceptions: 192.168.2.67 ~? 127.0.0.0/8
Oct 06 13:17:08 mail postfix/smtpd[11208]: match_hostname: 
smtpd_client_event_limit_exceptions: unknown ~? 192.168.2.0/24
Oct 06 13:17:08 mail postfix/smtpd[11208]: match_hostaddr: 
smtpd_client_event_limit_exceptions: 192.168.2.67 ~? 192.168.2.0/24
Oct 06 13:17:08 mail postfix/smtpd[11208]: disconnect event to all milters
Oct 06 13:17:08 mail postfix/smtpd[11208]: milter8_disc_event: skip quit milter 
unix:/opt/local/var/run/rspamd/milter.sock
Oct 06 13:17:08 mail postfix/smtpd[11208]: disconnect from 
unknown[192.168.2.67] quit=1 commands=1
Oct 06 13:17:08 mail postfix/smtpd[11208]: free all milters
Oct 06 13:17:08 mail postfix/smtpd[11208]: free milter 
unix:/opt/local/var/run/rspamd/milter.sock
Oct 06 13:17:08 mail postfix/smtpd[11208]: name_mask: no_address_mappings

When I remove the forced error

check_client_access regexp:/opt/local/etc/postfix/rna_rbl_whitelist_clients

I see nothing. No “connect from unknown[192.168.2.67]”. Nothing. This baffles 
me. Why do I only see logging in my maillog (including debug_peer) when I 
introduce an unrelated error in main.cf? I’d like to see logging for each mail 
delivery.

Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: Only logging from a connection when an unrelated error is forced in main.cf

[Wietse Venema]

Gerben Wierda:
> When I remove the forced error
> 
> check_client_access regexp:/opt/local/etc/postfix/rna_rbl_whitelist_clients
> 
> I see nothing. No ?connect from unknown[192.168.2.67]?. Nothing.
> This baffles me. Why do I only see logging in my maillog (including
> debug_peer) when I introduce an unrelated error in main.cf? I?d
> like to see logging for each mail delivery.

With confiuration error:

# postconf maillog_file debug_peer_list smtpd_client_restrictions
maillog_file = /tmp/log/maillog
debug_peer_list = 127.0.0.1
smtpd_client_restrictions = regexp:/non/existent
# date; telnet 127.0.0.1 25
Sun Oct  6 10:05:53 EDT 2019
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 tail.porcupine.org ESMTP Postfix
quit
221 2.0.0 Bye
Connection closed by foreign host.
#

Logfile:
Oct 06 10:04:03 tail postfix/master[2062]: reload -- version 3.5-20190922, 
configuration /etc/postfix
Oct 06 10:05:53 tail postfix/smtpd[2518]: error: open /non/existent: No such 
file or directory
Oct 06 10:05:53 tail postfix/smtpd[2518]: connect from localhost[127.0.0.1]
Oct 06 10:05:53 tail postfix/smtpd[2518]: smtp_stream_setup: maxtime=300 
enable_deadline=0
Oct 06 10:05:53 tail postfix/smtpd[2518]: > localhost[127.0.0.1]: 220 
tail.porcupine.org ESMTP Postfix
...
Oct 06 10:05:58 tail postfix/smtpd[2518]: < localhost[127.0.0.1]: quit
Oct 06 10:05:58 tail postfix/smtpd[2518]: > localhost[127.0.0.1]: 221 2.0.0 Bye
Oct 06 10:05:58 tail postfix/smtpd[2518]: disconnect from localhost[127.0.0.1] 
quit=1 commands=1

After removing the configuration error:

# postconf maillog_file debug_peer_list smtpd_client_restrictions
maillog_file = /tmp/log/maillog
debug_peer_list = 127.0.0.1
smtpd_client_restrictions =
# date; telnet 127.0.0.1 25
Sun Oct  6 10:08:18 EDT 2019
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 tail.porcupine.org ESMTP Postfix
quit
221 2.0.0 Bye
Connection closed by foreign host.
#

Logfile:
Oct 06 10:08:02 tail postfix/master[2062]: reload -- version 3.5-20190922, 
configuration /etc/postfix
Oct 06 10:08:18 tail postfix/smtpd[2545]: connect from localhost[127.0.0.1]
Oct 06 10:08:18 tail postfix/smtpd[2545]: smtp_stream_setup: maxtime=300 
enable_deadline=0
Oct 06 10:08:18 tail postfix/smtpd[2545]: > localhost[127.0.0.1]: 220 
tail.porcupine.org ESMTP Postfix
...
Oct 06 10:08:20 tail postfix/smtpd[2545]: < localhost[127.0.0.1]: quit
Oct 06 10:08:20 tail postfix/smtpd[2545]: > localhost[127.0.0.1]: 221 2.0.0 Bye
Oct 06 10:08:20 tail postfix/smtpd[2545]: disconnect from localhost[127.0.0.1] 
quit=1 commands=1

In other words, this still works as intended. Code changes since
Postfix 3.4.5 are totally unrelated to error handling or logging.

Wietse

Wietse

Re: Limiting mail relay

[Patrick Mahan]

Many thanks.  Especially for the GeoIP reference.  I will take steps to
clean up that account.

Again, thanks.

Patrick

On Sat, Oct 5, 2019 at 11:45 PM Viktor Dukhovni 
wrote:

> > On Oct 6, 2019, at 2:09 AM, Patrick Mahan  wrote:
> >
> > I am trying to understand how I am being a mail relay for (what I
> believe) are unauthorized users.
> > I have the following postfix config set:
> >
> > smtpd_relay_restrictions = permit_mynetworks,
> permit_sasl_authentication, reject_unauth_destination
>
> The second of these is presumably actually "permit_sasl_authenticated"...
>
> > The logs are showing -
> >
> > Oct  5 00:00:02 ns postfix/smtpd[65859]: BB829A32C24:
> client=unknown[37.114.181.42], sasl_method=LOGIN, sasl_username=tracy
>
> A successful login as "tracy" was completed from a system at
> [37.114.181.42],
> which GeoIP on my system reports as:
>
> 37.114.181.42: AZ, Azerbaijan
>
> If the real "tracy" is not logging in from Azerbaijan, her account
> password has been compromised, and the compromise might affect more
> than the password for your mailserver, perhaps remote control of her
> computer, ...
>
> The rest is just consequences of the account takeover.
>
> --
> Viktor.
>
>

How to avoid being classified as spam by Google?

[martin f krafft]

Folks,

I hope this is not too off-topic, but I figure this is the best 
mailing list because we're probably not in this boat alone, wherein 
we're annoyed (very) and a bit helpless about Google. I have to ask 
here, because Google of course doesn't care about us.


We operate several postfix mailservers with hundreds of users, and 
the rate at which these users find their emails spamfiled on the 
side of Gmail recipients is increasing.


And yet, we're doing everything we can! SPF is configured, DMARC is 
configured, DKIM works. And we've even registered the domains and 
MXs with Google's Postmaster services, 
https://postmaster.google.com/.


And yet, most mails are filed as spam on their side. And we just 
cannot figure out why. I promise we're not writing about 
enlargements or crypto scams. We use proper English (or German), and 
we know how to capitalise words.


Looking at messages being classified, there is nothing in the 
headers that gives any clues. In fact, the headers look just fine:


 Authentication-Results: mx.google.com; dkim=pass (test mode)
   header.i=@example.org header.s=2015-11-14 header.b=T7jbyqDv;
   spf=pass (google.com: best guess record for domain of
   madd...@example.org designates 2001:db8:bad::cafe:: as
   permitted sender) smtp.mailfrom=madd...@example.org;
   dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.org

What else can we do? How do you deal with this problem?

--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"for art to exist, for any sort of aesthetic activity or perception to
exist, a certain physiological precondition is indispensable:
intoxication."
 -- friedrich nietzsche

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: How to avoid being classified as spam by Google?

[Benny Pedersen]

martin f krafft skrev den 2019-10-06 18:36:


 Authentication-Results: mx.google.com; dkim=pass (test mode)
   header.i=@example.org header.s=2015-11-14 header.b=T7jbyqDv;
   spf=pass (google.com: best guess record for domain of
   madd...@example.org designates 2001:db8:bad::cafe:: as
   permitted sender) smtp.mailfrom=madd...@example.org;
   dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.org

What else can we do? How do you deal with this problem?


dkkim running in test mode ?, see if domain have t= in dns

just guesssing

Re: How to avoid being classified as spam by Google?

[Bill Cole]

On 6 Oct 2019, at 12:36, martin f krafft wrote:


Folks,

I hope this is not too off-topic, but I figure this is the best 
mailing list because we're probably not in this boat alone, wherein 
we're annoyed (very) and a bit helpless about Google. I have to ask 
here, because Google of course doesn't care about us.


The MailOp list is probably a better choice: 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Actual Google mail admins respond to such queries there. Really.

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)

Re: How to avoid being classified as spam by Google?

[Benny Pedersen]

Bill Cole skrev den 2019-10-06 18:50:


The MailOp list is probably a better choice:
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


NET::ERR_CERT_SYMANTEC_LEGACY


Actual Google mail admins respond to such queries there. Really.


if recipient keeps mails in spam folder how could google then classifiy 
it better ?

Re: How to avoid being classified as spam by Google?

[martin f krafft]

Quoting "Benny Pedersen", who wrote on 2019-10-06 at 18:44 Uhr +0200:

dkkim running in test mode ?, see if domain have t= in dns


Yes, on some domains it's still running in test mode. Is that enough 
reason for Google admins to flick us the finger?


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"god is a comedian playing to an audience too afraid to laugh."
-- voltaire

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: How to avoid being classified as spam by Google?

[martin f krafft]

Quoting "Bill Cole", who wrote on 2019-10-06 at 12:50 Uhr -0400:
The MailOp list is probably a better choice: 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Thanks! I didn't know about that. Will re-ask there. Sorry for the 
noise.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

"anyone who is capable of getting themselves made president
should on no account be allowed to do the job"
   -- douglas adams

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Re: How to avoid being classified as spam by Google?

[Benny Pedersen]

martin f krafft skrev den 2019-10-06 19:03:

Quoting "Bill Cole", who wrote on 2019-10-06 at 12:50 Uhr -0400:
The MailOp list is probably a better choice: 
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


Thanks! I didn't know about that. Will re-ask there. Sorry for the 
noise.


note NET::ERR_CERT_SYMANTEC_LEGACY

Re: Understanding master.cf

[Viktor Dukhovni]

On Sun, Oct 06, 2019 at 12:18:05PM +0200, Gerben Wierda wrote:

> Yes, it works with postfix when it can be read. It is a full letsencrypt 
> chain. 

I am puzzled as to why you're trying to set this as your "CAfile".
It is not a file containing trust anchors (root CAs).  And, unless
your SMTP server solicits client certificates, your smtpd(8) does
not need a CAfile at all.

Seems you're confusing "smtpd_tls_cert_file" with "smtpd_tls_CAfile".

> bash-3.2# openssl crl2pkcs7 -nocrl -certfile 
> /etc/letsencrypt/live/www.rna.nl/fullchain.pem | [...]
> Certificate:
> Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
> Subject: CN=www.rna.nl
> Certificate:
> Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
> Subject: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3

The "fullchain.pem" file is the one and *only* correct file to set
as your "smtpd_tls_cert_file".  You do not generally need an
"smtpd_tls_CAfile".  Your certificate will fail to verify in many
cases if you fail to include the intermediate CA cert(s) in the
fullchain.pem file.

> > No.  The SMTP server loads its CAfile before entering the chroot
> > jail (while still running as root).  There must be something wrong
> > with that file,
> 
> Indeed. It just wasn’t there. I need to make sure the _postfix user can
> read the files.

Actually, you don't.  The "smtpd_tls_cert_file" is loaded while
Postfix is running as root.

-- 
Viktor.

Re: How to avoid being classified as spam by Google?

[Jaroslaw Rafa]

Dnia  6.10.2019 o godz. 12:50:27 Bill Cole pisze:
> 
> The MailOp list is probably a better choice:
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

I have the very same issue as the OP, thanks for pointing to that list!
-- 
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: Only logging from a connection when an unrelated error is forced in main.cf

[Wietse Venema]

Gerben Wierda:
> For some reason, I don?t get smtpd logging at all. E.g. when sending a mail 
> from Apple Mail.app MUA, this is all I see:
> 
> Oct 06 22:42:21 mail postfix/cleanup[1020]: AE6C5504A6F: 
> message-id=<8f0db894-0b5a-407c-82fd-1cfb8ef77...@rna.nl>
> Oct 06 22:42:21 mail postfix/qmgr[350]: AE6C5504A6F: 
> from=, size=728, nrcpt=1 (queue active)
> Oct 06 22:42:21 mail postfix/qmgr[350]: AE6C5504A6F: removed

I note that the SMTP client logging is also missing.

Also, the smtpd process logs the "map open" error before the process
goes into the chroot jail and before it drops privileges.

Maybe the missing logging has to do with the time when the first
event is logged.

If it is chroot related, try turning off smtpd chroot in master.cf,
and do "postfix reload".

If chroot does not make the difference, try turning off smtpd
'unprivileged' in master.cf, and do "postfix reload".

I don't know why either of these could made a difference, but then
MacOS is not really UNIX.

Wietse

Re: How to avoid being classified as spam by Google?

[Wietse Venema]

martin f krafft:
>   Authentication-Results: mx.google.com; dkim=pass (test mode)
> header.i=@example.org header.s=2015-11-14 header.b=T7jbyqDv;
> spf=pass (google.com: best guess record for domain of
> madd...@example.org designates 2001:db8:bad::cafe:: as
> permitted sender) smtp.mailfrom=madd...@example.org;
> dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.org
> 
> What else can we do? How do you deal with this problem?

Perhaps the SMTP client IP address 2001:db8:bad::cafe:: has no PTR
record (or the name does not resolve to 2001:db8:bad::cafe::).

Wietse

Re: Only logging from a connection when an unrelated error is forced in main.cf

[Gerben Wierda]

> On 7 Oct 2019, at 01:10, Wietse Venema  wrote:
> 
> Gerben Wierda:
>> For some reason, I don?t get smtpd logging at all. E.g. when sending a mail 
>> from Apple Mail.app MUA, this is all I see:
>> 
>> Oct 06 22:42:21 mail postfix/cleanup[1020]: AE6C5504A6F: 
>> message-id=<8f0db894-0b5a-407c-82fd-1cfb8ef77...@rna.nl>
>> Oct 06 22:42:21 mail postfix/qmgr[350]: AE6C5504A6F: 
>> from=, size=728, nrcpt=1 (queue active)
>> Oct 06 22:42:21 mail postfix/qmgr[350]: AE6C5504A6F: removed
> 
> I note that the SMTP client logging is also missing.
> 
> Also, the smtpd process logs the "map open" error before the process
> goes into the chroot jail and before it drops privileges.

Aha.

> Maybe the missing logging has to do with the time when the first
> event is logged.
> 
> If it is chroot related, try turning off smtpd chroot in master.cf,
> and do "postfix reload”.

Indeed, it is. If I turn chroot from y to n, I get my logging.

Oct 07 01:26:20 mail postfix/master[18890]: daemon started -- version 3.4.6, 
configuration /opt/local/etc/postfix
Oct 07 01:26:38 mail submission/smtpd[18897]: connect from 
hermione.rna.nl[192.168.2.86]
Oct 07 01:26:38 mail submission/smtpd[18897]: 8D1F851E378: 
client=hermione.rna.nl[192.168.2.86]
Oct 07 01:26:38 mail postfix/cleanup[18901]: 8D1F851E378: 
message-id=<8c584332-f136-453f-b2c1-70c3d3c00...@rna.nl>
Oct 07 01:26:38 mail postfix/qmgr[18892]: 8D1F851E378: 
from=, size=683, nrcpt=1 (queue active)
Oct 07 01:26:38 mail postfix/qmgr[18892]: 8D1F851E378: removed
Oct 07 01:27:01 mail postfix/postscreen[18907]: cache 
btree:/opt/local/var/lib/postfix/postscreen_cache full cleanup: retained=0 
dropped=0 entries
Oct 07 01:27:01 mail postfix/postscreen[18907]: CONNECT from [127.0.0.1]:49401 
to [127.0.0.1]:25
Oct 07 01:27:01 mail postfix/postscreen[18907]: WHITELISTED [127.0.0.1]:49401
Oct 07 01:27:01 mail postfix/smtpd[18908]: connect from localhost[127.0.0.1]
Oct 07 01:27:14 mail postfix/smtpd[18908]: disconnect from localhost[127.0.0.1] 
quit=1 commands=1
Oct 07 01:27:38 mail submission/smtpd[18897]: disconnect from 
hermione.rna.nl[192.168.2.86] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 
commands=7

So, now the question becomes, how do I combine chroot smtpd/submission/smtp 
with postlog?

Strange though (for me at least), because I was under the impression that smtpd 
and friends were logging to postlog which is not running in a chroot jail so 
should be able to log everything and not just  qmgr and friends

Here is more from master.cf (now without chroot for smtpd and friends)

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 smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o syslog_name=submission

# smtps inet port 465 used to be mentioned here, but IANA has removed port
# 465 for 'SMTPS' in 2019. submission is now the only TLS-secured port

# postfix internals (to be found in /opt/local/var/spool/postfix/)
pickupunix  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  unix  n   -   n   300 1   qmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   y   -   -   smtp
relay unix  -   -   y   -   -   smtp
-o syslog_name=postfix/$service_name
showq unix  n   -   n   -   -   showq
error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   y   -   -   lmtp
anvil unix  -   -   n   -   1   anvil
scacheunix  -   -   n   -   1   scache
postlog   unix-dgram n  -   n   -   1   postlogd


G

> If chroot does not make the difference, try turning off smtpd
> 'unprivileged' in master.cf, and do "postfix reload".
> 
> I don't know why either of these could made a difference, but then
> MacOS is not really UNI

Is this a good smtpd restrictions set?

[Gerben Wierda]

I am revisiting my config and my config was made a long time ago (before 
relay_restrictions)

Would this be a good restrictions set? I think it is but I’m not 100% certain 
if this is efficient for instance. For instance, I am blocking 
reject_non_fqdn_recipient in  smtpd_recipient_restrictions without the 
permit_mynetworks and such first. Isn’t it then not more efficient to do that 
at the start of smtpd_relay_restrictions? And I also wonder if it isn’t better 
to remove permit_mynetworks from smtpd_relay_restrictions so that if a device 
has broken into my network (e.g. via Wifi), it cannot spam the world without 
authentication.

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access 
regexp:/opt/local/etc/postfix/rna_rbl_whitelist_clients,
reject_rbl_client zen.spamhaus.org,
permit
smtpd_helo_restrictions =
permit_mynetworks,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
permit
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_sender_domain
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unlisted_recipient
# with greylisting:
#smtpd_recipient_restrictions =
#   reject_non_fqdn_recipient,
#   reject_unlisted_recipient,
#   check_client_access 
regexp:/opt/local/etc/postfix/rna_policy_whitelist_clients,
#   check_sender_access 
regexp:/opt/local/etc//postfix/rna_policy_whitelist_senders,
#   check_policy_service unix:private/policy permit
smtpd_data_restrictions =
reject_unauth_pipelining,
permit_mynetworks,
permit_sasl_authenticated,
reject_multi_recipient_bounce


Gerben Wierda
Chess and the Art of Enterprise Architecture 
Mastering ArchiMate 
Architecture for Real Enterprises 
 at InfoWorld
On Slippery Ice  at EAPJ

Re: Only logging from a connection when an unrelated error is forced in main.cf

[Gerben Wierda]

And I forgot to mention, now that it isn’t running chroot-ed, the DNS reverse 
lookups suddenly also work.

Apparently, running chrooted is somewhat more difficult that imagined.

> Oct 07 01:26:20 mail postfix/master[18890]: daemon started -- version 3.4.6, 
> configuration /opt/local/etc/postfix
> Oct 07 01:26:38 mail submission/smtpd[18897]: connect from 
> hermione.rna.nl[192.168.2.86]
> Oct 07 01:26:38 mail submission/smtpd[18897]: 8D1F851E378: 
> client=hermione.rna.nl[192.168.2.86]
> Oct 07 01:26:38 mail postfix/cleanup[18901]: 8D1F851E378: 
> message-id=<8c584332-f136-453f-b2c1-70c3d3c00...@rna.nl>
> Oct 07 01:26:38 mail postfix/qmgr[18892]: 8D1F851E378: 
> from=, size=683, nrcpt=1 (queue active)
> Oct 07 01:26:38 mail postfix/qmgr[18892]: 8D1F851E378: removed
> Oct 07 01:27:01 mail postfix/postscreen[18907]: cache 
> btree:/opt/local/var/lib/postfix/postscreen_cache full cleanup: retained=0 
> dropped=0 entries
> Oct 07 01:27:01 mail postfix/postscreen[18907]: CONNECT from 
> [127.0.0.1]:49401 to [127.0.0.1]:25
> Oct 07 01:27:01 mail postfix/postscreen[18907]: WHITELISTED [127.0.0.1]:49401
> Oct 07 01:27:01 mail postfix/smtpd[18908]: connect from localhost[127.0.0.1]
> Oct 07 01:27:14 mail postfix/smtpd[18908]: disconnect from 
> localhost[127.0.0.1] quit=1 commands=1
> Oct 07 01:27:38 mail submission/smtpd[18897]: disconnect from 
> hermione.rna.nl[192.168.2.86] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 
> commands=7

Re: How to avoid being classified as spam by Google?

[martin f krafft]

Quoting "Wietse Venema", who wrote on 2019-10-06 at 19:13 Uhr -0400:
Perhaps the SMTP client IP address 2001:db8:bad::cafe:: has no PTR 
record (or the name does not resolve to 2001:db8:bad::cafe::).


Good point, but the address has a PTR record to a name with an  
record pointing to the address.


--
@martinkrafft | https://riot.im/app/#/room/#madduck:madduck.net

kermit: why are there so many songs about rainbows?
fozzy: that's part of what rainbows do.

spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)