[pfx] Re: [ext] list.sys4.de fails with starttls

[Jim Popovitch via Postfix-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2023-09-17 at 15:24 +0200, Herbert J. Skuhra via Postfix-users
wrote:
> On Fri, 17 Mar 2023 14:32:06 +0100, Ralf Hildebrandt via Postfix-users
> wrote:
> > 
> > * Benny Pedersen via Postfix-users :
> > > Mar 17 11:38:31 localhost postfix/smtpd[22150]: lost connection
> > > after STARTTLS from
> > > list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]
> > > Mar 17 12:09:10 localhost postfix/smtpd[23415]: lost connection
> > > after STARTTLS from
> > > list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]
> > > 
> > > maybe it works ?
> > 
> > I'll check. Which IP is that?
> 
> Since yesterday the same happens again.
> 
> Sep 17 15:08:36 mail postfix/smtpd[97630]: SSL_accept error from
> list.sys4.de[188.68.34.52]: lost connection
> Sep 17 15:08:36 mail postfix/smtpd[97630]: lost connection after
> STARTTLS from list.sys4.de[188.68.34.52]

I see the same on Debian Bullseye (oldstable) with Postfix v3.5.18


Sep 17 13:25:41 mx1.domainmail.net postfix/smtpd[2306]: connect from 
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]
Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: SSL_accept error from 
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]: lost connection
Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: lost connection after 
STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]
Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: disconnect from 
list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0] ehlo=1 starttls=0/1 
commands=1/2

Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: connect from 
list.sys4.de[188.68.34.52]
Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: SSL_accept error from 
list.sys4.de[188.68.34.52]: lost connection
Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: lost connection after 
STARTTLS from list.sys4.de[188.68.34.52]
Sep 17 13:25:42 mx1.domainmail.net postfix/smtpd[2306]: disconnect from 
list.sys4.de[188.68.34.52] ehlo=1 starttls=0/1 commands=1/2


- -Jim P.


-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAmUHA5gACgkQPcxbabkK
GJ활䀂围ꪁ刁⢬鱀牫㲒㤄쯖负��롏㤒�翻抍맍㌌⵫
A7mEj86oVv/N7kbDQTClxBkK6JrZD0ZokIsjX7holTVWQcHUOvD6Xq9jGlS6N5Je
toLI⸢楌韹쫕㱷쳍ࡆ陎勏忁᩽ᨾ野囸ိ㯅틕纤櫐
uJzℂ끫뙝嬀⒘܃윋㕲㧬噜祦⟺㏜ѹỜ餵퉵겣魀殦寶
K76tMzC8KtEE72rTeBnxMEuQfX/XUWVWmo7OPb0g3IbIvArxhi駧ꓳᨫ
gl0DyYyJA5x7vzGwn8wITzbQP9pszbYG3vNjL3FC2sCwLMW8KmvZ3PRGvAw/OrJ6
mG3mgbNdEO5JRllZHNVykzud3bwRO3A8k9T2OLDnvc4Dh2FrYMRY6UoJMHn479aA
GtnoKEZHX3TN70VQXuQcprMx6ohb2Yb1s2qv6mdDY9BZwj62d5HGXrrFTk3ZVxSB
k4zbPL7GfVnvDrsaLe8ptCvSwxlxOraVehuMm1gsuDxvU8lK6fsNdZ1MUdZhBx/c
G6Ua36Xe70StWx0lRx00FAw6xfpldnghSstHVOpGCChmzjOKwuhwZNoAstIZUX3d
w9k汚壍෻⢏郪뗑츏ΰ๜耿ⳍ㵙짡䑘㫮=
=kk38
-END PGP SIGNATURE-

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Anyone using SMTP relay through dnsexit.com?

[Jim Wright via Postfix-users]

On 6/23/23 17:13, Christian Kivalo via Postfix-users wrote:

Your lookup key is missing the [ ] you used for the relayhost setting. 
This results in no authentication to the dnsexit relay.
This is described in the section "Enabling SASL authentication in the 
Postfix SMTP/LMTP client" of the SASL README file at 
https://www.postfix.org/SASL_README.html#client_sasl_enable


You're correct, and that did fix it.  Their FAQ had it that way and I 
didn't question it.  Theirs was the only dns name I've used that had the 
brackets around it, so I didn't realize it was important in both 
places.  And after almost a week of talking this over with their support 
folks...  Guess I'll let them know how to fix their FAQ.


Many thanks!

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Anyone using SMTP relay through dnsexit.com?

[Jim Wright via Postfix-users]

Hey all.  Recently my ISP (Spectrum) decided (after this was working for 
me for almost 20 years) to make it impossible for a self hosted domain 
to relay through their SMTP server unless it was actually a spectrum.com 
email address being used.  After going back and forth with them to try 
to find a workaround, I had to give up and look elsewhere.  My next stop 
was with dnsexit.com.


Despite following their FAQ on postfix setup 
(http://www.dnsexit.com/support/mailrelay/postfix.html), I kept getting 
the dreaded 454, Relay access denied error message when attempting to 
send.  I verified all of my settings with their support but still 
couldn't relay through them, even though I had working settings 
previously for Spectrum (mail.twc.com).


Finally, I setup an account with smtp2go.com, jumped through their hoops 
to set up various cname records for my domain, and once that was done, I 
was able to relay a test email through them on the first try.  So, 
everything seemed to point to some issue with the dnsexit folks.


My question for the list is, is anyone here relaying via dnsexit.com, 
and if so, did you have similar issues that got resolved?  I'd rather 
use their service if possible as they are currently handling my dynamic DNS.


My settings

main.cf:
relayhost = [relay.dnsexit.com]:587
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =


And my sasl_passwd file (and yes, I did do a postmap after my changes)
relay.dnsexit.com:587 myusername:mypassword


And finally, what was logged here:

Jun 21 14:39:11 localhost postfix/smtp[191554]: 3F46E412E057: host 
relay.dnsexit.com[64.182.102.186] said: 454 4.7.1 : 
Relay access denied (in reply to RCPT TO command)
Jun 21 14:39:12 localhost postfix/smtp[191554]: 3F46E412E057: 
to=, relay=relay.dnsexit.com[64.182.102.185]:587, 
delay=78570, delays=78569/0.04/1.2/0.12, dsn=4.7.1, status=deferred 
(host relay.dnsexit.com[64.182.102.185] said: 454 4.7.1 
: Relay access denied (in reply to RCPT TO command))


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: [External] Re: Error when telnet testing, 1st cmd always fails

[Kinter, Jim via Postfix-users]

Thanks Wietse, you are correct.
I went into the putty config for that profile and unchecked a few things 
("Answer back to ^E" was set to PuTTy, Telnet Negotiation from Active to 
Passive, etc) and its working now. 

Thanks again.
Jim

-Original Message-
From: Wietse Venema via Postfix-users  
Sent: Tuesday, April 25, 2023 9:43 AM
To: Postfix users 
Subject: [External] [pfx] Re: Error when telnet testing, 1st cmd always fails

Caution: This is email originated from outside of the organization. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe.


Ue netcat (nc) instead of putty.

I suspsect that putty is sending telnet protocol options, even when it connets 
to a server on a non-telnet port. That would be a putty bug.

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an 
email to postfix-users-le...@postfix.org

This message may contain confidential information. If you are not the intended 
recipient, do not disseminate, distribute, or copy this e-mail or its 
attachments. Please notify the sender of the error immediately by e-mail or at 
the telephone number listed below, and delete this e-mail and any attachments 
from your system. Receipt by anyone other than the intended recipient(s) is not 
a waiver of any trade secrets, proprietary interests, or other applicable 
rights. E-mail transmission is not necessarily secure or error-free, as 
information could be intercepted, corrupted, lost, destroyed, delayed, 
incomplete, or may contain viruses. The sender disclaims all liability for any 
errors or omissions arising as a result of the e-mail transmission. 
 
OEConnection LLC, (888) 776-5792, www.oeconnection.com 
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Error when telnet testing, 1st cmd always fails

[Kinter, Jim via Postfix-users]

We have an issue with 2 postfix servers of the same vintage/version.

If I telnet port 25 to the server (Putty), it connects fine, then ANY command I 
send, be it helo, ehlo, or even just cr/lf (hit enter), I get:

502 5.5.2 Error: command not recognized

If I send the same command again, it then works fine from then on out:

ehlo localhost
250-dlmail.domain.local
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

Its always the 1st command after initial connection fails, any subsequent of 
that same connection works fine.

If I -vvv the log, I see (IPs and other sensitive data redacted):

Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: event_loop: read fd=6 
act=0x557650a49f60 0x6
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: event_cancel_timer: 0x557650a4a040 
0x0 45
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: connection established
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: master_notify: status 0
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: name_mask: resource
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: name_mask: software
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: connect from gateway[172.X.X.X]
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: match_list_match: gateway: no match
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: match_list_match: 172.X.X.X: no 
match
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: match_list_match: gateway: no match
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: match_list_match: 172.X.X.X: no 
match
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: smtp_stream_setup: maxtime=300 
enable_deadline=0
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: match_hostname: gateway ~? 172. 
X.X.X /32
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: match_hostaddr: 172. X.X.X ~? X.X.X 
/32
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: > gateway[172. X.X.X]: 220 
DLW011.domain.local ESMTP Postfix
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: watchdog_pat: 0x557652305720
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: vstream_fflush_some: fd 12 flush 40
Apr 25 09:29:04 DLW011 postfix/smtpd[5393]: vstream_buf_get_ready: fd 12 got 21
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: vstream_buf_get_ready: fd 12 got 16
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: < gateway[172. X.X.X]: ? 
?'?ehlo localhost
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: match_string: ? ~? CONNECT
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: match_string: ? ~? GET
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: match_string: ? ~? POST
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: match_list_match: ?: no match
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: > gateway[172. X.X.X]: 502 5.5.2 
Error: command not recognized
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: watchdog_pat: 0x557652305720
Apr 25 09:29:10 DLW011 postfix/smtpd[5393]: vstream_fflush_some: fd 12 flush 41

The 1st command is always prefaced with a bunch of question marks.
Subsequent commands of the same connection do not have all those question marks.

Anyone have a clue whats going on/what setting needs changed/whats busted?

Thanks
Jim

This message may contain confidential information. If you are not the intended 
recipient, do not disseminate, distribute, or copy this e-mail or its 
attachments. Please notify the sender of the error immediately by e-mail or at 
the telephone number listed below, and delete this e-mail and any attachments 
from your system. Receipt by anyone other than the intended recipient(s) is not 
a waiver of any trade secrets, proprietary interests, or other applicable 
rights. E-mail transmission is not necessarily secure or error-free, as 
information could be intercepted, corrupted, lost, destroyed, delayed, 
incomplete, or may contain viruses. The sender disclaims all liability for any 
errors or omissions arising as a result of the e-mail transmission. 
 
OEConnection LLC, (888) 776-5792, www.oeconnection.com 
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: www.postfix.org certificate expired

[Jim Popovitch via Postfix-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 2023-04-22 at 11:25 -0400, Viktor Dukhovni via Postfix-users
wrote:
> On Sat, Apr 22, 2023 at 01:08:06PM +0200, Matus UHLAR - fantomas via 
> Postfix-users wrote:
> 
> > > You should set a POST_HOOK in certbot renew (assuming you're using 
> > > certbot, that is) that restarts or reloads the web server.
> > 
> > I guess this exactly what failed.
> 
> The "post hooks" in certbot are not *reliable*.  If for some reason they
> don't succeed, they're retried on the next scheduled certbot run.  This
> is a design flaw.
> 

Yep. Just use renew_hook in /etc/letsencrypt/renewal/whatever.conf much
more reliable.

- -Jim P.

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEE3RmV4WutJ2KyCS2zPcxbabkKGJ8FAmREAuwACgkQPcxbabkK
GJ/58hAAtFiHlMghxVSQzhutl71EZh+PDD15NXnO19xN+V1PTm7NoXISsZKCjNLg
ueBL9O/DDJMRju+dWvfGLSTR4SqmEhLU/4zCkFFnLLyigZPGr5AcfEwkXCENg/PD
W+4h8Yi7iqRWYFvmMjwMFArsO0hmxxHdLyQWN4RTF0Cw7fLM6pXFY+kJ4SQdQakq
x2l1XfHwXu4p4Pay99r+SNk6lURaId2PqgEzzgX9w4feS0ZTH+rYhFFtMH9bOqAn
Ks4yBNcufw1WbsZjNiI1P5Y89ImznIZibv7svcY9e138Tj/XS6CDDyIgeJ7yH+rQ
7DNdOvs6FCx0EqJNhPNtjOTKqImyXKsaYZmDZJCZ46Nxoa1JoMcQloYxFGrUzzaD
iRQCWfjne9X19VLRGhDN29Oa6e3+oW4CmjNnIF0Pmek8trrxllDN/6tM0sXs/eGb
49sZcmvyrjUfSQecz8v/k/9UpwfTvmfcfZilWIfDwtCm6/tjYvDiBzcl/9ulu/+W
2HpvrDfTBmTWKE039hhvAt23cB+5BhVbgnmKmaEhZC1qRjT2B2ezakMJCpEHFcrR
7L44n28+ZLeO6ZUXc5JeKGcQaI8IMs9+2ED4iWNU/Jcl1UCnAtxQeSfBs8i3FlkP
wSfuQ4MzXVo/R6pkrLqtttQd+JeKcdw3sQkh5BVVSaKOSxlepJI=
=Fgza
-END PGP SIGNATURE-

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: [P-U] Re: Postfix lists are migrating to a new list server

[Jim Popovitch via Postfix-users]

On Fri, 2023-03-10 at 17:35 +0200, mailmary--- via Postfix-users wrote:
> 
> Looking at the opendkim/opendmarc right now, they appear dead over the past 2 
> years or so, which is sad really. 
> 

It's not sad at all.  It's a testament to the stability of the project.
Sure, both projects could use some polishing maybe, but that is not
something that is "sad"

-Jim P.

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

postconf manpage suggestion

[Jim Garrison]

Under the `-n` option, the man page currently says

To show settings that differ from built-in  defaults  only,
use the following bash syntax:
comm -23 <(postconf -n) <(postconf -d)
Replace "-23" with "-12" to show settings that duplicate built-in
defaults.

Curiously, with the typical LANG=en_US.UTF-8, this complains that the
inputs are not sorted.  It fails at the transition from smtp to smtpd
lines:

smtp_[whatever]
smtpd_[whatever]

because, apparently, the highly complex Unicode collation rules modify
how the underscore character (0x5f) is treated.  I couldn't find a
reference explaining exactly why, but it seems to be related to
"variable collation elements".  Adding LC_ALL=C to the front of the
comm command cures the problem.

So I'd like to suggest that the manpage either add the LC_ALL=C prefix
or include a warning about the possible issue under Unicode locales.

--
Jim Garrison
j...@acm.org

Re: Restrict access relay to single client

[Jim Garrison]

On 12/23/22 19:06, raf wrote:

On Fri, Dec 23, 2022 at 01:14:26PM -0800, Jim Garrison  wrote:

[snip]

Not relevant to your problem, but the above says that
only ipv4 is used but your config includes ipv6
addresses. You might want to delete it (and default to
"all"), or remove the ipv6 addresses from your config.

Good point, I'm in an IPV4-only network.

[snip]

smtpd_relay_restrictions = permit_mynetworks reject_unauth_destination


This is the problem. You need to add "reject" to the
end of smtpd_relay_restrictions. Without it, it
implicitly ends with "permit".
In http://www.postfix.org/SMTPD_ACCESS_README.html),
it says:

   Each restriction list is evaluated from left to right
   until some restriction produces a result of PERMIT,
   REJECT or DEFER (try again later). The end of each
   list is equivalent to a PERMIT result.

I recommend always having "permit" or "reject" at the
end of all smtpd_*_restrictions parameters. Even if
it's just to make the implicit "permit" explicit and
visible.


Got it, this is what I somehow missed.

[snip]

Thanks, it's now working the way I want, and I learned something :-)

--
Jim Garrison
j...@acm.org

Re: Restrict access relay to single client

[Jim Garrison]

On 12/23/22 17:24, Wietse Venema wrote:

You should also include "postconf -P" for parameter settings in
master.cf.

Wietse


Not much there...

$ postconf -P
relay/unix/syslog_name = postfix/$service_name

--
Jim Garrison
j...@acm.org

Restrict access relay to single client

[Jim Garrison]

I have Postfix running inside a private LAN as an outgoing relay via
GMail (no incoming Internet connections).  I have two goals

1. Relay only to one specific domain
2. Accept relay from only one specific LAN client

So I configured the following (complete postconf -n appended below):

myhostname = host.internal.lan
mynetworks = 192.168.0.105
 127.0.0.0/8
 [:::127.0.0.0]/104
 [::1]/128
relay_domains = mydomain.com
relayhost = [smtp.gmail.com]:587
smtpd_relay_restrictions = permit_mynetworks
   reject_unauth_destination

This works for the first objective, and blocks relaying to any address
not in mydomain.com.

Dec 23 12:21:16 janus postfix/smtpd[9974]: connect from 
unknown[192.168.0.175]
Dec 23 12:22:10 janus postfix/smtpd[9974]: NOQUEUE: reject: RCPT 
from unknown[192.168.0.175]: 554 5.7.1 : Relay access denied; 
from= to= proto=SMTP 
helo=



I was also expecting the $mynetworks setting to allow relaying from
only that one specific host (.105) (as well as the local system) while
blocking relaying from any other LAN host.

What I actually see is that any host on the LAN is allowed to relay (I
tested from 192.168.0.175).  Here are the log entries:

Dec 23 12:24:01 janus postfix/smtpd[9974]: CC31BC0281: 
client=unknown[192.168.0.175]

Dec 23 12:24:17 janus postfix/cleanup[9984]: CC31BC0281: message-id=<>
Dec 23 12:24:17 janus postfix/qmgr[9910]: CC31BC0281: 
from=, size=225, nrcpt=1 (queue active)
Dec 23 12:24:18 janus postfix/relay/smtp[9992]: CC31BC0281: 
to=, relay=smtp.gmail.com[142.251.116.109]:587, 
delay=22, delays=21/0.03/0.69/0.53, dsn=2.0.0, status=sent (250 2.0.0 OK 
 1671827058 l14-20020a056870f14e00b0014b8347e1e3sm1987913oac.12 - gsmtp)

Dec 23 12:24:18 janus postfix/qmgr[9910]: CC31BC0281: removed


I've studied the excellent documentation thoroughly, and even found
several how-to's on the web saying this is the way to restrict relaying
to a specific client.

What have I missed?

postconf -n output (slightly redacted):

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
mydestination = $myhostname, host, localhost.internal.lan, localhost
myhostname = host.internal.lan
mynetworks = 192.168.0.105 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = $myhostname
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = mydomain.com
relayhost = [smtp.gmail.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options =
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks reject_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

Re: Send email to one @domain.com via authenticated relay?

[Jim Popovitch]

On Sat, 2022-12-03 at 10:37 -0500, John Stoffel wrote:
> > > > > > "Jim" == Jim Popovitch  writes:
> 
> > On Fri, 2022-12-02 at 11:36 -0500, John Stoffel wrote:
> > I check, but I find my IP for mail.stoffel.org in the UCEPROTECT-3 
> > spam list.  Nothing I can do about it. 
> 
> 
> > I doubt that many sites block by using UCEPROTECH-3 alone, but you
> > can 
> > use www.whitelisted.org to be excluded from it.
> 
> I'm not going to pay those scum to get my IP whitelisted, that's just
> blackmail.  How does paying some extortionate third party make my
> email problems go away?  
> 

That's cool and all, I was just offering you advice on how you can be
excluded from the UCEPROTECT-3 listing.  That is all.

I am subscribed to the postfix-users@postfix.org mailinglist, no need to
also email me a copy of your posts.

-Jim P.

Re: Send email to one @domain.com via authenticated relay?

[Jim Popovitch]

On Fri, 2022-12-02 at 11:36 -0500, John Stoffel wrote:
I check, but I find my IP for mail.stoffel.org in the UCEPROTECT-3 
spam list.  Nothing I can do about it. 


I doubt that many sites block by using UCEPROTECH-3 alone, but you can 
use www.whitelisted.org to be excluded from it.


-Jim P.

Re: Save all emails in transit, including envelope data

[Jim Popovitch]

On Tue, 2022-09-06 at 12:07 -0400, Wietse Venema wrote:
> Jim Popovitch:
> > On Tue, 2022-09-06 at 09:25 -0400, Viktor Dukhovni wrote:
> > > On Tue, Sep 06, 2022 at 06:35:05AM -0400, Wietse Venema wrote:
> > > 
> > > > > Any suggestion?
> > > > 
> > > > /etc/postfix/main.cf:
> > > > recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc.pcre
> > > > 
> > > > /etc/postfix/recipient_bcc.pcre:
> > > > (.+)@(+)$1%$2@backup.example
> > > 
> > > Nit:
> > > 
> > > /(.+)@(.+)/   $1%$2@backup.example
> > 
> > What are my options for sending that to a file instead of a destination
> > address?  I want to temporarily store a copy of all bounce emails for a
> > mailinglist to debug a bounce processing problem. 
> 
> Proper mail systems will return undeliverable messages to the mailing
> list's bounce address. Just like any other email, you can receive
> those messages in a mailbox file or in a maildir structure.

Right, right.  What I want to do is add the recipient_bcc_maps that you
suggested earlier, and modify it to match the bounce address, and then
dump that to a file for future examination the next time the mailing
list's bound processing doesn't function as it should. 

-Jim P.

Re: Save all emails in transit, including envelope data

[Jim Popovitch]

On Tue, 2022-09-06 at 09:25 -0400, Viktor Dukhovni wrote:
> On Tue, Sep 06, 2022 at 06:35:05AM -0400, Wietse Venema wrote:
> 
> > > Any suggestion?
> > 
> > /etc/postfix/main.cf:
> > recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc.pcre
> > 
> > /etc/postfix/recipient_bcc.pcre:
> > (.+)@(+)$1%$2@backup.example
> 
> Nit:
> 
> /(.+)@(.+)/   $1%$2@backup.example
> 

What are my options for sending that to a file instead of a destination
address?  I want to temporarily store a copy of all bounce emails for a
mailinglist to debug a bounce processing problem. 

tia,

-Jim P.

fail2ban filter for spurious connections?

[Jim Garrison]

This is a question about Postfix, in relation to fail2ban.

Having recently upgraded to the current Postfix from an ancient version,
I notice the "disconnect from" log entries now include a summary of
commands received and successfully completed.

I am also seeing lots of password probe attempts that look similar to:

disconnect from unknown[104.148.78.224] ehlo=1 mail=1 rcpt=0/1 
quit=1 commands=3/4


It occurs to me that this provides a really convenient way to identify
hosts sending password probe attempts by adding a filter that looks for 
the regex:


disconnect.*commands=[0123]

This would trigger on any SMTP session that disconnected before
processing a valid RCPT command. With a suitable maxretry setting (say
5) this would stop most probes.

The Postfix question: Is there a reason this is a bad idea, and could it
cause legitimate MTAs to be banned?

--
Jim Garrison
j...@acm.org

Re: warning: unknown[137.xxx.xxx.253]: SASL LOGIN authentication failed: UGFzc3dvcmQ6

[Jim Garrison]

On 6/6/2022 3:13 AM, Jaroslaw Rafa wrote:

Dnia  5.06.2022 o godz. 23:29:05 julio covolato pisze:


I would like to know why these messages appear in the mail.log,
I know that "UGFzc3dvcmQ6" is base64 encoded for "Password:".
Is this some misconfigured internet mail server system (Windows)?


Rather not a misconfigured server, but some stupid bot trying to guess
passwords. It is a comonly observed thing.


Blocking these IPs with fail2ban is a good idea?


Probably yes.


I recently saw this when I rebuilt a Postfix server and forgot to
update a client's password when it changed on the server.

It seems the error message always contains the base64 encoding of
"Password:" regardless of the actual userid/password.

Anybody know why the error message displays this (base64 encoded)?

--
Jim Garrison
j...@acm.org

Re: Postfix+SASL chrooted - out of ideas

[Jim Garrison]

On 5/28/2022 7:07 PM, Viktor Dukhovni wrote:

On Sat, May 28, 2022 at 05:11:22PM -0700, Jim Garrison wrote:


Foreground saslauthd command, including debug output from
successful testsaslauthd but no log entries corresponding to the
immediately above extract from the Postfix log:

$ sudo saslauthd -a pam -d -c -m /var/spool/postfix/var/run/saslauthd


Why are you using the above "-m" option?  The SASL library is going to
look in "/var/run/saslauthd/mux", which corresponds to the default "-m
/var/run/saslauthd".  Unless the Postfix smtpd(8) process is chrooted,
the default value is the only one that'll work.

If you want to make saslauthd chroot-agnostic, make /var/run/saslauthd a
symlink to /var/spool/postfix/var/run/saslauthd.  But simpler to just
not bother with chroot.

Well, since I was making no progress with cyrus SASL I decided to
switch to Dovecot following the Postfix SASL howto, and it worked
first time.

Viktor et al, thank you for your assistance.  I've spent way too much
time on this, and should have just switched to dovecot auth at the
start.  I foolishly assumed since I had it working on the ancient
system it would be at least as easy on a modern system.

The documentation tweak I'd recommend is to more strongly steer users
towards using dovecot auth instead of cyrus SASL.  This is based on my
own experience plus reading the many posts from others, in various
forums, who were also having trouble with Cyrus SASL.

While I hate using cookbook solutions (where I cannot abstract the
intuitive understanding of what's going on under the covers), in this
case it'll have to do.  I just don't have the time or inclination to
become an expert in the architecture, design and implementation of
either Cyrus SASL or Dovecot. (sigh! so much to learn, so little time)

One possible suggestion for Postfix: Since it appears Postfix was
never able to even establish contact with Cyrus SASL, it might be nice
to detect that condition and provide a different error message than
just "authentication failed", to help with troubleshooting.  I
also appreciate that that might actually require a change in libsasl
and not Postfix.

Thanks again

--
Jim Garrison
j...@acm.org

Re: Postfix+SASL chrooted - out of ideas

[Jim Garrison]

slauthd.pid.lock

$ grep postfix /etc/group
sasl:x:45:postfix
postfix:x:117:

Is there an option to increase the debug level in Postfix's
interaction with saslauthd?


--
Jim Garrison
j...@acm.org

Postfix+SASL chrooted - out of ideas

[Jim Garrison]

I'm migrating from an ancient Postfix 2.6.6 with SASL 2.1.23 on Centos
6 to 3.5.6 with SASL 2.1.27 on Debian 11.  I've got everything working
EXCEPT SASL authentication, and the amount of conflicting information
on Postfix+SASL on the web is rather amazing :-).

I tried reading the Cyrus SASL manual, but it seems to be incomplete,
with lots of headings with no text.

I have authentication working just fine on my old system (for years),
but I'm stumped on the new system after about 10 hours of
experimentation. Here's the current setup (sensitive info redacted):

$sudo sasldblistusers2
myu...@mydomain.com: userPassword

$ sudo testsaslauthd -r mydomain.com -u myuser -p [password]
0: OK "Success."

So I know SASL itself is working, but in case it's relevant:

$ sudo db_dump -p /etc/sasldb2
VERSION=3
format=print
type=hash
h_nelem=2
db_pagesize=4096
HEADER=END
 myuser\00mydomain.com\00userPassword
 [password]
DATA=END

$cat /etc/sasl2/smtpd.conf
pwcheck_method: auxprop
log_level: 4
mech_list: PLAIN

$ sudo postconf -a
cyrus
dovecot

$ sudo postconf |egrep '^smtpd_(sasl|relay)'
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated 
reject_unauth_destination

smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = no
smtpd_sasl_exceptions_networks =
smtpd_sasl_local_domain =
smtpd_sasl_path = smtpd
smtpd_sasl_response_limit = 12288
smtpd_sasl_security_options = noanonymous
smtpd_sasl_service = smtpd
smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
smtpd_sasl_type = cyrus


Since the Debian default is to run Postfix chroot, I applied the fix
suggested to make the SASL socket available to Postfix (OPTIONS below)

$ cat /etc/default/saslauthd
START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="sasldb"
MECH_OPTIONS=""
THREADS=5
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

$ groups postfix
postfix : postfix sasl

$ ls -ld /var/spool/postfix
drwxr-xr-x 21 root root 4096 May 27 21:42 /var/spool/postfix

$ ls -ld /var/spool/postfix/var
drwxr-xr-x 3 root root 4096 May 27 21:42 /var/spool/postfix/var

$ ls -ld /var/spool/postfix/var/run
drwxr-xr-x 3 root root 4096 May 27 21:42 /var/spool/postfix/var/run

$ ls -ld /var/spool/postfix/var/run/saslauthd/
drwx--x--- 2 root sasl 4096 May 28 00:41 
/var/spool/postfix/var/run/saslauthd/


$ sudo ls -l /var/spool/postfix/var/run/saslauthd/mux
srwxrwxrwx 1 root root 0 May 28 00:41 
/var/spool/postfix/var/run/saslauthd/mux


Thunderbird client configuration (same as working config that connects
to the old system, except for the hostname).

Host: hostname of the new server
Port: 587
User: myu...@mydomain.com
Auth: Normal Password
Sec:  STARTTLS

The consistent error is (/var/log/mail.log)

May 28 00:50:34 smtp2 postfix/submission/smtpd[19147]: connect from 
[redacted]
May 28 00:50:35 smtp2 postfix/submission/smtpd[19147]: warning: SASL 
authentication failure: Password verification failed
May 28 00:50:35 smtp2 postfix/submission/smtpd[19147]: warning: 
[redacted]: SASL PLAIN authentication failed: authentication failure


There is nothing logged in auth.log, and journalctl does not show
anything for saslauthd except daemon start and stop messages.

So I'm out of ideas.  What can I do to resolve the problem or
troubleshoot further?


I also tried manually connecting, here's the results of that session:

$ echo -ne '\000myu...@mydomain.com\000[password]' | openssl base64
[redacted base64]

$ openssl s_client -connect localhost:587 -starttls smtp
CONNECTED(0003)

[certificate data]

---
SSL handshake has read 4810 bytes and written 396 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
---
[session ticket]
---
read R BLOCK
EHLO test.com
250-[redacted]
250-PIPELINING
250-SIZE 1024
250-VRFY
250-ETRN
250-AUTH DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
AUTH PLAIN [redacted base64]
535 5.7.8 Error: authentication failed: bad protocol / cancel
QUIT
DONE

--
Jim Garrison
j...@acm.org

Re: Migrate mbox from 2.6.6 to 3.5.6

[Jim Garrison]

On 5/20/2022 6:14 AM, Viktor Dukhovni wrote:

On 20 May 2022, at 9:09 am, Rob McGee  wrote:

It's also perhaps worth mentioning that Postfix has nothing to to with
mail once it has been delivered. This question should have been sent
to a mailing list for the unstated IMAP server.


This is almost true.  The main caveat is that either the old or new Postfix
is up and running, it is not safe to copy mbox files, as mail may be lost,
and messages at the tail of the file may be corrupted.

Transfer of mailboxes must take place between idle systems where Postfix is
not running on either end.

Otherwise, indeed the mbox file format hasn't changed in decades.



Thanks to all who have responded.  I'll be performing the cutover
later this weekend.

--
Jim Garrison
j...@acm.org

Migrate mbox from 2.6.6 to 3.5.6

[Jim Garrison]

I am migrating an ancient mail server running 2.6.6 to a new host
running postfix 3.5.6.  This is a simple setup with just a handful of
users and no complications like virtual mailboxes.

Simple question: Is it as easy as copying the /var/spool/mail/[user]
file and ~/mail directory to the new host for each user?  I.e. is the
mbox format used still the same, or will I run into incompatibilities?

If a conversion or format upgrade is necessary, what is involved?

Thanks

--
Jim Garrison
j...@acm.org

if/endif header_check

[Jim Popovitch]

Hello!

I'm trying to get a complex header_check to work, and unfortunately it
isn't. :(  I started in #postfix and figured I would follow up here too.

The goal is to put mail on HOLD if it is not spam and is destined for 2
role accounts.  Any help is much appreciated.


~$ cat header_checks.pcre
if /^X-Spam-Status: No/
/^To:.*admin@/  HOLD
/^To:.*owner@/  HOLD
endif


~$ postmap -vhmq - pcre:header_checks.pcre < test.eml 
postmap: name_mask: ipv4
postmap: name_mask: ipv6
postmap: inet_addr_local: configured 2 IPv4 addresses
postmap: inet_addr_local: configured 3 IPv6 addresses
postmap: dict_open: pcre:header_checks.pcre
postmap: dict_pcre_lookup: header_checks.pcre: Return-Path: 

postmap: dict_pcre_lookup: header_checks.pcre: Message-ID: 

postmap: dict_pcre_lookup: header_checks.pcre: Date: Tue, 18 Jan 2022 00:23:06 
+0900
postmap: dict_pcre_lookup: header_checks.pcre: From: Nobody 

postmap: dict_pcre_lookup: header_checks.pcre: Mime-Version: 1.0
postmap: dict_pcre_lookup: header_checks.pcre: To: Test Admin 
postmap: dict_pcre_lookup: header_checks.pcre: Subject: BEST TEST for the BEST 
TEST Admin
postmap: header_token: multipart / alternative
postmap: header_token: boundary = ===1daff0b5e974181ee018f94c==
postmap: PUSH boundary ===1daff0b5e974181ee018f94c==
postmap: dict_pcre_lookup: header_checks.pcre: Content-Type: 
multipart/alternative;? boundary="===1daff0b5e974181ee018f94c=="
postmap: dict_pcre_lookup: header_checks.pcre: X-Virus-Scanned: clamav-milter 
0.103.3 at mx1.domainmail.net
postmap: dict_pcre_lookup: header_checks.pcre: X-Virus-Status: Clean
postmap: dict_pcre_lookup: header_checks.pcre: X-Spam-Status: No, score=3.0 
required=5.0 tests=HTML_FONT_LOW_CONTRAST,?
HTML_MESSAGE,MIME_QP_LONG_LINE,URIBL_ABUSE_SURBL,URIBL_SBL_A?
shortcircuit=no autolearn=disabled version=3.4.6
postmap: dict_pcre_lookup: header_checks.pcre: X-Spam-Level: ***
postmap: dict_pcre_lookup: header_checks.pcre: X-Spam-Checker-Version: 
SpamAssassin 3.4.6 (2021-04-09) on? mx1.domainmail.net
postmap: POP boundary ===1daff0b5e974181ee018f94c==



~$ cat test.eml
eturn-Path: 
Message-ID: 
Date: Tue, 18 Jan 2022 00:23:06 +0900
From: Nobody 
Mime-Version: 1.0
To: Test Admin 
Subject: BEST TEST for the BEST TEST Admin
Content-Type: multipart/alternative;
 boundary="===1daff0b5e974181ee018f94c=="
X-Virus-Scanned: clamav-milter 0.103.3 at mx1.domainmail.net
X-Virus-Status: Clean
X-Spam-Status: No, score=3.0 required=5.0 tests=HTML_FONT_LOW_CONTRAST,
HTML_MESSAGE,MIME_QP_LONG_LINE,URIBL_ABUSE_SURBL,URIBL_SBL_A
shortcircuit=no autolearn=disabled version=3.4.6
X-Spam-Level: ***
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 mx1.domainmail.net

This is a test message

Re: postconf -d smtpd_relay_restrictions

[Jim Popovitch]

On Thu, 2022-01-06 at 12:23 -0500, Wietse Venema wrote:
> Jim Popovitch:
> > This config produces the warning/error message:
> > 
> > mail_version = 3.6.3
> > smtpd_relay_restrictions = ${{$compatibility_level}  > {permit_mynetworks, permit_sasl_authenticated,
> > defer_unauth_destination}}
> > smtpd_recipient_restrictions = check_client_access
> > cidr:/etc/postfix/check_client_access.cidr, reject_non_fqdn_sender,
> > reject_non_fqdn_recipient, reject_unknown_recipient_domain,
> > check_sender_access pcre:/etc/postfix/check_senders.pcre,
> > check_recipient_access pcre:/etc/postfix/check_recipients.pcre,
> > permit_auth_destination
> > compatibility_level = 0
> 
> Above, smtpd_relay_restrictions will be empty. This setting is
> backwards compatible with Postfix versions that did not have
> smtpd_relay_restrictions.
> 
> This triggers the error because smtpd_recipient_restrictions does
> not contain any of the features that are considered 'required'.
> 
>   ... specify at least one working
>   instance of: reject_unauth_destination, defer_unauth_destination,
>   reject, defer, defer_if_permit or check_relay_domains
> 
> > This config works, and does not produce the warning/error message:
> > 
> > mail_version = 3.6.3
> > smtpd_relay_restrictions = ${{$compatibility_level}  > {permit_mynetworks, permit_sasl_authenticated,
> > defer_unauth_destination}}
> > smtpd_recipient_restrictions = check_client_access
> > cidr:/etc/postfix/check_client_access.cidr, reject_non_fqdn_sender,
> > reject_non_fqdn_recipient, reject_unknown_recipient_domain,
> > check_sender_access pcre:/etc/postfix/check_senders.pcre,
> > check_recipient_access pcre:/etc/postfix/check_recipients.pcre,
> > permit_auth_destination
> > compatibility_level = 3.6
> 
> Above, smtpd_relay_restrictions is non-empty (permit_mynetworks,
> permit_sasl_authenticated, defer_unauth_destination), and
> defer_unauth_destination is one of the features that are considered
> 'required'.
> 
> Mystery solved.

Correct. I ack'ed that yesterday in my response to Viktor.  Thanks for
confirming/validating this Wietse.

-Jim P.

Re: postconf -d smtpd_relay_restrictions

[Jim Popovitch]

On Thu, 2022-01-06 at 11:32 -0500, Wietse Venema wrote:
> Jim Popovitch:
> > On Thu, 2022-01-06 at 22:29 +1100, Viktor Dukhovni wrote:
> > > 
> > > 
> > > Removing the compatibility_level setting entirely could introduce
> > > the reported symptoms, if "smtpd_recipient_restrictions" doesn't
> > > have any of the "default deny" rules, and relies on the relay
> > > restrictions to prevent relay abuse.
> > 
> > That's interesting.
> > 
> > Testing this AM...
> > 
> > Setting compatibility_level=2 doesn't reproduce the error message.
> > 
> > Removing the compatibility_level entirely does reintroduce the error
> > message (once per every inbound connection):
> > 
> >   fatal: in parameter smtpd_relay_restrictions or
> >  smtpd_recipient_restrictions, specify at least one working
> >  instance of: reject_unauth_destination, defer_unauth_destination,
> >  reject, defer, defer_if_permit or check_relay_domains
> > 
> > The message is accurate as I do not have any instance of those settings
> > in smtpd_recipient_restrictions, however I do have
> > permit_auth_destination set.
> 
> Could we have all the neccary info to reproduce this in one email message?
> 
> For both compatibility level settings:
> 
> postconf mail_version smtpd_relay_restrictions smtpd_recipient_restrictions 
> compatibility_level
> 
>   Wietse

This config produces the warning/error message:

mail_version = 3.6.3
smtpd_relay_restrictions = ${{$compatibility_level} 

Re: postconf -d smtpd_relay_restrictions

[Jim Popovitch]

On Thu, 2022-01-06 at 22:29 +1100, Viktor Dukhovni wrote:
> 
> 
> Removing the compatibility_level setting entirely could introduce
> the reported symptoms, if "smtpd_recipient_restrictions" doesn't
> have any of the "default deny" rules, and relies on the relay
> restrictions to prevent relay abuse.

That's interesting.

Testing this AM...

Setting compatibility_level=2 doesn't reproduce the error message.

Removing the compatibility_level entirely does reintroduce the error
message (once per every inbound connection):

  fatal: in parameter smtpd_relay_restrictions or
 smtpd_recipient_restrictions, specify at least one working
 instance of: reject_unauth_destination, defer_unauth_destination,
 reject, defer, defer_if_permit or check_relay_domains

The message is accurate as I do not have any instance of those settings
in smtpd_recipient_restrictions, however I do have
permit_auth_destination set.

-Jim P.

Re: postconf -d smtpd_relay_restrictions

[Jim Popovitch]

On Thu, 2022-01-06 at 00:11 +0100, John Fawcett wrote:
> On 05/01/2022 21:21, Jim Popovitch wrote:
> > On Wed, 2022-01-05 at 20:45 +0100, John Fawcett wrote:
> > > On 05/01/2022 20:19, Jim Popovitch wrote:
> > > > This can't be right
> > > > 
> > > > Using 'postconf -d smtpd_relay_restrictions'...
> > > > 
> > > > ...on postfix v3.5 (Debian/Buster)
> > > > smtpd_relay_restrictions = ${{$compatibility_level} < {1} ? {} :
> > > > {permit_mynetworks, permit_sasl_authenticated,
> > > > defer_unauth_destination}}
> > > > 
> > > > ...on postfix v3.6.3 (Debian/Bookworm)
> > > > smtpd_relay_restrictions = ${{$compatibility_level}  > > > {permit_mynetworks, permit_sasl_authenticated,
> > > > defer_unauth_destination}}
> > > > 
> > > > 
> > > > Notice the extra word 'level' just to the right of the less-than symbol.
> > > > 
> > > > -Jim P.
> > > > 
> > > Hi Jim
> > > 
> > > Using the github "blame" feature on file global/mail_params.h it was
> > > easy to track down when this was introduced:
> > > 
> > > postfix-3.6-20210109
> > > 
> > >   From the history file:
> > > 
> > > 20210102
> > > 
> > >   Infrastructure: support for the <=level,  > >   operators to compare compatibility levels. With the standard
> > >   <=, <, etc. operators, compatibility level 3.10 would be
> > >   less than 3.9 which is undesirable. Files: global/compat_level.[hc]
> > >   and test files.
> > > 
> > > John
> > > 
> > Hi John, Thanks for the quick response and details.  When I upgraded the
> > system to postfix v3.6 it complained with the following error, however
> > it has since resolved itself once I set compatibility_level=3.6.
> > 
> > postfix/smtpd[3751]: fatal: in parameter smtpd_relay_restrictions or
> > smtpd_recipient_restrictions, specify at least one working instance of:
> > reject_unauth_destination, defer_unauth_destination, reject, defer,
> > defer_if_permit or check_relay_domains
> > 
> > -Jim P.
> > 
> > 
> Jim
> 
> had you previously set a compatibility_level in version 3.5 or left it 
> at the default? Was the compatibility_level the same when you got the 
> above fatal message in version 3.6? Did you make changes to 
> smtpd_recipient_restrictions between version 3.5 and 3.6
> 
> The logic behind that fatal message is that you can have an empty 
> smtpd_relay_restrictions (like you would get if you left defaults for 
> smtpd_relay_restrictions and compatibility_level) but in that case you 
> have to have one of the required restrictions in 
> smtpd_recipient_restrictions.
> 
> I don't see changes in that logic between version 3.5 and 3.6.


I did have compatibility_level=2 set when I got that error.  I removed
that setting completely, but the error didn't go away until I
specifically set it to 3.6 (IIRC).

-Jim P.

Re: postconf -d smtpd_relay_restrictions

[Jim Popovitch]

On Wed, 2022-01-05 at 20:45 +0100, John Fawcett wrote:
> On 05/01/2022 20:19, Jim Popovitch wrote:
> > This can't be right
> > 
> > Using 'postconf -d smtpd_relay_restrictions'...
> > 
> > ...on postfix v3.5 (Debian/Buster)
> > smtpd_relay_restrictions = ${{$compatibility_level} < {1} ? {} :
> > {permit_mynetworks, permit_sasl_authenticated,
> > defer_unauth_destination}}
> > 
> > ...on postfix v3.6.3 (Debian/Bookworm)
> > smtpd_relay_restrictions = ${{$compatibility_level}  > {permit_mynetworks, permit_sasl_authenticated,
> > defer_unauth_destination}}
> > 
> > 
> > Notice the extra word 'level' just to the right of the less-than symbol.
> > 
> > -Jim P.
> > 
> Hi Jim
> 
> Using the github "blame" feature on file global/mail_params.h it was 
> easy to track down when this was introduced:
> 
> postfix-3.6-20210109
> 
>  From the history file:
> 
> 20210102
> 
>      Infrastructure: support for the <=level,       operators to compare compatibility levels. With the standard
>      <=, <, etc. operators, compatibility level 3.10 would be
>      less than 3.9 which is undesirable. Files: global/compat_level.[hc]
>      and test files.
> 
> John
> 

Hi John, Thanks for the quick response and details.  When I upgraded the
system to postfix v3.6 it complained with the following error, however
it has since resolved itself once I set compatibility_level=3.6.

postfix/smtpd[3751]: fatal: in parameter smtpd_relay_restrictions or
smtpd_recipient_restrictions, specify at least one working instance of:
reject_unauth_destination, defer_unauth_destination, reject, defer,
defer_if_permit or check_relay_domains

-Jim P.

postconf -d smtpd_relay_restrictions

[Jim Popovitch]

This can't be right

Using 'postconf -d smtpd_relay_restrictions'...

...on postfix v3.5 (Debian/Buster)
smtpd_relay_restrictions = ${{$compatibility_level} < {1} ? {} :
{permit_mynetworks, permit_sasl_authenticated,
defer_unauth_destination}}

...on postfix v3.6.3 (Debian/Bookworm)
smtpd_relay_restrictions = ${{$compatibility_level} 

Re: Fatal: no SASL authentication mechanisms

[Jim Popovitch]

On Tue, 2022-01-04 at 21:14 -0500, Ken Wright wrote:
> flags=DRhu
> user=vmail argv=/usr/bin/maildrop -d ${recipient}
> uucp   unix  -   n   n   -   -   pipe
> flags=Fqhu
> user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
> ifmail unix  -   n   n   -   -   pipe flags=F
> user=ftn
> argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
> bsmtp  unix  -   n   n   -   -   pipe flags=Fq.
> user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender
> $recipient
> scalemail-backend unix - n   n   -   2   pipe flags=R
> user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
> ${nexthop}
> ${user} ${extension}
> mailmanunix  -   n   n   -   -   pipe flags=FR
> user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
> ${nexthop}
> ${user}
> policyd-spf unix -   n   n   -   0   spawn
> user=policyd-spf
> argv=/usr/bin/policyd-spf
> 
> 

Those lines above look debian'ish to me.  If you are running debian,
then make sure you have libsasl2-2, libsasl2-modules and libsasl2-
modules-db installed.

-Jim P.

Re: feature request: improve vague/incorrect error message

[Jim]

On Tue, Nov 16, 2021 at 11:41 (-0500), Kris Deugau wrote:

> Jim wrote:
>> On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:

>>> Instead, use Maildir format with one message per file,

>> I thought about that once, but I decided I have too many e-mail
>> messages for that.  (I don't want to run out of inodes, nor do I want to
>> make file accesses too slow because of the number of files in the
>> directory.)

> I converted "local"[*] storage from mbox to maildir a number of
> years ago - IIRC I was starting to see performance issues with mbox
> in part due to the way I manage my mail and in part simply due to
> the number of messages I keep around.

> This account has ~13G of mail on my PC, with over 100K messages each
> in two folders, several in the tens of thousands, and most dedicated
> mailing list folders holding somewhere between about 5K and 8K
> messages each.

Thanks for the specifics.

> The only performance issues I have are:

> a) something sucks in the the IMAP protocol such that my mail client keeps
> having to create a new connection and reauthenticate - it's not strictly a
> timeout, because it's not on anything remotely resembling a predictable
> timing

At first glance I wouldn't see that related to mbox vs. maildir, but
I've been surprised before.

> Local storage is ext4 on a SATA SSD, although I wouldn't expect a noticeable
> performance difference if it were on a conventional hard drive.

I am surprised that accessing files in a directory with 100K entries
is not slow, since (according to what I read) ext4 stores entries in
an "almost linear" list, and thus to find a director entry you might
have to chew through (on average) 50K entries.  Of course, file system
caching will speed things up immensely, assuming one has enough RAM
(given the other activity on the system) to keep the contents of those
maildirs (that is, the directory contents, not the contents of the
files) in RAM.

> [*] Due to some legacy mail flow that would be painful to convert, I
> pull mail with fetchmail, deliver locally with procmail (sorry),
> then expose it to my mail client with a local Dovecot instance.

Again, thanks for your specifics.  Maybe I should give maildir a try
some time and see what happens.  (Or maybe I should just delete a bunch
of email and forget that I ever got it.)

I see that I have lots on inodes on the file system where I keep my
email: although the file system is 48% full, I have used only 3% of
the inodes, so I'm in no danger of running out.  If I used another
160,000 for mail messages I'd still be less than 6% inodes used, so
that turns out not to be a concern for me.  (The last time I
considered doing this I don't think I had such a surplus of inodes.)

Cheers.

Jim

Re: feature request: improve vague/incorrect error message

[Jim]

Wietse,

On Mon, Nov 15, 2021 at 12:25 (-0500), Wietse Venema wrote:

> Jim:

>> On Artix, the default is 5120.  (Aside: in 1985, that would have

> Postfix has limits on everything, so that the mail system will not
> get stuck. It's really a bad idea to disable them.

I agree that changing it to "unlimited" opens one up to some risks.

And I can't make a definitive argument for any particular default
value.  However, I still think that the limit of 5120 is far too
small in this day and age.

> TL;DR: If you want a better error message, stop using procmail.

Hmmm... Thanks for the summary.  On reflection, I guess I should have
realized that procmail was implicated.

> Procmail returns a status of 73, which is one of 15 status codes
> defined in /usr/include/sysexits.h. This file defines the interface
> between a mail server (such as Postfix) and an external program
> that delivers mail (such as procmail). The problem is not in
> procmail, it is in the sysexits.h interface.

> If you use Postfix itself for mailbox delivery, then the error
> message will be "File too large", one of the dozens of status codes
> defined in /usr/include/errno.h.

Indeed, that would have been more meaningful.

> On Linux, that file is the top of a forest of include files.

> Finally, if you want to keep lots of mail around, don't keep
> everything in one huge mailbox file.

I actually have a bunch of huge mailbox files ;-)
(Yeah, way too much email.)

> Instead, use Maildir format with one message per file,

I thought about that once, but I decided I have too many e-mail
messages for that.  (I don't want to run out of inodes, nor do I want to
make file accesses too slow because of the number of files in the
directory.)

> or rotate files frequently like I do.


On Mon, Nov 15, 2021 at 12:49 (-0500), Wietse Venema wrote:

> In fact, procmail can produce its own logging which may be more
> detailed. Returning fine detail to remote senders is not needed
> (hence "can't create ... file") if there is a local log that can
> record the underlying problem details.

Also thanks for that.  I guess I need to learn more about procmail
than I had really hoped to.


Thanks for the quick replies.

Jim

feature request: improve vague/incorrect error message

[Jim]

(This is really for postfix developers, but since I'm not allowed to
post this on the devel list, here it is here.)

Background: I recently moved from Ubuntu to Artix.  On Ubuntu, for
better or worse, mailbox_size_limit is 0, and I blissfully went around
using a large inbox.

On Artix, the default is 5120.  (Aside: in 1985, that would have
been a reasonable limit.  But time has moved on, and mass storage
devices have come down in price by many orders of magnitude, and the
size of attachments shipped via email has correspondingly increased.
I don't know whether that is the Artix-imposed limit or Arch-imposed
limit, or whether that is in the postfix distribution, but that is
another question.)

Not realizing this is one of the parameters I would need to configure,
I fired up fetchmail and started downloading my email.

This limit caused me to lose a certain number of email messages with
the only hint being log messages containing this:
... status=bounced (can't create user output file)

Searching the web, I came across a number of messages which pointed to
various permission problems (file ownership, programs needing to be
setgid or setuid, ...), and looking down these paths wasn't useful,
since permissions were not the problem.


In summary: would the powers that be consider improving that error
message so that it contains information about *why* it couldn't create
the user output file?

(In fact, I'd argue the error message is in fact wrong, because
(a) it didn't need to *create* the output file, and
(b) it was able to write to the output file, it just didn't want to.)

Thanks for reading.

Jim

Re: "parameter inet_interfaces: no local interface found for 127.0.0.2" at reboot, but not on manual systemctl start

[Jim Garrison]

On 7/29/2021 12:34 AM, Matus UHLAR - fantomas wrote:

On 28.07.21 12:54, Jim Garrison wrote:

This means that Postfix now starts up before the network is completely
up, and systemd's DNS resolution hack (systemd-resolved.service),
finding no interfaces up yet, resolves 'localhost' to 127.0.0.2.

(man systemd-resolved.service)


sorry, but this manpage says that localhost resolvs to 127.0.0.1
(as it always should).

according to systemd-resolved manpage, the local host name is resolved to
127.0.0.2 (not localhost)

maybe a just mistake in your description?



No, from man systemd-resolved.service:

   systemd-resolved synthesizes DNS resource records (RRs) for the
   following cases:

   ·   The local, configured hostname is resolved to all locally
   configured IP addresses ordered by their scope, or — if
   none are configured — the IPv4 address 127.0.0.2 (which is
   on the local loopback) and the IPv6 address ::1 (which is
   the local host).

So if the network isn't actually up yet, DNS queries get resolved by
systemd-resolved.  This explains how I could see the error message
about 127.0.0.2 without that IP address appearing anywhere.

Postfix must not attempt to start until the network is completely up.

--
Jim Garrison
j...@acm.org

Re: "parameter inet_interfaces: no local interface found for 127.0.0.2" at reboot, but not on manual systemctl start

[Jim Garrison]

On 7/28/2021 1:49 PM, Wietse Venema wrote:

Jim Garrison:

For anyone encountering this error, I've traced it to a regression of
a very old bug relating to systemd service ordering dependencies.

In my case, OS is CentOS Linux release 8.4.2105
postfix-3.5.8-1.el8.x86_64

Since a recent update I've found that, after every reboot, Postfix fails
to start, and logs the message

fatal: parameter inet_interfaces: no local interface found for 127.0.0.2

If I then manually start Postfix (systemctl start postfix) it starts
right up with no complaints.

Long story short, this appears to be a regression of the 6-year-old
systemd problem documented at

 https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331

The problem is that in CentOS 8, a recent update seems to have changed
Postfix's systemd service dependency from

After=syslog.target network-online.target

to

After=syslog.target network.target

This means that Postfix now starts up before the network is completely
up, and systemd's DNS resolution hack (systemd-resolved.service),
finding no interfaces up yet, resolves 'localhost' to 127.0.0.2.

(man systemd-resolved.service)

The simple fix is to create an override file with

 systemctl edit postfix.service"

and restore the "After=" dependency on network-online.target


Thanks. I agree, Postfix should start up after the network is fully
initialized. That includes all the network interfaces, and all the
network infrastructure services.

Wietse



Who "owns" (and maintains) the systemd unit files for Postfix? Is that
up to each individual distro's maintainers?  It would be nice if this
could be fixed in one place, but that's probably wishful thinking :-(

--
Jim Garrison
j...@acm.org

"parameter inet_interfaces: no local interface found for 127.0.0.2" at reboot, but not on manual systemctl start

[Jim Garrison]

For anyone encountering this error, I've traced it to a regression of
a very old bug relating to systemd service ordering dependencies.

In my case, OS is CentOS Linux release 8.4.2105
postfix-3.5.8-1.el8.x86_64

Since a recent update I've found that, after every reboot, Postfix fails
to start, and logs the message

fatal: parameter inet_interfaces: no local interface found for 127.0.0.2

If I then manually start Postfix (systemctl start postfix) it starts
right up with no complaints.

Long story short, this appears to be a regression of the 6-year-old
systemd problem documented at

   https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1519331

The problem is that in CentOS 8, a recent update seems to have changed
Postfix's systemd service dependency from

After=syslog.target network-online.target

to

After=syslog.target network.target

This means that Postfix now starts up before the network is completely
up, and systemd's DNS resolution hack (systemd-resolved.service),
finding no interfaces up yet, resolves 'localhost' to 127.0.0.2.

(man systemd-resolved.service)

The simple fix is to create an override file with

   systemctl edit postfix.service"

and restore the "After=" dependency on network-online.target

--
Jim Garrison
j...@acm.org

Re: Illegal address syntax in MAIL command

[jim]

That did the trick!  Many thanks.  ;)


On 2021-07-07 10:21, Kevin N. wrote:
It seems that in the MAIL command the IP address is still not between 
[].


 should be 

On a quick look, it seems that you could try setting
resolve_numeric_domain = yes in your Postfix configuration and see if
that changes anything.

From http://www.postfix.org/postconf.5.html

resolve_numeric_domain (default: no)
Resolve "user@ipaddress" as "user@[ipaddress]", instead of rejecting
the address as invalid.


Cheers,

K.


On 07/07/2021 18:08, j...@wrightthisway.com wrote:
I believe you are correct, but again I have no control over that part. 
Also, I mistakenly attached the log attempt from the telnet session I 
tried, the actual systems having issues have the from address within 
brackets, here is the system in question:


Jul  6 15:18:42 localhost postfix/smtpd[40342]: warning: Illegal 
address syntax from unknown[100.67.10.122] in MAIL command: 






On 2021-07-07 09:59, Kevin N. wrote:

When using IP addresses in the email address, shouldn't the IP be
enclosed between []?

For example: noreply@[100.67.10.122] instead of noreply@100.67.10.122

Cheers,

K.

On 07/07/2021 17:49, j...@wrightthisway.com wrote:
Hello folks.  I have set up a fresh instance of Postfix at my office 
to help do some troubleshooting on another issue.  There is a relay 
upstream that is having issues forwarding mail from some devices 
here, and this seemed the easiest way to get some data to help them 
troubleshoot.  Install is Redat 8.4 using the postfix install from 
YUM. Everything is pretty much default settings.


This is what I'm seeing in the logs:

Jul  6 15:36:02 localhost postfix/smtpd[40841]: connect from 
desktop-204qpi1.example.net[100.67.2.4]
Jul  6 15:36:20 localhost postfix/smtpd[40841]: warning: Illegal 
address syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL 
command: noreply@100.67.10.122
Jul  6 15:36:23 localhost postfix/smtpd[40841]: warning: Illegal 
address syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL 
command: noreply@100.67.10.122.
Jul  6 15:38:11 localhost postfix/smtpd[40841]: warning: Illegal 
address syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL 
command: 
Jul  6 15:38:48 localhost postfix/smtpd[40841]: disconnect from 
desktop-204qpi1.example.net[100.67.2.4] mail=1/4 quit=1 unknown=0/1 
commands=2/6


If I telnet to this postfix and use a mail from with an IP literal, 
it fails, but a DNS name works.  I can't seem to locate the proper 
command to allow such emails to be received.  These emails would be 
generated from Dell servers via their iDrac (system management), 
temperature probes, etc, so I have little control over how these 
devices send mail. Mail delivery would be targeted to system admins 
needing to monitor alerts from such systems.



Below is my postconf output:

[root@localhost postfix]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
ddd $daemon_directory/$process_name $process_id & sleep 5

html_directory = no
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
meta_directory = /etc/postfix
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 100.67.0.0/16
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550

Re: Illegal address syntax in MAIL command

[jim]

I believe you are correct, but again I have no control over that part.  
Also, I mistakenly attached the log attempt from the telnet session I 
tried, the actual systems having issues have the from address within 
brackets, here is the system in question:


Jul  6 15:18:42 localhost postfix/smtpd[40342]: warning: Illegal address 
syntax from unknown[100.67.10.122] in MAIL command: 






On 2021-07-07 09:59, Kevin N. wrote:

When using IP addresses in the email address, shouldn't the IP be
enclosed between []?

For example: noreply@[100.67.10.122] instead of noreply@100.67.10.122

Cheers,

K.

On 07/07/2021 17:49, j...@wrightthisway.com wrote:
Hello folks.  I have set up a fresh instance of Postfix at my office 
to help do some troubleshooting on another issue.  There is a relay 
upstream that is having issues forwarding mail from some devices here, 
and this seemed the easiest way to get some data to help them 
troubleshoot.  Install is Redat 8.4 using the postfix install from 
YUM. Everything is pretty much default settings.


This is what I'm seeing in the logs:

Jul  6 15:36:02 localhost postfix/smtpd[40841]: connect from 
desktop-204qpi1.example.net[100.67.2.4]
Jul  6 15:36:20 localhost postfix/smtpd[40841]: warning: Illegal 
address syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL 
command: noreply@100.67.10.122
Jul  6 15:36:23 localhost postfix/smtpd[40841]: warning: Illegal 
address syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL 
command: noreply@100.67.10.122.
Jul  6 15:38:11 localhost postfix/smtpd[40841]: warning: Illegal 
address syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL 
command: 
Jul  6 15:38:48 localhost postfix/smtpd[40841]: disconnect from 
desktop-204qpi1.example.net[100.67.2.4] mail=1/4 quit=1 unknown=0/1 
commands=2/6


If I telnet to this postfix and use a mail from with an IP literal, it 
fails, but a DNS name works.  I can't seem to locate the proper 
command to allow such emails to be received.  These emails would be 
generated from Dell servers via their iDrac (system management), 
temperature probes, etc, so I have little control over how these 
devices send mail. Mail delivery would be targeted to system admins 
needing to monitor alerts from such systems.



Below is my postconf output:

[root@localhost postfix]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin 
ddd $daemon_directory/$process_name $process_id & sleep 5

html_directory = no
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
meta_directory = /etc/postfix
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 100.67.0.0/16
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550

Illegal address syntax in MAIL command

[jim]

Hello folks.  I have set up a fresh instance of Postfix at my office to 
help do some troubleshooting on another issue.  There is a relay 
upstream that is having issues forwarding mail from some devices here, 
and this seemed the easiest way to get some data to help them 
troubleshoot.  Install is Redat 8.4 using the postfix install from YUM.  
Everything is pretty much default settings.


This is what I'm seeing in the logs:

Jul  6 15:36:02 localhost postfix/smtpd[40841]: connect from 
desktop-204qpi1.example.net[100.67.2.4]
Jul  6 15:36:20 localhost postfix/smtpd[40841]: warning: Illegal address 
syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL command: 
noreply@100.67.10.122
Jul  6 15:36:23 localhost postfix/smtpd[40841]: warning: Illegal address 
syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL command: 
noreply@100.67.10.122.
Jul  6 15:38:11 localhost postfix/smtpd[40841]: warning: Illegal address 
syntax from desktop-204qpi1.example.net[100.67.2.4] in MAIL command: 

Jul  6 15:38:48 localhost postfix/smtpd[40841]: disconnect from 
desktop-204qpi1.example.net[100.67.2.4] mail=1/4 quit=1 unknown=0/1 
commands=2/6


If I telnet to this postfix and use a mail from with an IP literal, it 
fails, but a DNS name works.  I can't seem to locate the proper command 
to allow such emails to be received.  These emails would be generated 
from Dell servers via their iDrac (system management), temperature 
probes, etc, so I have little control over how these devices send mail.  
Mail delivery would be targeted to system admins needing to monitor 
alerts from such systems.



Below is my postconf output:

[root@localhost postfix]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
compatibility_level = 2
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd 
$daemon_directory/$process_name $process_id & sleep 5

html_directory = no
inet_interfaces = all
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
meta_directory = /etc/postfix
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 100.67.0.0/16
mynetworks_style = subnet
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix/README_FILES
sample_directory = /usr/share/doc/postfix/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
shlib_directory = /usr/lib64/postfix
smtp_tls_CAfile = /etc/pki/tls/certs/ca-bundle.crt
smtp_tls_CApath = /etc/pki/tls/certs
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
smtpd_tls_key_file = /etc/pki/tls/private/postfix.key
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550

Re: Search for free MX Backup Service

[Jim Popovitch]

On Sat, 2021-07-03 at 00:30 -0600, @lbutlr wrote:
> 
> MX backups are a legacy of 30-40 years ago when it was very common to
> have machines that only periodically connected to the Internet. There
> are many reasons they are a bad idea in a modern context, and having a
> third party be a alternate path for your mail is a particularly bad
> idea.

While I agree that MX backups are a pita, it's important to note that
something very common these days are routing issues.  I have a SMTP
server in NYC area that (new to me) can't deliver email to people who
use Level3/CenturyLink due to some things outside of my control. I'm
100% sure the reverse situation exists somewhere even though I may not
know about it today. So my resolution to others' corporate greed and
neck beard routing laziness is more than 1 MX.

-Jim P.

Re: Does smtpd_milters=inet:.... round-robin if the hostname has multiple IPs?

[Jim Popovitch]

On Mon, 2021-05-31 at 19:07 -0400, Wietse Venema wrote:
> Jim Popovitch:
> > > Postfix will try each IP address in the order as returned from
> > > getaddrinfo(3) until it can establish a TCP connection. Postfix
> > > will not reconnect when an established Milter connection goes bad.
> > > For example, the Milter does not respond, or produces bad responses.
> > 
> > Right, I got that from your earlier post, thank you again.  Would you be
> > interested in a patch or some idea on how to make that more robust?
> 
> How would you handle the case that the Milter hangs after RCPT TO
> or END-OF-DATA, or after the Milter has requested changes to queue
> file content? That requires replaying events already sent to a
> milter, and redoing changes already made to a queue file.
> 

Hanging after RCPT TO and END-OF-DATA should be (imho) handled the same
as milter_command_timeout, unless there is some reason that I can't
think of.

I'm not sure about the after the Milter has requested changes to queue
file contents, can you explain more about when/how that would happen? 
Thanks!

-Jim P.

Re: Does smtpd_milters=inet:.... round-robin if the hostname has multiple IPs?

[Jim Popovitch]

On Mon, 2021-05-31 at 18:20 -0400, Wietse Venema wrote:
> Jim Popovitch:
> > On Mon, 2021-05-31 at 16:18 -0400, Wietse Venema wrote:
> > > Jim Popovitch:
> > > > Hello,
> > > > 
> > > > If given hostname that resolves to multiple A/ records, will
> > > > smtpd_milters=inet:... cycle through all A/ records until if
> > > > finds a host that it can connect to?
> > > 
> > > Postfix will try each IP address (as returned from getaddrinfo(3))
> > > until it can establish a TCP connection. Postfix does not randomize
> > > the order of these IP addresses, and it does not reconnect (and
> > > replay a session) when an established Milter connection goes bad.
> > 
> > Thanks for that detail.
> > 
> > > > If so, does it make sense to reduce milter_connect_timeout to 10
> > > > or 15 seconds?
> > > 
> > > When does it make sense to run Postfix and Milters in different
> > > failure domains? I have no experience with such configurations.
> > 
> > My thought is that having 2+ content filter endpoints could increase
> > postfix's resiliency if a rules update or processing hack corrupt the
> > process the milter is calling. 
> 
> That would not solve your problem.
> 
> Postfix will try each IP address in the order as returned from
> getaddrinfo(3) until it can establish a TCP connection. Postfix
> will not reconnect when an established Milter connection goes bad.
> For example, the Milter does not respond, or produces bad responses.

Right, I got that from your earlier post, thank you again.  Would you be
interested in a patch or some idea on how to make that more robust?

-Jim P.

Re: Does smtpd_milters=inet:.... round-robin if the hostname has multiple IPs?

[Jim Popovitch]

On Mon, 2021-05-31 at 16:18 -0400, Wietse Venema wrote:
> Jim Popovitch:
> > Hello,
> > 
> > If given hostname that resolves to multiple A/ records, will
> > smtpd_milters=inet:... cycle through all A/ records until if
> > finds a host that it can connect to?
> 
> Postfix will try each IP address (as returned from getaddrinfo(3))
> until it can establish a TCP connection. Postfix does not randomize
> the order of these IP addresses, and it does not reconnect (and
> replay a session) when an established Milter connection goes bad.

Thanks for that detail.

> > If so, does it make sense to reduce milter_connect_timeout to 10
> > or 15 seconds?
> 
> When does it make sense to run Postfix and Milters in different
> failure domains? I have no experience with such configurations.

My thought is that having 2+ content filter endpoints could increase
postfix's resiliency if a rules update or processing hack corrupt the
process the milter is calling. 

-Jim P.

Does smtpd_milters=inet:.... round-robin if the hostname has multiple IPs?

[Jim Popovitch]

Hello,

If given hostname that resolves to multiple A/ records, will
smtpd_milters=inet:... cycle through all A/ records until if finds a
host that it can connect to?

If so, does it make sense to reduce milter_connect_timeout to 10 or 15
seconds?

tia,


-Jim P.

Re: strange characters in log

[Jim Popovitch]

On Mon, 2021-05-24 at 03:00 +0200, Fourhundred Thecat wrote:
> Hello,
> 
> I see following lines in my log (pasted below). What do these errors
> mean? Is somebody sending garbage characters to my server?

Same here


May 24 00:10:18 mx1 postfix/trivial-rewrite[11417]: warning:
midna_domain_to_ascii_create: Problem translating domain "اختبار-
القبول-العالمي.شبكة" to ASCII form:
UIDNA_ERROR_DISALLOWED

May 24 00:25:11 mx2 postfix/trivial-rewrite[13453]: warning:
midna_domain_to_ascii_create: Problem translating domain "اختبار-
القبول-العالمي.شبكة" to ASCII form:
UIDNA_ERROR_DISALLOWED



-Jim P.

Re: Logging Question: SASL Auth Failures?

[Jim Seymour]

On Wed, 20 Jan 2021 10:33:37 -0500 (EST)
Wietse Venema  wrote:

[snip]
> 
> With rsyslogd.conf you can route based on content.
> 
> :msg, contains, "SASL LOGIN"  /var/log/whatever
> :msg, contains, "SASL LOGIN"  ~
> 
> This is based on information from the web, which is often incorrect.

Ok.  Thanks, Wietse.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Logging Question: SASL Auth Failures?

[Jim Seymour]

Hi All,

Each of the various servers I admin occasionally get inundated with
things like

Jan 13 07:33:06 jimsun postfix/submission/smtpd[25328]: warning:
unknown[59.95.95.239]: SASL LOGIN authentication failed:
UGFzc3dvcmQ6

I want these to go to the auth log, rather than, or in addition to,
the mail log.

Anybody know what is the syslog severity level and facility code
attached to SASL auth errors?

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Re: Connection refused / telnet: connect to address 10.5.2.1: Connection refused

[Jim Reid]

> On 29 Dec 2020, at 12:58, Wolfgang Paul Rauchholz  
> wrote:
> 
> The server is listening on port 25, 587 and 465
> netstat -plutn | grep 25 and 587
> tcp0  0 127.0.0.1:250.0.0.0:*   LISTEN
>   28704/master
> tcp0  0 127.0.0.1:587   0.0.0.0:*   LISTEN
>   21435/smtpd
> 
> I can send mails to my gmail account. But when responding to this mail I get 
> nothing back

That’s to be expected. You seem to have configured postfix to only listen on 
port 25 for the loopback interface (127.0.0.1). If postfix isn’t listening on 
an IP address that’s reachable from the Internet, it’s never going to receive 
any email from the Internet. Check inet_interfaces in main.cf and post the 
output of postconf if you need further help.

postfix should probably be listening on that 10.5.2.1 interface (as well as 
127.0.0.1). But there will be even more to do. 10.5.2.1 is a private IP address 
that isn’t routed on the Internet. See RC1918. So that isn’t reachable either. 
Presumably your DSL or cable box is doing network or port address translation 
to map its real IP address on to 10.5.2.1, the internal one you’ve used on your 
home network. You’ll need to confirm that address translation is working 
correctly for both inbound and outbound packets.

You’ll also need to configure the DNS for your domain name(s) to have MX 
records that ultimately map to that public IP address. If not, the world won’t 
know how to deliver email to you. ie in the zone file for your-domain.com have 
entries like:

your-domain.com. IN MX 20 foo.your-domain.com.
foo.your-domain.com. IN A public-ip-address-goes-here

On your internal network, you’ll need to configure mail clients to connect to 
port 25 on 10.5.2.1 when they send email. Or use the loopback interface if the 
clients run on the same box that’s running postfix. You could do this with a 
split DNS configuration - two versions of your-domain.com, one for the Internet 
and one for your internal net. However based on your questions here, that 
requires a lot more DNS expertise than you appear to have. Questions about that 
belong on a DNS forum and not the postfix mailing list.

BTW Your test connections to 10.5.2.1:imap work because IIRC dovecot listens on 
all available network interfaces by default. postfix has to be told which 
interfaces to listen on port 25 for incoming email.

Re: Postfix 3.5.5 and TLS handshake failure

[Jim Maenpaa]

07:00:37 morbo postfix/smtpd[73115]: connect from 
st11p00im-ztba01351701.me.com[17.172.82.217]
Jul 26 07:00:37 morbo postfix/smtpd[73115]: SSL_accept error from 
st11p00im-ztba01351701.me.com[17.172.82.217]: -1
Jul 26 07:00:37 morbo postfix/smtpd[73115]: warning: TLS library problem: 
error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared 
cipher:/usr/src/crypto/openssl/ssl/statem/statem_srvr.c:2259:
Jul 26 07:00:37 morbo postfix/master[49852]: warning: process 
/usr/local/libexec/postfix/smtpd pid 73115 killed by signal 11

When the me.com server tries again, the TLS handshake works:

Jul 26 07:10:34 morbo postfix/smtpd[73299]: Anonymous TLS connection 
established from st11p00im-ztba01351701.me.com[17.172.82.217]: TLSv1.2 with 
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Jul 26 07:10:34 morbo postfix/smtpd[73299]: 4BF4bG2wSxzwPm: 
client=st11p00im-ztba01351701.me.com[17.172.82.217]

-jim

Re: may we suggest ICANN not run that many new tlds?

[Jim Reid]

> On 19 Nov 2019, at 09:58, Merrick  wrote:
> 
> in the coming future, everything is a TLD, the cat, the dog, the pig, the 
> rose, the coffee, the wine, the bike ...
> that would be terrible for domain based validation.
> we have already too many TLDs today.
> may we suggest ICANN not open a new TLD anymore?

The ICANN policy process is open to all. Knock yourself out. :-)

Re: Error 46 with TLS

[Jim P.]

On Sat, 2019-09-21 at 16:13 +0200, Matus UHLAR - fantomas wrote:
> with letsencrypt (and most other certificate authorities), servers need to
> provide intermediate certificate in addition to their own cert.
> 
> postfix does not have separate configuration directive for CA chain file (as
> apache, proftpd and many other servers have, so you must append certificate
> chain file(s) to certificate file provided with smtpd_tls_cert_file or
> smtpd_tls_chain_files (since 3.4).

Wait, what? 

This works perfectly fine for me on debian:

smtpd_tls_key_file=/etc/letsencrypt/live/smtp.domainmail.net/privkey.pem
smtpd_tls_cert_file=/etc/letsencrypt/live/smtp.domainmail.net/cert.pem
smtpd_tls_CAfile=/etc/letsencrypt/live/smtp.domainmail.net/fullchain.pem
smtpd_tls_CApath=/etc/ssl/certs/


-Jim P.

Re: Refuse mail from hosts with closed port 25

[Jim Reid]

> On 16 Sep 2019, at 14:17, Paul van der Vlis  wrote:
> 
>> A significant number of installations will use different servers for
>> inbound and outbound email.
> 
> I know a provider what is actually using this. I guess only the big
> providers will have different servers for inbound and outbound email,

Guess again. Hint: you might be mistaken.

> and you can make a list of them.

Guess again. Hint: you might be mistaken.

Re: Refuse mail from hosts with closed port 25

[Jim Reid]

> On 16 Sep 2019, at 13:47, Paul van der Vlis  wrote:
> 
> How can I refuse mail from hosts who don't have an open port 25?
> 
> What do you think from such a check?

It’s a stunningly bad idea. Don’t do it.

Many enterprises and cloud-based mail providers have discrete servers/systems 
handling inbound and outbound mail. In these setups, the servers sending you 
email won’t have a listener on port 25 -- or any other port -- for inbound 
email.

> Is there more needed?  E.g. a list of exceptions for some big providers?

It’ll be impractical to maintain a workable whitelist. There will probably be 
too many false positives and negatives. And the approach probably won’t be an 
effective anti-spam measure either. But if you want to try the experiment and 
report back, go ahead. It’ll only be you and your customers who will have to 
deal with the consequences.

Re: 'SERVFAIL' error on DNS 'TXT' lookup

[Jim Reid]

> On 14 Jun 2019, at 14:24, klirstr  wrote:
> 
> host smtp.customerdomain.com[customer-mx-server-ip] said: 450 4.7.1 
> : Recipient address rejected: 
> SPF-Result=smtp.mydomain.com: 'SERVFAIL' error on DNS 'TXT' lookup of 
> 'smtp.mydomain.com' (in reply to RCPT TO command)) 
>  u...@customerdomain.com 
> 
> 
> I don't really understand the error but I tried to add an SPF record ("v=spf1 
> mx -all") to my dns domain but it didn't solve the issue.  So I am wondering 
> about below. 
> 
> - Is the problem on my side or customer-side? 
> - Is it because I cannot read the customer SPF record (they have one) 
> properly? 
> - Is there a way to "bypass" this error? 

It’s impossible to answer your questions from the information provided. In 
future, always show any log and error messages *verbatim*. None of this silly 
obfuscation of domain names and IP addresses: customerdomain.com or whatever. 
That helps no-one.

What would your reaction be if my answer was "the problem is xx x xxx 
xx  xx (details hidden for imaginary/misguided security reasons)"?

That said, the quoted error message suggests DNS lookups for smtp.mydomain.com 
are returning SERVFAIL - which means DNS is very badly broken for that domain. 
If you’d told us the actual domain name instead of hiding it, somebody could 
have checked that and might well have been able to diagnose the fault.

Re: Can postscreen whitelist?

[Jim P.]

On Mon, 2019-04-15 at 10:21 -0600, Shawn Heisey wrote:
> On 4/15/2019 10:02 AM, Jim P. wrote:
> > Sure.  You want postscreen_access_list, which defaults to permit_mynetworks.
> > Just add it to your config with a lookup table like so:
> > 
> > postscreen_access_list = permit_mynetworks, 
> > hash:/etc/postfix/postscreen_access_list
> > 
> > ~# cat /etc/postfix/postscreen_access_list
> > 168.100.1.3 permit  # camomile.cloud9.net
> > 2604:8d00:0:1::3permit  # camomile.cloud9.net
> > 168.100.1.4 permit  # russian-caravan.cloud9.net
> > 2604:8d00:0:1::4permit  # russian-caravan.cloud9.net
> > 168.100.1.7 permit  # 
> > english-breakfast.cloud9.net
> > 2604:8d00:0:1::7permit  # 
> > english-breakfast.cloud9.net
> 
> That looks like a list of client IP addresses, not a list of email 
> addresses.  It is an email address (a local one in the mysql database) 
> that I want to whitelist, not a client IP address.


You said "For users who want to receive email from servers.."

You can whitelist servers, but not specific email addresses from those
servers.

-Jim P.

Re: Can postscreen whitelist?

[Jim P.]

On Mon, 2019-04-15 at 09:43 -0600, Shawn Heisey wrote:
> Something I did pretty recently on the various restrictions in main.cf 
> was add a spam_lovers access file that allows me to whitelist certain 
> recipients so that messages to them will bypass all the filtering.
> 
> I did this because I've had people tell me about situations where they 
> did not receive an important email, usually from a relative.  When I 
> look into these problems, it's almost always something basic, like 
> reverse DNS.  And I find that a whole lot of people will not lift a 
> finger to fix the problems with their mail server.
> 
> For users who want to receive email from servers that are run by these 
> bad admins, I can add them to the spam_lovers file and redo postmap on 
> it.  Their incoming email will bypass almost every filter I've got. 
> They don't even seem to mind the massive increase in spam that this creates.
> 
> But I've realized that this config doesn't affect postscreen.  Sometimes 
> the sender will be on a server that has been blacklisted by an RBL and 
> either the admin won't try to fix the problem or they are unable to get 
> the problem fixed.
> 
> So now we come to my question:  Can I whitelist a recipient so email to 
> that user will always pass postscreen?  I tried to find an answer with 
> google and came up empty.
> 
> Here's the full restriction config from main.cf.  If anybody sees any 
> problems with that config, I would appreciate knowing that too:
> 
> --
> smtpd_relay_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> defer_unauth_destination
> 
> smtpd_client_restrictions =
> check_recipient_access hash:/etc/postfix/spam_lovers,
> check_sender_access hash:/etc/postfix/always_sender_access,
> permit_sasl_authenticated,
> permit_mynetworks,
> check_client_access cidr:/etc/postfix/client_access,
> check_sender_access hash:/etc/postfix/sender_access,
> reject_unknown_reverse_client_hostname,
> reject_unknown_client_hostname
> 
> smtpd_helo_restrictions =
> check_recipient_access hash:/etc/postfix/spam_lovers,
> check_sender_access hash:/etc/postfix/always_sender_access,
> permit_sasl_authenticated,
> permit_mynetworks,
> check_client_access cidr:/etc/postfix/client_access,
> reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname
> 
> smtpd_sender_restrictions =
> check_recipient_access hash:/etc/postfix/spam_lovers,
> check_sender_access hash:/etc/postfix/always_sender_access,
> permit_sasl_authenticated,
> permit_mynetworks,
> check_sender_access hash:/etc/postfix/sender_access,
> check_client_access cidr:/etc/postfix/client_access,
> reject_non_fqdn_sender,
> reject_unknown_sender_domain
> 
> smtpd_recipient_restrictions =
> check_recipient_access hash:/etc/postfix/spam_lovers,
> check_sender_access hash:/etc/postfix/always_sender_access,
> permit_sasl_authenticated,
> permit_mynetworks,
> check_sender_access hash:/etc/postfix/sender_access,
> check_recipient_access hash:/etc/postfix/recipient_access,
> check_client_access cidr:/etc/postfix/client_access,
> sleep 2,
> reject_non_fqdn_recipient,
> reject_unauth_destination,
> reject_unknown_recipient_domain,
> reject_unlisted_recipient,
> check_policy_service unix:private/policy-spf
> 
> smtpd_data_restrictions =
> permit_mynetworks,
> reject_unauth_pipelining,
> reject_multi_recipient_bounce
> --
> 
> Thanks,
> Shawn


Sure.  You want postscreen_access_list, which defaults to permit_mynetworks. 
Just add it to your config with a lookup table like so:

postscreen_access_list = permit_mynetworks, 
hash:/etc/postfix/postscreen_access_list

~# cat /etc/postfix/postscreen_access_list
168.100.1.3 permit  # camomile.cloud9.net
2604:8d00:0:1::3permit  # camomile.cloud9.net
168.100.1.4 permit  # russian-caravan.cloud9.net
2604:8d00:0:1::4permit  # russian-caravan.cloud9.net
168.100.1.7 permit  # english-breakfast.cloud9.net
2604:8d00:0:1::7permit  # english-breakfast.cloud9.net

hth,

-Jim P.

Re: OpenDKIM not signing

[Jim P.]

On Tue, 2019-04-09 at 08:22 +, Laura Smith wrote:
> OpenDKIM is not signing my mails.
.
> KeyTable    /etc/opendkim/KeyTable

I think this should be:

KeyTablerefile:/etc/opendkim/KeyTable


> InternalHosts   refile:/etc/opendkim/TrustedHosts

Try using ExternalIgnoreList (i don't know why it works, but it does)

#InternalHosts  refile:/etc/opendkim/InternalHosts
ExternalIgnoreList  refile:/etc/opendkim/InternalHosts

hth,

-Jim P.

What's new in log file parsers? Anything better than pflogsumm?

[Jim Rice]

I'm looking for a postfix log file parser that can provide the number of
messages delivered,
broken down by sending domain, and per hour counts on a daily basis.

I have looked at pflogsumm, but it seems a bit dated, and isn't as flexible
as I had hoped.

Can someone suggest any alternatives?




--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: Rethinking the Postfix release schedule

[Jim Popovitch]

On January 31, 2019 11:10:50 AM UTC, Matus UHLAR - fantomas  
wrote:
>while debian and ubuntu LTS have 2-year cycle and 5-year LTS support, yes,
>that can get near 8 years behind.


Debian has no strict release cycles, and Debian's LTS is based on several 
factors including $$, time, and personnel.

-Jim P.

Re: mailer-daemon bounce notifications with original message in clear text?

[Jim Rice]

As a followup, we found a workaround...

postconf -e bounce_size_limit=1
zmcontrol restart

(Yes, this is Zimbra.)

This had the effect of including the bounce notification and headers,
but without the original email content (and no .eml attachment).



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

Re: mailer-daemon bounce notifications with original message in clear text?

[Jim Rice]

The sending platform is Sitecore, which I believe is a Microsoft platform.



--
Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html

mailer-daemon bounce notifications with original message in clear text?

[Jim Rice]

We have a client connecting with a custom pop-client script that wants to parse 
mailer-daemon bounce notifications.
But the original email content is being returned as an .eml attachment.

Is there any way to configure bounce to compose the response message in clear 
text (message/rfc822)?

mail_version = 3.1.1

Re: SSL not working after unwanted server migration

[Jim P.]

On Mon, 2018-12-10 at 04:22 -0800, Alice Wonder wrote:
> ssl_min_protocol = TLSv1.2
> ssl_cipher_list = 
> EECDH+CHACHA20:EECDH+AESGCM:EECDH+SHA384:EECDH+SHA256:EECDH:!3DES:!RC4
> :!ADH:!LOW@STRENGTH
> ssl_prefer_server_ciphers = yes

Don't forget about ssl_dh_parameters_length, it's default on Debian is
1024.

-Jim P.

Re: Installing LetsEncrypt For Postfix and Dovecot

[Jim P.]

On Thu, 2018-11-29 at 09:28 +0100, Matus UHLAR - fantomas wrote:
> > On Wed, 2018-11-28 at 10:03 +0100, Matus UHLAR - fantomas wrote:
> > > But I prefer dehydrated over bloated certbot.
> 
> On 28.11.18 09:49, Jim P. wrote:
> > This comes up enough to warrant the following questions:
> > 
> > 1) What do you do about restarting services after automatic cert
> > renewals in the middle of a holiday weekend?  (i.e. renew_hook in
> > /etc/letsencrypt/renewal/*.conf)
> 
> simply modified provided hook.sh script to reload/restart all services
> that use certificates.

ack

> > 2) What do you do to list all certs to show revocation, expiration,
> > renewal status (e.g. certbot certificates)
> 
> I haven't needed this yet.  I remember that dehydrated contains option
> to clean up old certificates.
> 

Ok, Thank you.

-Jim P.

Re: Installing LetsEncrypt For Postfix and Dovecot

[Jim P.]

On Wed, 2018-11-28 at 12:25 -0500, Viktor Dukhovni wrote:
> > On Nov 28, 2018, at 9:49 AM, Jim P.  wrote:
> > 
> > 1) What do you do about restarting services after automatic cert
> > renewals in the middle of a holiday weekend?  (i.e. renew_hook in
> > /etc/letsencrypt/renewal/*.conf)
> 
> There is no need to restart or even "reload" Postfix when certificates
> change, unless you've left renewal too late, and are already or will
> imminently be serving expired certificates.
> 
> Most Postfix service processes, in particular all the ones that
> make use of private keys and certificates, run for a limited
> amount of time and are automatically replaced with newer processes
> that use the latest settings.

Thanks for that point, that makes good sense.

-Jim P.


signature.asc
Description: This is a digitally signed message part

Re: Installing LetsEncrypt For Postfix and Dovecot

[Jim P.]

On Wed, 2018-11-28 at 10:03 +0100, Matus UHLAR - fantomas wrote:
> On 27.11.18 10:52, Asai wrote:
> > With Mozilla recently dropping support for all Symantec certs, our
> > security
> > cert now throws errors on Thunderbird clients.  We’d like to install
> > certbot on Centos 6, but I’m not sure if it’s going to interfere
> > with
> > Postfix (2.11) or Dovecot (2.2.18).  Does anybody have experience
> > with
> > this?
> 
> I have no problem with Let's Encrypt certificates and
> postfix/whatever.
> I'm just not sure if iphones have the root CA (DST Root CA X3)
> installed -
> just yesterday noticed a complaint.
> 
> But I prefer dehydrated over bloated certbot.

This comes up enough to warrant the following questions:

1) What do you do about restarting services after automatic cert
renewals in the middle of a holiday weekend?  (i.e. renew_hook in
/etc/letsencrypt/renewal/*.conf)

2) What do you do to list all certs to show revocation, expiration,
renewal status (e.g. certbot certificates)

-Jim P.

Re: A bit stuck compiling Postfix on Mac Mojave.

[Jim Reid]

On 19 Nov 2018, at 15:42, Robert Chalmers  wrote:
> 
>   "_OpenSSL_version", referenced from:
>  import-atom in libpostfix-tls.dylib
> ...
>   "_X509_up_ref", referenced from:
> import-atom in libpostfix-tls.dylib
> ld: symbol(s) not found for architecture x86_64
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make: *** [smtpd] Error 1
> make: *** [update] Error 1
> make: *** [update] Error 2
> zeus:postfix-3.3.1 robert$ 
> 
> 
> Thanks for any ideasa.

It looks like you've not given the correct voodoo to the compiler/linker to use 
some version of an openssl library. IIUC, Apple replaced OpenSSL (with 
LibreSSL?) a few years ago because of the Heartbleed bug. You might well be 
linking against that ssl library rather than the openssl one you expected. The 
MacOSX ssl library doesn't replicate all the variable names and function calls 
in OpenSSL.

Re: Reminder DNSSEC Root KSK roll today

[Jim Reid]

> On 11 Oct 2018, at 19:07, pg...@dev-mail.net wrote:
> 
>> The switch to the new KSK seems the most likely cause, assuming DNSSEC 
>> validation always worked for you before then.
> 
> It's been 'working' for ages.  Yes, I could have been 'just lucky for a long 
> time'. 

DNSSEC is very brittle. Either it works perfectly or not at all. Luck has 
nothing to do with it. Ending up with a working DNSSEC setup is something that 
rarely if ever happens by accident. If your validators don’t/can’t maintain up 
to date trust anchors they *will* fail at some point. Today might well have 
been that day for you.

Ensuring trust anchor(s) are current is critical to DNSSEC validation. It’s not 
a matter of luck if this doesn’t get configured correctly. And it’s not a 
matter of luck if someone’s failed to plan for today’s KSK rollover or been 
unaware of this high profile event. Sorry.

Re: Reminder DNSSEC Root KSK roll today

[Jim Reid]

On 11 Oct 2018, at 18:27, pg...@dev-mail.net wrote:
> 
> Changing my local dns (named) config to
> 
>   -   dnssec-enable yes;
>   +   dnssec-enable no;
>   dnssec-lookaside  no;
>   -   dnssec-validation yes;
>   +   dnssec-validation no;
> 
> gets me back up & running, without DNSSEC of course.

Although switching off DNSSEC validation will keep the mail flowing, it only 
kludges around the underlying problem. Which might or might not be related to 
the rollover of the root KSK a few hours ago. It’s hard to tell from the 
information you’ve provided. That said, you do appear to have a DNS server 
misconfiguration which is causing DNSSEC validation to fail. Clearly it would 
be wise to fix that before turning DNSSEC validation on again.

The switch to the new KSK seems the most likely cause, assuming DNSSEC 
validation always worked for you before then.

> Is 'ready' simply  'wait awhile’ ?

Maybe, maybe not. It depends on what is broken in your DNSSEC setup. If you’ve 
hard-wired the now dead root KSK, waiting a while won’t help. That key will 
still be dead when you re-enable DNSSEC validation. No matter how long or short 
you wait.

Consult ICANN’s web pages on the root KSK rollover. They have info on how to 
check that DNS configurations handle the KSK rollover properly and how to 
troubleshoot them when they don’t.

Re: [Postfix] Re: [Postfix] Re: [Postfix] Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS

[Jim P.]

On Tue, 2018-05-29 at 13:57 -0400, Viktor Dukhovni wrote:
> > On May 29, 2018, at 1:54 PM, Jim P.  wrote:
> > 
> > It's more of a language "feature".  This works:
> > 
> > LANG=C comm -1 -2 <(postconf -n) <(postconf -d)
> > 
> > this doesn't:
> > 
> > LANG=en_US comm -1 -2 <(postconf -n) <(postconf -d)
> 
> The collation rules for "en_US" are abominable.  I always set:
> 
>   LC_CTYPE=en_US.UTF-8 LANG=C
> 
> but if you just want sensible collation, with everything else
> using "en_US", you can just set LC_COLLATE=C.

Ahh, sounds good.  Thanks for that.

-Jim P.

Re: [Postfix] Re: [Postfix] Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS

[Jim P.]

On Tue, 2018-05-29 at 13:32 -0400, Viktor Dukhovni wrote:
> > On May 29, 2018, at 12:28 PM, Jim P.  wrote:
> > 
> > FWIW, I had to use this:
> > 
> > comm -1 -2 <(postconf -n|sort) <(postconf -d|sort)
> 
> That'd only be needed if you have a funny collation locale.
> Try:
> 
>  env -i "PATH=$PATH" LANG=C LC_COLLATE=C bash -c '
>  comm -1 -2 <(postconf -n) <(postconf -d)
>  '
> 

It's more of a language "feature".  This works:

LANG=C comm -1 -2 <(postconf -n) <(postconf -d)

this doesn't:

LANG=en_US comm -1 -2 <(postconf -n) <(postconf -d)

-Jim P. 

Re: [Postfix] Re: Question about disabling SSLv2 and SSLv3 and Opportunistic TLS

[Jim P.]

On Tue, 2018-05-29 at 10:49 +0200, Stefan Förster wrote:
> * Dirk Stöcker :
> > On Mon, 28 May 2018, Viktor Dukhovni wrote:
> > 
> > > > It might be useful, but probably not, to have a version of
> > > > postconf -n that showed the default value along sinde the
> > > > changed value:
> > > 
> > > join <(postconf -n) <(postconf -d | sed 's/=/(default:/; s/$/)/')
> > 
> > Do you maybe also have a command to show only changed parameters?
> > 
> > Something like postconf -n, but dropping everything identical to
> > default.
> 
> You can get changed parameters that are at their default value with:
> 
> comm -1 -2 <(postconf -n) <(postconf -d)

FWIW, I had to use this:

comm -1 -2 <(postconf -n|sort) <(postconf -d|sort)

-Jim P.

Re: Hotmail spam prevention mech.

[Jim Reid]

> On 16 Jan 2018, at 10:49, jin  wrote:
> 
> We are having difficulties while delivering mails to Microsoft's domains like 
> hotmail and outlook.

They appear to have a DNS problem which is causing outbound mail to fail. Their 
SMTP servers are using non-existent hostnames when they say HELO. This DNS 
brokenness may well be wreaking havoc for those using SPF, DKIM, etc when 
speaking to M$ mail servers or receiving email from them.

Re: Accurate install guide for Postfix on Ubuntu 16.04 LTS

[Jim Reid]

> On 15 Sep 2017, at 11:07, pjakcity  wrote:
> 
> All i want is enough understanding that wont take me years so i can set this
> up, but understand what features are present and what they do (in a broad
> sence)

Note the O/P's email address

Dear Internet, please do my classwork for me.

Re: Check out my Kickstarter

[Jim McCorison]

For those that are user’s of Kickstarter, might I suggest reported this 
campaign for spamming. Here’s the link: 
https://www.kickstarter.com/projects/1349369124/endfirst-accelerate-your-business-communication-fo?ref=nav_search

---
Jim McCorison
Orcas Island, WA



> On Apr 12, 2017, at 3:14 PM, Rob Archibald <rob.archib...@endfirst.com> wrote:
> 
>   
>  
> <https://u4962376.ct.sendgrid.net/wf/click?upn=nWb4NotKf11TH6zl5B2z-2BlNs0qhJcxKea-2FaKbRR4hLEDvMouQJqEo6-2FaPOEqvJT20SZCCCFc2TlEy-2BUtRKSegxtUV9BXebLnYdbmI4tPf9do8TsRUqde25eQj5ZQcFN6-2Fmb5yqnjnLuE1kgsvsA7KedqSpRvidYi0kAofL-2FXOD1NXjT7M46eQt2xprIjml-2Bq7re2-2BXC286A0rXgOqwZIknb3yQu5nowNhvpJsq2oouBWMs3fffLpXfK9Je7JK2-2F-2BTm-2BL3A34ntUmtQg3aS2zHQ-3D-3D_o2usWWPei-2BYSYJCar36tcKE0vRozTbIPgejMlgcqhwO1bIsIJVoH5F3xVTZmN121Ps-2BfvPQrzyoS0crvf39zBco9rZEenk5ozVNEN3wqvO32Oex9l-2BmXb-2FzIhM4DrAVD5BtZCG3g78hYHDGjtxRD22IDt-2BO8M6F6ikdjpSd8g9m4TghRCncGQJsSou6inw3vONJSpEI-2B5nNlgG2cDdl4WKRLuHzfyr1itbMi-2BL5-2BQb8-3D>
> Check out my Kickstarter campaign! 
> <https://u4962376.ct.sendgrid.net/wf/click?upn=nWb4NotKf11TH6zl5B2z-2BlNs0qhJcxKea-2FaKbRR4hLEDvMouQJqEo6-2FaPOEqvJT20SZCCCFc2TlEy-2BUtRKSegxtUV9BXebLnYdbmI4tPf9do8TsRUqde25eQj5ZQcFN6-2Fmb5yqnjnLuE1kgsvsA7KedqSpRvidYi0kAofL-2FXOD1NXjT7M46eQt2xprIjml-2Bq7re2-2BXC286A0rXgOqwZIknb3yQu5nowNhvpJsq2oouBWMs3fffLpXfK9Je7JK2-2F-2BTm-2BL3A34ntUmtQg3aS2zHQ-3D-3D_o2usWWPei-2BYSYJCar36tcKE0vRozTbIPgejMlgcqhwO1bIsIJVoH5F3xVTZmN121Ps-2BfvPQrzyoS0crvf39zBdrq9I-2F-2BlwlHg-2FJIFS14N9ejqKIwnO0mr0v9Obm0E-2B-2Fb5frOZRSBqlFjtR0xGxKYEU0lbrj2Pzygj8Xvmk0Nrds2E2LthYdsWToCgCUKDK9ufHx5e6X2ugJgrNZTUYKtWF1extZY5Rfo-2BHaUAdXjoHI-3D>
> Hooray! I’m finally ready to launch my new business, EndFirst, on 
> Kickstarter! It has been a tough, but rewarding nearly 2 years since I left 
> Intel to start my own company. My goal was to create an awesome communication 
> service at the best price on the Internet. With your support, we can finish 
> our work and improve communication for businesses and organizations around 
> the world! In order to get the word out, I scoured all the emails I’ve sent 
> or received to find all of my music friends and associates, work colleagues, 
> neighbors, church friends, and more. I know you’re busy, but I’d love it if 
> you’d give me a few minutes of your time to help me launch my company. Please 
> check out our Kickstarter and contribute!
> 
>  
> <https://u4962376.ct.sendgrid.net/wf/click?upn=nWb4NotKf11TH6zl5B2z-2BlNs0qhJcxKea-2FaKbRR4hLEDvMouQJqEo6-2FaPOEqvJT20SZCCCFc2TlEy-2BUtRKSegxtUV9BXebLnYdbmI4tPf9do8TsRUqde25eQj5ZQcFN6-2Fmb5yqnjnLuE1kgsvsA7KedqSpRvidYi0kAofL-2FXOD1NXjT7M46eQt2xprIjml-2Bq7re2-2BXC286A0rXgOqwZIknb3yQu5nowNhvpJsq2oouBWMs3fffLpXfK9Je7JK2-2F-2BTm-2BL3A34ntUmtQg3aS2zHQ-3D-3D_o2usWWPei-2BYSYJCar36tcKE0vRozTbIPgejMlgcqhwO1bIsIJVoH5F3xVTZmN121Ps-2BfvPQrzyoS0crvf39zBZyPhW673rUCnDcWmqqSyXxh8db2DXN2KM-2BVNsa97xVuAqMS6g6Jbe1MrX-2BaaYSSLtxqEbBueuatkSo3sAJH1O9z2iKB-2FwXjJv-2BtQngN3bjSgffOq3UbgIW3gU68OlfgLXbzOhciRMFDGswaoZsJ-2FX0-3D>
> Order during the Kickstarter campaign and save 66% off the price of our 
> competitors. We offer the most powerful and inexpensive way for businesses 
> and organizations to communicate on the Internet. You'll get business email, 
> calendar, address book, file-storage and sharing, voice and video 
> conferencing, company instant messaging, to-do lists, collaborative document 
> editing and more! Happy communicating!
> 
> View Kickstarter Campaign 
> <https://u4962376.ct.sendgrid.net/wf/click?upn=nWb4NotKf11TH6zl5B2z-2BlNs0qhJcxKea-2FaKbRR4hLEDvMouQJqEo6-2FaPOEqvJT20SZCCCFc2TlEy-2BUtRKSegxtUV9BXebLnYdbmI4tPf9do8TsRUqde25eQj5ZQcFN6-2Fmb5yqnjnLuE1kgsvsA7KedqSpRvidYi0kAofL-2FXOD1NXjT7M46eQt2xprIjml-2Bq7re2-2BXC286A0rXgOqwZIknb3yQu5nowNhvpJsq2oouBWMs3fffLpXfK9Je7JK2-2F-2BTm-2BL3A34ntUmtQg3aS2zHQ-3D-3D_o2usWWPei-2BYSYJCar36tcKE0vRozTbIPgejMlgcqhwO1bIsIJVoH5F3xVTZmN121Ps-2BfvPQrzyoS0crvf39zBWCQs6HaIG-2Bwb-2FTTaK7w2REInjbd3I8NcK77RElWRLn9yLJZ1z-2Fc-2FxMnd8cj4pf4kfReACEqDin5xyE7xLrECo-2Bv5bjgUP86xp-2F2Nczhon0rGz1hLuYG0bm-2BFnns6tUZchVndQlvAev5xYU8hSYQQOk-3D>
> Blessings,
> Rob Archibald, CTO
> EndFirst LLC
> rob.archib...@endfirst.com <mailto:rob.archib...@endfirst.com> 
> 

Re: Where are bounce messages for milters configured?

[Jim Reid]

> On 10 Mar 2017, at 16:48, Linda Pagillo  wrote:
> 
> Also, is SMFIS_REJECT* even a file where I can configure a bounce message or 
> is it just a protocol which means "reject”.

SMFIS_REJECT is a status/error code in the milter protocol. What some milter 
application does when SMFIS_REJECT gets returned depends on that milter. 
Consult its documentation or read the software's source code. You might also 
find it helpful to read the milter documentation that is part of sendmail 
distribution since that includes the source code for building libmilter and its 
API which all milters depend on.

If you’re looking for advice here about a specific milter, it would help if you 
told the list which one you’re trying to configure. There’s bound to be someone 
on this list who will already be using that milter. But if you can’t/won’t say 
what that milter is, they won’t be able to guess that and therefore offer 
specific advice on how to go about configuring it or tailoring it to your 
needs. 

launchd plist files on MacOSX

[Jim Reid]

> On 3 Jan 2017, at 14:37, Robert Chalmers  wrote:
> 
> To start Postscript I use the following plist file. Based in 
> /Library/LaunchDaemons
> 
> org.postfix.master.plist 

Don’t do that. Pick names for your own plist files that don’t clash with the 
ones Apple use. There will be confusion if your plist files (in 
/Library/LaunchDaemons or wherever) have the same names as those in 
/System/Library/LaunchDaemons. For example, you think you’re running your own 
instance of postfix when the OS is actually running Apple’s. Or vice versa. Or 
both end up running and launchd eventually kills one of them since it’s had to 
restart that daemon too often because the daemon’s unable to listen on a port 
already used by the other instance.

It gets even worse if you install Apple Server software. That includes a script 
(cron job?) which secretly tells launchd to unload things like whatever bind 
and postfix is running and replace them with the Server-flavoured versions 
which are controlled from  
/Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons.

I found this out the hard way.

Re: DNS round robin on helo?

[Jim Reid]

> On 15 Dec 2016, at 16:01, L.P.H. van Belle <be...@bazuin.nl> wrote:
> 
> Hello Noel/Jim, 
>  
> Thank you for the replies. 

If you’re going to continue hiding the actual names and addresses, don’t bother 
posting followups. As far as I know, nobody on this list is a mind reader.

How do you expect anyone to help you if they don’t know what domain names and 
IP addresses are involved? How could anyone troubleshoot your problem when they 
don’t have that vital information?

Re: DNS round robin on helo?

[Jim Reid]

> On 15 Dec 2016, at 14:56, L.P.H. van Belle  wrote:
> 
> Now the thing i dont get. 
>  
> 1)   if both ipnumbers have a hostname, why do i see  : unknown[1.2.3.4]

Your starting assumption is wrong or mistaken. If the postfix logs are saying 
"unknown[1.2.3.4]” it means reverse lookups of that IP address are not 
returning a hostname.

You appear to have chosen to obscure the actual IP address and very probably 
the real domain names in the SMTP envelope (ie “helo==...”, etc) as well. So 
nobody here will be able to explain what is wrong or how to fix it.

This might be a DNS misconfiguration. Or it might be a fault in some locally 
deployed hostname-to-address mechanism like /etc/hosts or Active Directory or 
NIS(+) or...

> 2)   are Round Robin A record for mail Allowed.

Yes. Of course.

It’s very common for domains to have >1 IP address to handle inbound mail, 
particularly on busy mail services. For instance at the moment there are 70+ IP 
addresses handling incoming mail for hotmail.com. yahoo.com is currently 
advertising 24 IP addresses for inbound SMTP.

Re: TLD blocking revisited

[Jim Reid]

> On 21 Sep 2016, at 01:40, Sebastian Nielsen  wrote:
> 
> I would really suggest using DISCARD instead of "500 This TLD sends spam - g
> e t lost.".
> Thus the spammer dosen't get to know he got stuck in a spam filter and can
> update their tools to bypass it.

Spammers generally don’t pay that level of attention to SMTP responses, far 
less fine-tune their address lists and tools. These morons just find a victim 
host or botnet to blast out crap to a bazillion email addresses, not caring if 
any of them work or not or if their spam makes it as far as getting presented 
to a human victim. Then move on to the next victim host/botnet and repeat with 
the same list of a bazillion email addresses. Or an even bigger list. Once the 
spam generating software’s fingerprints eventually get spotted by SpamAssassin 
or whatever, a spammer will just throw that generator away and either tweak it 
a little or get a new one. Repeat.

FWIW I see the same bogus recipient email addresses (which never existed) 
repeatedly showing up in most of the spam attempts which arrive here. Clearly, 
those addresses are being swapped/traded by spammers or I have one very 
persistent spammer who only uses the same addresses over and over again. Either 
way, they don’t care that RCPT TO fails because they’re trying to deliver to 
email addresses that have never existed. If spammers did as you seem to think, 
these addresses would have been deleted from their lists a long time ago. They 
haven’t.

> DISCARD accepts the mail but throws it into /dev/null

True. But it means the spammmer still gets to burn your bandwidth and your CPU 
cycles as they deliver crap to your /dev/null. That does not seem sensible to 
me. YMMV.

Saying "500 This TLD sends spam - get lost” usually kills the SMTP session 
*well before* the DATA part of the handshake. So you don’t receive the spam 
payload. The message doesn’t get to your server. You also get the satisfaction 
of saying something rude back at the scumbag that was sending spam. Which eases 
the blood pressure even if it has no impact on that scumbag.

You’ve made your choices. I’ve made mine. We’re both happy with the ones we 
made.

Re: TLD blocking revisited

[Jim Reid]

> On 20 Sep 2016, at 21:10, li...@lazygranch.com wrote:
> 
> What is the simplest way to block a TLD?

Put the offending TLD in a map and have that map referenced through 
check_sender_access and/or check_client_access.

ie 

in main.cf:


smtpd_client_restrictions = permit_mynetworks

check_client_access hash:/etc/postfix/spamsources

mtpd_sender_restrictions = permit_mynetworks

check_sender_access hash:/etc/postfix/spamsources


and in /etc/postfix/spamsources:

xyz 500 This TLD sends spam - get lost.

Re: OpenBSD build 'OPENSSL_VERSION' undeclared

[Jim Reid]

> On 23 Aug 2016, at 20:44, David Benfell  wrote:
> 
> What I have now, which should not be considered complete because the dovecot 
> part isn't working

I’d bet money on that being caused by a broken OpenSSL installation too. Check 
your OpenSSL setup before you do *anything* else. References to this dubious 
(and unnecessary) eopenssl directory should be ringing alarm bells. You'll 
probably be best to nuke whatever OpenSSL stuff is in /usr/local and start 
again from scratch.

Re: OpenBSD build 'OPENSSL_VERSION' undeclared

[Jim Reid]

> On 23 Aug 2016, at 20:16, Wietse Venema  wrote:
> 
> David Benfell:
>> So now I have:
>> 
>> make tidy \
>>&& make makefiles CCARGS="-DUSE_TLS
>> -I/usr/local/include/eopenssl/openssl
> 
> Try: -I/usr/local/include/eopenssl

Looks like the OP made a typo when they orginally installed OpenSSL or had some 
port manager do that for them. Locally-installed OpenSSL include files are 
usually found in /usr/local/ssl/include and a symlink to that directory ends up 
(by hand?) in /usr/local/include/openssl. YMMV.

Re: Postscreen white listing based on MX, SPF

[Jim Reid]

> On 16 Jul 2016, at 02:50, Lefteris Tsintjelis  wrote:
> 
> I was thinking it more in simple DNS terms only and a simply reverse
> look up of the IP and then extract the domain from there but it is not
> possible without the FROM.

That wouldn’t have worked anyway.

Assuming a reverse lookup of an IP address returns a name -- a big if -- 
there’s no guarantee that name has any relation to whatever domain name is in 
the MAIL FROM.

For instance, lots of organisations outsource their email to specialised 
hosting/service providers. A MAIL FROM might well say example.com while the 
reverse lookup returns some name in $emailprovider.com for a server that’s 
delivering email sent by bazillions of customers.

Re: Is not honoring bounces-to violation of RFC?

[Jim Reid]

> On 28 Jun 2016, at 20:26, Jeffs Chips  wrote:
> 
> I'm just saying that ALL email campaign services allow and indeed suggest 
> users to identity a specific sole purpose email account in which to receive 
> bounces to eliminate spam and which almost all email campaigners adhere to

The IETF process is open to all. Feel free to make use of it.

BTW, the IETF is where Internet email protocols get developed and documented. 
It doesn’t and can’t happen on postfix-users. 

Re: Is not honoring bounces-to violation of RFC?

[Jim Reid]

> On 28 Jun 2016, at 19:28, Chip  wrote:
> 
> Okay maybe it's not in RFC's but I would it would be at least a 
> recommendation that bounces can be routed back to bounces-to rather than 
> reply-to.  After all, why have the field at all if it's not used properly.

No RFC defines a bounces-to email header. Or how an MTA or MUA should handle 
one. As a matter of fact, the only email-related RFC which contains the word 
“bounce” is RFC5355. Which is in the Experimental category. It uses “bounce" in 
the context of clients speaking UTF8SMTP to servers that don’t support this 
feature.

Here’s the relevant part of Section 4.4 of that RFC:

  Below are a few examples of possible  representations.

  ...

  "DISPLAY_NAME" 
 ; UTF8SMTP but no ALT-ADDRESS parameter provided,
 ; message will bounce if UTF8SMTP extension is not supported

  
 ; without DISPLAY_NAME and quoted string
 ; UTF8SMTP but no ALT-ADDRESS parameter provided,
 ; message will bounce if UTF8SMTP extension is not supported


If you think bounces-to has to be part of Internet email standards, feel free 
to write up a draft and submit it to the IETF.

Re: detecting /etc/resolv.conf

[Jim Reid]

> On 13 May 2016, at 09:56, Hans Ginzel  wrote:
> 
> Does Postfix detect changes in /etc/resolv.conf to flush its dns caches etc, 
> please?

Changing /etc/resolv.conf has no impact on what DNS data an application or name 
server has cached. All that can do is tell an application which name servers to 
query or what domain names to append to the strings in the queries it sends.

Applications generally just read /etc/resolv.conf exactly once when they start 
up. Most postfix processes tend to be short-lived. So they should pick up any 
changes to resolver configuration fairly soon (or even immediately) after 
/etc/resolv.conf has been updated. A “postfix reload” should be enough to 
ensure everything in the Postfix toolset makes use of the updated file.

It’s probably unwise to change /etc/resolv.conf in day-to-day operations. That 
file should only ever need to be modified after a full OS install or a major 
redesign of someone’s network and DNS setup.

Re: Is the reason for this "connect from unknown[65.181.123.80]" from NXDOMAIN? Is it safe to reject it always?

[Jim Reid]

> On 21 Apr 2016, at 20:46,   wrote:
> 
> What is "unknown" in this case?
> 
> I think it is the RDNS that is not there?

Yes. There’s no reverse DNS for the connecting IP address.

> host 65.181.123.80
> Host 80.123.181.65.in-addr.arpa. not found: 3(NXDOMAIN)

You should really use dig for DNS troubleshooting. Accept no subsitutes. Well, 
apart from delv or drill if you’re troubleshooting Secure DNS errors.

> I think a good mail server must always have the RDNS, yes? I am not 100% sure 
> that it is safe to reject this.

SMTP connections from an IP address with no reverse DNS is a *very strong* 
indication of a spam source. But it’s not 100% foolproof, particularly for IPv6.

IMO, anytbing that doesn’t have a working reverse DNS entry shouldn’t be 
sending email.

source code for MacOSX tools

[Jim Reid]

> On 13 Mar 2016, at 15:06, Robert Chalmers  wrote:
> 
> Nice hardware, but the software is really recycled FreeBSD. say what?

The MacOSX kernel is based on Mach, not BSD, though that Mach kernel presents a 
largely BSD-flavour/POSIX API to user mode applications. It might be fairer to 
say FreeBSD is recycled MacOSX given the engineering resources Apple has 
contributed to FreeBSD. :-)

Most MacOSX command line tools come from FreeBSD or GNU, apart from the obvious 
independent open source projects like postfix, openssl, BIND, ntpd and so on.

> So all I need - if I’m bothered, is the source of FreeBSD’s mail, and rebuild 
> it myself so it links to postfix’s sendmail where I want it properly.

Source code for the pretty much the entire OS excluding Apple’s GUI-based tools 
and the window manager can be downloaded from http://www.opensource.apple.com. 
You may be better off compiling from that instead of FreeBSD source so you know 
you’re starting from the same baseline code Apple is using. Maybe Apple have 
changed /usr/bin/mail somehow. They probably haven’t, but you'll never know for 
sure unless you check.

Some command line tools have been “enhanced" by Apple. For instance openssh has 
been hacked to work with Keychain and although the source code for those 
changes is freely available, it’s not yet found its way into the official 
openssh distribution.

working around System Integrity Protection on MacOSX

[Jim Reid]

> On 13 Mar 2016, at 14:07, Larry Stone  wrote:
> 
> The only “pain” likely to result is if you aren’t smart and let malware do 
> something bad. OS X (at least so far) does not care if SIP is on or off. SIP, 
> IMHO, is protection for those who don’t know what they are doing but is in 
> the way of us who know our way around a system.

Sadly, your opinion (and mine) don’t count. Apple’s decided System Integrity 
Protection matters and they get to choose. SIP’s likely to play even more 
significant role in future releases of MacOSX. [And maybe for iOS too.] I think 
Apple have already said that. So if you disable SIP or if workaround sysadmin 
practices rely on it being switched off, you may well be in for a nasty 
surprise or two further down the road. Says the guy who had /usr/src nuked when 
upgrading to MacOSX 10.11.

Re: Is /usr/bin/mail a link to sendmail/postfix

[Jim Reid]

> On 13 Mar 2016, at 08:41, Alice Wonder  wrote:
> 
> It's possible the mail command on OS X is using the OS X sendmail command 
> provided by the OS X postfix which would want its configuration file at 
> /etc/postfix/main.cf

It is. Though MacOSX puts the sendmail front-end in /usr/sbin:
% strings /usr/bin/mail | grep /
...
/usr/sbin/sendmail
...

> You may need to move the OS X sendmail command and make a symlink from 
> /usr/local/sbin/sendmail (as provided by postfix built from source) to 
> /sbin/sendmail (or wherever OS X keeps it) so that the right sendmail command 
> is available to OS X mail command.

Easier said than done. MacOSX 10.11 introduced System Integrity Protection. 
This means most, if not all, of the OS cannot be modified by anything unless 
the OS is booted in recovery mode and csrutil is used to disable or enable SIP. 
[Which probably explains why the Macs now boot twice during an upgrade: once in 
recovery mode to make the changes and then another to resume “normal” 
operations.] By default the SIP-protected directories and files include 
everything in /usr except /usr/local.

The path of least resistance would be to put the postfix config files in 
/etc/postfix where the Apple-supplied postfix tools expect to find them. Be 
sure to keep copies of these files elsewhere in case Apple stamps all over them 
at the next OS upgrade. Messing around with SIP settings or being clever with 
symbolic links is likely to end in pain, particularly when the next upgrade 
comes along.

pfctl on MacOSX

[Jim Reid]

> On 5 Mar 2016, at 15:38, Robert Chalmers  wrote:
> 
> Also, I can see that pfctl -e turns it on - enables it, but I can’t see how 
> that is put in place automatically. On re boot, it’s once again disabled, and 
> pf is not working. Even though the plist is loading.

Did you tell the OS to switch on the firewall? This is one of the configuration 
options under Security & Privacy in System Preferences.

If the firewall is disabled, I think there’s a setting somewhere deep in MacOSX 
which means nothing happens whenever /etc/pf.conf gets loaded. Which seems 
counter-intuitive: why load pf rulesets into the kernel if it's not going to 
use them?

Note that the MacOSX firewall is more than just pf. It can block or permit 
incoming and outgoing traffic on a per-application basis. Or restrict that to 
apps that have Apple-approved certificates. That extra granularity might be a 
lot of hassle, so a boot-time script which does a “pfctl -e” could be the path 
of least resistance.

hth

access permissions 101

[Jim Reid]

> On 19 Feb 2016, at 23:52, Sebastian Nielsen  wrote:
> 
> but if you're hosting for example a mail server for a company, and only you 
> as a sysadmin has shell access to the server, its no danger 666'ing files 
> that throw permission errors. Then the file isn't really "world writable", 
> since only you have a account on the server anyways.

This is a remarkably stupid and utterly irresponsible thing to say. It’s also 
wrong. Very, very wrong.

One of the fundamental principles of security is least privilege. Things get 
the minimum permissions/access rights/whatever that are needed for the task 
they have to perform.

So for postfix only some postfix processes need to have write access from time 
to time to specific files and directories. Almost nothing should ever need 
write access to postfix's configuration files, except for maybe postmap when 
rebuilding hash tables. So postfix's config files shouldn’t be writable by 
anyone, not even the postfix user.

Your starting assumption is also deeply flawed. A world-writable file can be 
written to by anything, not just the UIDs who have shell accounts. There will 
be other (or should be) UIDs and GIDs allocated to other services that run on 
the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man pages, 
TeX, FTP, etc, etc. That way if one of these things has a security leak, it can 
only write to that UID’s writable files (if there are any). The breakage can’t 
contaminate anything else. But if someone is stupid enough to intentionally 
make config files world-writable, these can be damaged by a security problem in 
a rogue application. This is why the TeX user (say) doesn’t get write access to 
the DNS or mail or MySQl or configuration. That UID doesn’t need those 
privileges. So it doesn’t get them. At least, not on any sensibly managed 
computer system.

The logical extension of your approach is to make the password file, kernel, 
shared library, etc world-writable. After all, you’re the only one who has 
shell access. And you never, ever make mistakes and no software vulnerabilities 
of any sort ever occur on the servers you manage - right?

If you were hosting mail for my business and I found out you’d *deliberately* 
set 666 permissions on the mail configuration files my company depended on, I’d 
sue you for gross negligence. And win.

Postfix and (Open)DKIM: Received Email?

[Jim Seymour]

Hi All,

I just installed, configured and have working OpenDKIM.  I can see
outgoing email is being properly signed, but not certain what it's doing
for me on the receiving side of things?

All the searching and reading I've done talks all about how to get it
going, and how to test your outgoing email, but not a word on what it
does for you on received email--e.g.: validating the signatures on same,
alerting you to mis-matches, or whatever?

Can somebody either enlighten me or point me in a direction in which I
might find enlightenment?

Thanks,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Re: Postfix and (Open)DKIM: Received Email?

[Jim Seymour]

On Thu, 24 Sep 2015 08:48:24 -0400 (EDT)
wie...@porcupine.org (Wietse Venema) wrote:

> Jim Seymour:
> > Hi All,
> > 
> > I just installed, configured and have working OpenDKIM.  I can see
> > outgoing email is being properly signed, but not certain what it's
> > doing for me on the receiving side of things?
> > 
> > All the searching and reading I've done talks all about how to get
> > it going, and how to test your outgoing email, but not a word on
> > what it does for you on received email--e.g.: validating the
> > signatures on same, alerting you to mis-matches, or whatever?
> > 
> > Can somebody either enlighten me or point me in a direction in
> > which I might find enlightenment?
> 
> The verifier can add a header to the message. However, DKIM does
> not specify a policy for how to handle failure.  You may want to
> look into DMARC for that.

Very well.  Thanks, Wietse.

Regards,
Jim
-- 
Note: My mail server employs *very* aggressive anti-spam
filtering.  If you reply to this email and your email is
rejected, please accept my apologies and let me know via my
web form at <http://jimsun.LinxNet.com/contact/scform.php>.

Re: postfix3.0.2 compile error on AIX61/71

[Jim Reid]

On 4 Sep 2015, at 23:43, Takae Harrington  wrote:

> does u_short/u_int, and unassigned makes difference?

Maybe, maybe not. Consult your C compiler documentation. BTW I assume you meant 
"unsigned" instead of "unassigned".

Though I doubt compiler documentation will help you because the definition of 
the ad field in this struct concerns the position of a single bit in the DNS 
header. It probably doesn't matter if that gets typed as an unsigned or u_int 
or whatever because it's just 1 bit. C compilers are usually not too fussy 
about bit field definitions. Maybe your C compiler cares about that, I don't 
know. (Or care: I've never used AIX and never will.) That said, the definitions 
found in your #include files should be appropriate for your C compiler.

If this struct really does have an ad field defined for the AD bit on your 
system, there may well be some AIX #ifdef goop somewhere else which is messing 
things up. Perhaps there's two or more struct HEADER definitions in 
/usr/include/arpa/nameser_compat.h and your C compiler is picking up the wrong 
one when it compiles postfix. You're on your own from this point if you want to 
continue. I can't help you fix or debug AIX #include files, even if I wanted 
to. Perhaps you can raise an internal support request inside IBM.

You also have the option of following the advice Viktor supplied yesterday.

Re: postfix3.0.2 compile error on AIX61/71

[Jim Reid]

On 4 Sep 2015, at 23:43, Takae Harrington  wrote:

> does u_short/u_int, and unassigned makes difference?

Maybe, maybe not. Consult your C compiler documentation. BTW I assume you meant 
"unsigned" instead of "unassigned".

Though I doubt compiler documentation will help you because the definition of 
the ad field in this struct concerns the position of a single bit in the DNS 
header. It probably doesn't matter if that gets typed as an unsigned or u_int 
or whatever because it's just 1 bit. C compilers are usually not too fussy 
about bit field definitions. Maybe your C compiler cares about that, I don't 
know. (Or care: I've never used AIX and never will.) That said, the definitions 
found in your #include files should be appropriate for your C compiler.

If this struct really does have an ad field defined for the AD bit on your 
system, there may well be some AIX #ifdef goop somewhere else which is messing 
things up. Perhaps there's two or more struct HEADER definitions in 
/usr/include/arpa/nameser_compat.h and your C compiler is picking up the wrong 
one when it compiles postfix. You're on your own from this point if you want to 
continue. I can't help you fix or debug AIX #include files, even if I wanted 
to. Perhaps you can raise an internal support request inside IBM.

You also have the option of following the advice Viktor supplied yesterday.

Re: postfix3.0.2 compile error on AIX61/71

[Jim Reid]

On 3 Sep 2015, at 22:11, Takae Harrington  wrote:

> When I compile postfix3.0.2 (the same issue has existed since 2.11.x) on 
> aix61 and aix71, I get this error:
> 
> [vq2ua613:/staging/Postfix-3.0.2]make
> dns_lookup.c: In function 'dns_query':
> dns_lookup.c:339: error: 'HEADER' has no member named 'ad'

It looks like the system #include files are broken or out of date. A HEADER 
typedef struct is usually defined in  which lays out the 
headers found in a DNS query. This should include a field "unsigned ad: 1;" for 
the AD (Authentic Data) bit which is used in Secure DNS. This 1-bit field 
appears to be missing from your include files. It shouldn't.

The AD bit has been part of the DNS protocol since 2005 and is defined in 
RFC4033.

Here's what you should see in that struct definition:

typedef struct {
unsignedid :16; /* query identification number */
#if BYTE_ORDER == BIG_ENDIAN
/* fields in third byte */
unsignedqr: 1;  /* response flag */
unsignedopcode: 4;  /* purpose of message */
unsignedaa: 1;  /* authoritive answer */
unsignedtc: 1;  /* truncated message */
unsignedrd: 1;  /* recursion desired */
/* fields in fourth byte */
unsignedra: 1;  /* recursion available */
unsignedunused :1;  /* unused bits (MBZ as of 4.9.3a3) */
unsignedad: 1;  /* authentic data from named */
unsignedcd: 1;  /* checking disabled by resolver */
unsignedrcode :4;   /* response code */
#endif
#if BYTE_ORDER == LITTLE_ENDIAN || BYTE_ORDER == PDP_ENDIAN
/* fields in third byte */
unsignedrd :1;  /* recursion desired */
unsignedtc :1;  /* truncated message */
unsignedaa :1;  /* authoritive answer */
unsignedopcode :4;  /* purpose of message */
unsignedqr :1;  /* response flag */
/* fields in fourth byte */
unsignedrcode :4;   /* response code */
unsignedcd: 1;  /* checking disabled by resolver */
unsignedad: 1;  /* authentic data from named */
unsignedunused :1;  /* unused bits (MBZ as of 4.9.3a3) */
unsignedra :1;  /* recursion available */
#endif
/* remaining bytes */
unsignedqdcount :16;/* number of question entries */
unsignedancount :16;/* number of answer entries */
unsignednscount :16;/* number of authority entries */
unsignedarcount :16;/* number of resource entries */
} HEADER;

Re: Postfix and Mailman 2 virtual alias domain integration

[Jim Reid]

On 18 Aug 2015, at 22:06, Tom Browder tom.brow...@gmail.com wrote:

 Okay, I assume then that this should be the only PTR record:
 
 4.3.2.1.in-addr.arpa. IN PTR B.tld.

Yes. Provided of course B.tld is The One True Hostname for your server.

BTW, you will get on a lot better if your postings used the actual IP addresses 
and domain names rather than hide these behind nonsense like B.tld and 1.2.3.4. 
Obscuring this information helps nobody, especially yourself.

Re: Postfix and Mailman 2 virtual alias domain integration

[Jim Reid]

On 18 Aug 2015, at 21:55, Tom Browder tom.brow...@gmail.com wrote:

 Okay, now assuming my server IP address is 1.2.3.4, do the following
 DNS records appear reasonable?

No. There should be just one PTR record for an IP address.