Re: "Authentication-Results" header order

[PGNet Dev]

On 7/4/21 4:10 PM, Juri Haberland wrote:

On 03/07/2021 13:29, Markus E. wrote:


By the way, I like the way Google merges the headers into one, like:


an additional option is:

https://github.com/fastmail/authentication_milter

very config'able, a typical header appears as:

Authentication-Results: auth-milter.example.com;
arc=none (no signatures found);
dkim=pass (1024-bit rsa key sha256) header.d=example.net
  header.i=@example.net header.b=l1y+dUDe header.a=rsa-sha256
  header.s=may2015;
dmarc=pass policy.published-domain-policy=none
  policy.applied-disposition=none policy.evaluated-disposition=none
  (p=none,d=none,d.eval=none) policy.policy-from=p
  header.from=example.net;
iprev=pass smtp.remote-ip=yyy.yyy.yyy.yyy (subd.example.net);
spf=pass
  smtp.mailfrom=
  "bounces+213868-70ac-p.t=example@sg.example.net"
  smtp.helo=subd.example.net;
x-ptr=pass smtp.helo=subd.example.net policy.ptr=subd.example.net;
x-return-mx=pass header.domain=example.net policy.is_org=yes
  (MX Records found: mx0a-xxx.pphosted.com,mx0b-xxx.pphosted.com);
x-return-mx=warn smtp.domain=sg.example.net
  policy.org_domain=example.net policy.is_org=no
  (A Records found: xxx.xxx.xxx.xxx);
x-tls=pass smtp.version=TLSv1.3 smtp.cipher=TLS_CHACHA20_POLY1305_SHA256
  smtp.bits=256/256


it's a trivial install with cpan ... and plays nicely with postfix.

Re: Can send but not receive

[PGNet Dev]

On 7/8/21 1:59 PM, techli...@phpcoderusa.com wrote:

Any thought how I can troubleshoot this?


map out your traffic one step at a time.

connect with

openssl s_client
curl

from an external server, and manually exec an smtp transaction.

&/or, less convenietly, (re)send mail from an external mail account, gmail or 
somesuch.

exec tcpdump on each of your listening interfaces/ports, and turn on verbose 
logging on all your server listeners (named, postfix & dovecot), and identify 
where the traffic flows to, and where it stops.

Re: Stopping backscatter spam to a specific domain

[PGNet Dev]

On 7/11/21 3:46 PM, Ron Garret wrote:

Ah.  That may be my problem then.  I’m using Dovecot via LMTP for local 
delivery.  I thought that postfix would receive information about non-existent 
users via that protocol, but I guess it doesn’t and ends up just accepting 
everything.

So… is dovecot actually the thing that is generating the emails from 
mailer-daemon?  Is there a way to get this setup to do the Right Thing?  If 
not, why is LMTP even supported, because it seems to me that anyone who uses it 
will have this problem.

(FYI, the reason I want to use LMTP is that I’m using sqlite for my user db, 
but postfix does not play well with sqlite when other programs are trying to 
access the same DB.  I didn’t want to duplicate the user DB (I’m a big believer 
in the DRY principle) so I wanted to localize DB access to a single process, 
and that process has to be Dovecot.)


You've an additional option.

RECIPIENT ADDRESS VERIFICATION

read-up @

http://www.postfix.org/ADDRESS_VERIFICATION_README.html
http://www.postfix.org/verify.8.html
http://www.postfix.org/postconf.5.html#relay_recipient_maps
http://www.postfix.org/ADDRESS_CLASS_README.html

e.g., I run an external instance of postfix that smtp relays mail that passes 
all my 'heavy' filtering (postscreen, spam, virus, other milters, etc) to a 
lightweight internal instance of postfix+dovecot over a non-public , secure 
connection.

The internal postfix/dovecot instances share an sqlite3 DB, managed via 
postfixadmin (https://postfixadmin.sourceforge.io)
Postfixadmin's DB contains only valid addresses; both postfix and dovecot on 
that instance 'see' the same list.

This DB is local only, no user DB (other than postfix cache) exists on the 
external DB.  I.e., single process DB access, and no DB duplication, and that 
process is Dovecot(+ the internal postfix instance)

By leaving blank, in main.cf on the external instance

relay_recipient_maps =

"the Postfix SMTP server accepts all recipients for domains listed with the 
relay_domains parameter".  Once that criterion is met, an address verification probe 
is then exec'd 'by' the external instance 'against' the internal postfix instance's 
recipient list, fed by that shared DB list.

no matching entry? not a valid recipient.  internal instance notifies external 
instance, which rejects accordingly.

Not everyone's cup-of-tea, but works perfectly for me.

Re: Conditional milter_header_checks?

[PGNet Dev]

On 7/13/21 6:06 PM, post...@ptld.com wrote:

I am not meaning to confrontational, i want to develop a deeper understanding 
and educate myself.


your issues are not with Postfix, & likely won't be further addressed/solved 
here



they're with your understanding of DMARC policy/usage, and the parts that DKIM, 
SPF, etc play



might be useful to read up on DMARC policy





 https://dmarc.org/



 https://powerdmarc.com/what-is-dmarc-policy/



 https://www.dmarcanalyzer.com/what-is-a-dmarc-policy/




and usage,





 Set Up OpenDMARC with Postfix on Ubuntu to Block Spam/Email Spoofing



  https://www.linuxbabe.com/mail-server/opendmarc-postfix-ubuntu

heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

[PGNet Dev]

i've reported the bug here,

 python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must be 
defined for '#' formats"
  https://bugs.launchpad.net/dkimpy-milter/+bug/1949520

fwiw, python 3.9 still works as expected

now to poke at it ...

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

[PGNet Dev]

On 11/2/21 16:26, Scott Kitterman wrote:

Thanks.  From the error message, that looks like something from the Python C 
API, so it's almost certainly in the pymilter Python binding for libmilter, not 
in dkimpy-milter itself.


+1

https://github.com/sdgathman/pymilter/issues/44

thx

Re: heads up: dkimpy-milter signing breaks w/ python 3.10 (e.g., @ fedora 45 -> 35 upgrade)

[PGNet Dev]

On 11/2/21 16:26, Scott Kitterman wrote:



On November 2, 2021 8:18:54 PM UTC, PGNet Dev  wrote:


i've reported the bug here,

  python 3.10 incompat, exec FAILs @ "SystemError: PY_SSIZE_T_CLEAN macro must be 
defined for '#' formats"
   https://bugs.launchpad.net/dkimpy-milter/+bug/1949520

fwiw, python 3.9 still works as expected

now to poke at it ...



Thanks.  From the error message, that looks like something from the Python C 
API, so it's almost certainly in the pymilter Python binding for libmilter, not 
in dkimpy-milter itself.


fyi,

upstream pymilter's fixed the issue

 https://github.com/sdgathman/pymilter/issues/44

using (for now), pymilter from git main, dkimpy-milter signing with python 3.10 
is again functional

after adding IPv6 config, getting fail on submission -> "fatal: open dictionary: expecting "type:name" form instead of "::1"" ?

[PGNet Dev]

I'm trying to add IPv6 addresses to a previously IPv4-only/working 
internal-network submission node (mx1); the node receives submissions from 
another sending postfix instance (mx2)

I've botched something, & am getting an error I don't yet recognize/understand,

fatal: open dictionary: expecting "type:name" form instead of "::1"

, and am not sure where to look for the cause.

any clues appreciated!

the submission node's master.conf contains

[internal.mx2.example.loc]:465 inet n - n - - smtpd -v
 -o syslog_name=postfix/submit-from-mx2-backend
 -o smtpd_banner=internal.mx2.example.loc.465
 -o receive_override_options=no_unknown_recipient_checks
 -o smtpd_milters=unix:/run/dkimpy-milter/dkimpy-milter.sock
 -o milter_macro_daemon_name=DKIM_ORIGINATING
 -o smtpd_tls_loglevel=1
 -o smtpd_tls_security_level=secure
 -o smtpd_tls_wrappermode=yes
 -o smtpd_tls_auth_only=yes
 -o 
tls_high_cipherlist=TLS13-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305
 -o smtpd_tls_mandatory_protocols=!TLSv1.1,!TLSv1,!SSLv3,!SSLv2
 -o smtpd_tls_mandatory_ciphers=high
 -o smtpd_sasl_auth_enable=no
 -o tls_append_default_CA=no
 -o smtpd_tls_CAfile=${ssl_keys_dir}/myCA.CHAIN.crt.pem
 -o 
smtpd_tls_cert_file=${ssl_keys_dir}/internal.mx2.example.loc.server.EC.crt.pem
 -o 
smtpd_tls_key_file=${ssl_keys_dir}/internal.mx2.example.loc.server.EC.key.pem
 -o 
smtpd_authorized_xforward_hosts=127.0.0.0/8,[::1],10.16.1.50,10.16.2.100,[fd72:16:1::50],[fd72:16:2::100]
 -o 
mynetworks=127.0.0.0/8,[::1],10.16.1.50,10.16.2.100,[fd72:16:1::50],[fd72:16:2::100]
 -o smtpd_client_restrictions=permit_mynetworks,reject
 -o smtpd_helo_restrictions=
 -o smtpd_sender_restrictions=
 -o smtpd_tls_fingerprint_digest=sha256
 -o 
relay_clientcerts=${default_database_type}:${config_directory}/local/smarthost_clientcerts
 -o smtpd_tls_req_ccert=yes
 -o smtpd_tls_ccert_verifydepth=2
 -o smtpd_relay_restrictions=permit_tls_clientcerts,reject
 -o smtpd_recipient_restrictions=
 -o smtpd_data_restrictions=
 -o smtpd_end_of_data_restrictions=
 -o smtpd_etrn_restrictions=
 -o smtpd_discard_ehlo_keywords=chunking,etrn,silent-discard
 -o cleanup_service_name=cleanup-out

on mail send exec, at the sending instance,

2022-01-03T10:22:39.111475-05:00 mx2 
postfix/submit-from-dovecot-proxy/smtpd[21516]: connect from 
mx2.example.lan[fd72:16:1::50]
2022-01-03T10:22:39.315190-05:00 mx2 
postfix/submit-from-dovecot-proxy/smtpd[21516]: Trusted TLS connection 
established from mx2.example.lan[fd72:16:1::50]: TLSv1.3 with cipher 
TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 
server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA 
(P-384) client-digest SHA384
2022-01-03T10:22:39.324339-05:00 mx2 
postfix/submit-from-dovecot-proxy/smtpd[21516]: 4JSKHg2Hd8zWf7L: 
client=mx2.example.lan[fd72:16:1::50]
2022-01-03T10:22:39.389270-05:00 mx2 postfix/qmgr[17689]: 4JSKHg2Hd8zWf7L: 
from=, size=910, nrcpt=1 (queue active)
2022-01-03T10:22:39.399889-05:00 mx2 
postfix/submit-from-dovecot-proxy/smtpd[21516]: disconnect from 
mx2.example.lan[fd72:16:1::50] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5

it appears to be an OK submission.

but, at the receiving submission node

2022-01-03T10:23:15.639273-05:00 mx1 postfix/smtpd[7724]: name_mask: 
ipv4
2022-01-03T10:23:15.639722-05:00 mx1 postfix/smtpd[7724]: name_mask: 
ipv6
2022-01-03T10:23:15.640130-05:00 mx1 postfix/smtpd[7724]: 
inet_addr_local: configured 9 IPv4 addresses
2022-01-03T10:23:15.640248-05:00 mx1 postfix/smtpd[7724]: 
inet_addr_local: configured 11 IPv6 addresses
2022-01-03T10:23:15.640571-05:00 mx1 
postfix/submit-from-mx2-backend/smtpd[7724]: process generation: 17 (17)
2022-01-03T10:23:15.640672-05:00 mx1 postfix/submit-from-mx2-backend/smtpd[7724]: fatal: 
open dictionary: expecting "type:name" form instead of "::1"
2022-01-03T10:23:16.641888-05:00 mx1 postfix/master[7632]: warning: 
process /usr/libexec/postfix/smtpd pid 7724 exit status 1
2022-01-03T10:23:16.642172-05:00 mx1 postfix/master[7632]: warning: 
/usr/libexec/postfix/smtpd: bad command startup -- throttling

I see the fail.

iiuc, the fail is *at* the submission node -- but unclear to me whether it's 
caused there, or something in my sending instance.

what/where is that

expecting "type:name" form instead of "::1"

telling me something is broken?  sending &/or receiving end?

Re: after adding IPv6 config, getting fail on submission -> "fatal: open dictionary: expecting "type:name" form instead of "::1"" ?

[PGNet Dev]

On 1/3/22 11:03, Wietse Venema wrote:

There's a 'bare' ::1 where [::1] is needed.
To find these in main.cf or master.cf:

postconf | grep  '[^[]::1'
postconf -P | grep '[^[]::1'

The 'bare' ::1 may also appear in a /file/name that is referenced
by mynetworks or by some other Postfix feature. There's no simple
grep command for that.


ah.  didn't clue in that that error suggests 'bare' IPv6 :-/

grep'ing, found bare '::1' in both

smtpd_authorized_xclient_hosts
smtpd_authorized_xforward_hosts

in docs,

Note: IP version 6 address information must be specified inside [] in the 
smtpd_authorized_xclient_hosts value, and in files specified with "/file/name". IP version 6 
addresses contain the ":" character, and would otherwise be confused with a "type:table" 
pattern.

i'd taken care of 'mynetworks', but not those.

i'd searched on the error-referenced "type:name" _in_ the docs, but the 
'smtpd_authorized_xclient_hosts' & 'smtpd_authorized_xforward_hosts' entries @ 
http://www.postfix.org/postconf.5.html mention "type:table" rather than "type:name".

now that I know, it's not an issue for me; if practical, could be useful for others 
to tie the error to the docs' " ...

mail's flowing again, now _with_ IPv6 in place.

thanks!

"ignoring DNS RR:" for only google.com MX ?

[PGNet Dev]

in the process of turning on IPv6,

send to public 'net via my outbound smtp instance,

smtp-out-ext  unix  -  -  n  -  -  smtp
  -o syslog_name=postfix/smtp-out-ext
  -o smtp_line_length_limit=990
  -o smtp_tls_security_level=dane
  -o 
smtp_tls_policy_maps=${default_database_type}:${config_directory}/local/outbound_tls_policy
  -o smtp_tls_loglevel=1
  -o smtp_helo_name=mx1.example.net
  -o smtp_bind_address=$var_MX1_IPv4

i notice now, with every/only sent message to gmail/google, a bunch of "ignoring DNS 
RR:" log entries,

2022-01-03T11:31:06.194561-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
ignoring DNS RR: gmail-smtp-in.l.google.com. 284 IN  2607:f8b0:400d:c0d::1a
2022-01-03T11:31:06.195531-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
ignoring DNS RR: alt1.gmail-smtp-in.l.google.com. 30 IN  
2800:3f0:4003:c00::1a
2022-01-03T11:31:06.196617-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
ignoring DNS RR: alt2.gmail-smtp-in.l.google.com. 235 IN  
2a00:1450:400b:c00::1b
2022-01-03T11:31:06.197766-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
ignoring DNS RR: alt3.gmail-smtp-in.l.google.com. 136 IN  
2a00:1450:400c:c0b::1a
2022-01-03T11:31:06.198683-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
ignoring DNS RR: alt4.gmail-smtp-in.l.google.com. 35 IN  
2a00:1450:4013:c16::1b
2022-01-03T11:31:06.287943-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
Untrusted TLS connection established to 
gmail-smtp-in.l.google.com[173.194.175.26]:25: TLSv1.3 with cipher 
TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 
server-signature ECDSA (P-256) server-digest SHA256
2022-01-03T11:31:06.655409-05:00 mx1 postfix/smtp-out-ext/smtp[14518]: 
4DEDAQ3aFed1a: to=<@gmail.com>, 
relay=gmail-smtp-in.l.google.com[173.194.175.26]:25, delay=0.57, 
delays=0.1/0.01/0.13/0.33, dsn=2.0.0, status=sent (250 2.0.0 OK  1641228163 
e3sda542e62dq1e.468 - gsmtp)
2022-01-03T11:31:06.655941-05:00 mx1 postfix/qmgr[14487]: 
4DEDAQ3aFed1a: removed

the msg hails from

./postfix/src/dns/dns_rr_filter.c
...
/* dns_rr_action - execute action from filter map */

static DNS_RR *dns_rr_action(const char *cmd, DNS_RR *rr, const 
char *rr_text)
{
const char *cmd_args = cmd + strcspn(cmd, " \t");
int cmd_len = cmd_args - cmd;

while (*cmd_args && ISSPACE(*cmd_args))
cmd_args++;

#define STREQUAL(x,y,l) (strncasecmp((x), (y), (l)) == 0 && 
(y)[l] == 0)

105 if (STREQUAL(cmd, "IGNORE", cmd_len)) {
106 msg_info("ignoring DNS RR: %s", rr_text);
return (0);
} else {
msg_warn("%s: unknown DNS filter action: \"%s\"",
 dns_rr_filter_maps->title, cmd);
return (dns_rr_filter_error);
}
return (rr);
}
...

looking for that IGNORE in my setup finds,

cat ./local/smtp_dns_reply_filter.pcre
# <- Wietse Venema:
#  force IPv4 for all domains that have Google as an MX host.
#  This drops all  records from Google MX hosts,
#  effectively forcing Postfix to deliver over IPv4.
#  /domain ttl IN  address/ action, all case-insensitive.
#  Note: the domain name ends in ".".
/^\S+\.google.com\.\s+\S+\s+\S+\s+\s+/ IGNORE

where

grep smtp_dns_reply_filter main.cf
smtp_dns_reply_filter = 
pcre:/usr/local/etc/postfix/local/smtp_dns_reply_filter.pcre

per the comment, i must've added that 'on advice' here at ML.

unfortunately, my notes are missing any ML date/reference (looking for it ...) 
:-/
afaik, could've been 'my' problem, or google's.

i _suspect_ it's due to (for now) my public postfix IP binds service only on 
IPv4 -- i.e.,

-o smtp_bind_address=$var_MX1_IPv4

offhand, is that generally needed/beneficial for google.com MXs?

Re: "ignoring DNS RR:" for only google.com MX ?

[PGNet Dev]

On 1/3/22 18:15, Viktor Dukhovni wrote:

On Mon, Jan 03, 2022 at 12:32:03PM -0500, Wietse Venema wrote:


offhand, is that generally needed/beneficial for google.com MXs?


I don't know, does anyone want to be the guinea pig and discover
if they still randomly bounce email over IPv6?


Last I heard the Google MX host policy is not quite that capricious,
but messages over IPv6 are expected to tick more checklist boxes,
by e.g. having DKIM signatures, and perhaps other "best practice"
markers of being a "mainstream" MTA.


once I realized that _I_ hadn't asked the question ... but borrowed the answer 
from another thread, I found what appears to be the (a?) relevant, 2014 thread:

  https://groups.google.com/g/mailing.postfix.users/c/8SHkC2GdttI

in my case here, postfix generally checks most of the usual suspect checklist 
boxes.  DANE deployment is still a bit intermittent here, but don't think it's 
on those 'checklists' ... yet.

as to whether @google has improved sufficiently since 2014 to warrant getting 
rid of this, dunno yet.

testssl reports issues with "Session Resumption" & "OCSP stapling" ; expected status/use for Postfix?

[PGNet Dev]

i'm prepping postfix tls on the way to DANE implementation

current check with

testssl -t smtp mx.example.com:25

reports,

 Testing server defaults (Server Hello)

 TLS extensions (standard)"renegotiation info/#65281" "EC point formats/#11" 
"session ticket/#35"
  "supported versions/#43" "key share/#51" "max 
fragment length/#1"
  "extended master secret/#23"
 Session Ticket RFC 5077 hint 7200 seconds, session tickets keys seems to 
be rotated < daily
 SSL Session ID support   yes
???  Session Resumption   Tickets: yes, ID resumption test failed, 
pls report
 TLS clock skew   Random values, no fingerprinting possible

  Server Certificate #1
   Signature Algorithm  SHA256 with RSA
   Server key size  RSA 4096 bits
...
   Issuer   R3 (Let's Encrypt from US)
...
   OCSP URI http://r3.o.lencr.org
   OCSP staplingnot offered
???OCSP must staple extension   requires OCSP stapling (NOT ok)
...
  Server Certificate #2
   Signature Algorithm  SHA256 with RSA
   Server key size  EC 384 bits
...
   Issuer   R3 (Let's Encrypt from US)
...
   OCSP URI http://r3.o.lencr.org
   OCSP staplingnot offered
???OCSP must staple extension   requires OCSP stapling (NOT ok)


From comments I've found (not yet anything official),

"OCSP staplingnot offered"

for Postfix is

(1) expected
(2) won't change
(3) doens't 'break' any operation, using the LE certs

Is that correct?  I.e., can be safely ignored?


The other ??? item,

"Session Resumption   Tickets: yes, ID resumption test failed, pls 
report"

I've not found any guidance on at all, yet.

For postfix, do I care?
And if so, what/where is a fix?

Re: testssl reports issues with "Session Resumption" & "OCSP stapling" ; expected status/use for Postfix?

[PGNet Dev]

The other ??? item,

 "Session Resumption   Tickets: yes, ID resumption test failed, pls 
report"

I've not found any guidance on at all, yet.

For postfix, do I care?
And if so, what/where is a fix?


did find this comment at SF,

"Certbot — Post-Handshake New Session Ticket arrived"
 
https://serverfault.com/questions/1034382/certbot-post-handshake-new-session-ticket-arrived#comment1349580_1034382

"You are using a server that supports TLS 1.3, and testing with 
OpenSSL 1.1.1 which also does so. The secure-renegotiation extension (RFC5756) is no 
longer used or needed in 1.3 because it no longer does any renegotiation, or even 
resumption with prior secret. Yes there may be multiple 'tickets' in 1.3; the protocol is 
changed so that they aren't really tickets, just saved PSKs. This is all explained in the 
1.3 spec, RFC8446"

led eventually to this @ openssl ML, which is related (?)

"[openssl-project] OpenSSL 1.1.1 library(OpenSSL 1.1.0 compile) Postfix to 
Postfix test"
 
https://mta.openssl.org/pipermail/openssl-project/2018-April/000671.html

"The only interesting observations are:

* With TLS 1.3 a new session is generated even sessions are
resumed, because the server responds with a new ticket
in the event of session resumption.  With TLS 1.2 
sessions
that had sufficient remaining lifetime did not trigger 
new
ticket generation on the server, and no new session was
stored on the client.  This causes needless 
wear-and-tear
on the external session cache in Postfix, since each
connection writes out a new session, replacing the one
it just used.  Some might consider this a security 
feature,
but it is not especially desirable with SMTP.  Any 
thoughts
about whether this could be tunable?  It would have to 
be
server-side tuning I think, since the client does not 
know
why the server issued a new session, perhaps the old one
was not (or will soon not) be valid for re-use."

and downthread comes to some agreement, but I've missed what server-side 
tunable knob in postfix to use, or if needed.

unclear if this is a red-herring, and can/should just be ignored in Postfix, 
when tested by testssl ...

Re: testssl reports issues with "Session Resumption" & "OCSP stapling" ; expected status/use for Postfix?

[PGNet Dev]

Session ID resumption is by default disabled.  This is a feature, let
the client store a session ticket if it wants, otherwise it does a fresh
handshake.  This makes sense for SMTP.


   OCSP staplingnot offered
???OCSP must staple extension   requires OCSP stapling (NOT ok)


You made the mistake of using the "--must-staple" flag with certbot, or
some equivalent way to elicit this certificate feature.


bingo.

my generator wrapper script around acme.sh handled initial cert generation for 
all my domains --

& has a default of

  --ocsp-must-staple --ocsp

good for all the web certs.  as you point out, not for postfix.

an oversight.


Don't do that.


+1 . an easy fix. thx.


Postfix has no CRL or OCSP support, and none is planned.


other than reporting the bad result, does the current (bad) config cause any 
actual mail delivery breakage?

i've clearly not noticed my mistake 'til now, and afaict have seen no 
unexplained breakage.
dunno if i should've and missed it, or it's just noisy and ignorable?


The other ??? item,

"Session Resumption   Tickets: yes, ID resumption test failed, pls 
report"


This is expected, nothing to worry about.


+1


Matt Caswell and I had a chat about this and session ticket issuance was
made more configurable and backwards-compatible in a subsequent OpenSSL
1.1.1 release.  OpenSSL 1.1.1 and later
now honour the ticket callback signal to reuse the existing ticket.  If
you observe something else, let me know.

Resumption with a previously obtained and still fresh ticket should not
elicit yet another ticket.  Unless "posttls-finger" fails to log the
unwanted ticket this appears to still be working:

 $ posttls-finger -Lssl-debug,verbose -r3 -c amnesiac
 ...
There's no "read server session ticket" logged after resumption.


Here, appears ~ the same

with

 postconf mail_version
  mail_version = 3.6.3
 openssl version
  OpenSSL 1.1.1l  FIPS 24 Aug 2021

exec

 posttls-finger -Lssl-debug,verbose -r3 -c mx.example.com

...
posttls-finger: certificate verification failed for 
mx.example.com[192.0.2.12]:25: untrusted issuer /O=Digital Signature Trust 
Co./CN=DST Root CA X3
posttls-finger: mx.example.com[192.0.2.12]:25: 
subject_CN=mx.example.com, issuer_CN=R3, fingerprint=26:...:64
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSL negotiation finished successfully
-->  posttls-finger: SSL_connect:SSLv3/TLS read server session ticket
posttls-finger: Reconnecting after 3 seconds
posttls-finger: looking for session 
[192.0.2.12]:25&103B4B1F4A5BBF379DCD2EE9B618B03309F956ED7A7D865743E12E6B275A6E95
 in memory cache
posttls-finger: reloaded session 
[192.0.2.12]:25&103B4B1F4A5BBF379DCD2EE9B618B03309F956ED7A7D865743E12E6B275A6E95
 from memory cache
posttls-finger: SSL_connect:before SSL initialization
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
posttls-finger: SSL_connect:SSLv3/TLS read finished
posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
posttls-finger: SSL_connect:SSLv3/TLS write finished
posttls-finger: mx.example.com[192.0.2.12]:25: Reusing old session
posttls-finger: mx.example.com[192.0.2.12]:25: re-using session with 
untrusted certificate, look for details earlier in the log
posttls-finger: Untrusted TLS connection established to 
mx.example.com[192.0.2.12]:25: TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 
(256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)
posttls-finger: Found a previously used server.  Done reconnecting.

, except for the

re-using session with untrusted certificate

which I need to investigate.  my certs are LE-issued public certs.  dunno yet why I've 
got an "untrusted issuer" rattling around.

Re: testssl reports issues with "Session Resumption" & "OCSP stapling" ; expected status/use for Postfix?

[PGNet Dev]

i've clearly not noticed my mistake 'til now, and afaict have seen no
unexplained breakage.  dunno if i should've and missed it, or it's
just noisy and ignorable?


Best to not solicit misbehaviour, even if typically nothing bad happens.


sure. not hoping to avoid fixing it!  asking if i should've/could've known 
without running the testssl etc check.

i.e., was there something in postfix logs that I missed? or haven't logged at 
sufficient levels to see?


which I need to investigate.  my certs are LE-issued public certs.  dunno yet why I've 
got an "untrusted issuer" rattling around.


This is expected and normal. Postfix has an empty set of trusted issuers
by default, which avoids wasting time verifying certificates when the
result is ignored anyway.  You can use the "-F " and/or the
"-P " options if you want to go through the motions of doing
WebPKI chain verification.


+1


Absent DANE, this is all security theatre.


yup.  which is why i'm doing the step1 cleanups etc to get my own mistakes out 
of the way ... on the way to DNSSEC/DANE.

thx.

Re: testssl reports issues with "Session Resumption" & "OCSP stapling" ; expected status/use for Postfix?

[PGNet Dev]

yup, I have separate certs for mail & web.  i'd just mistakenly added the ocsp 
opts to all.
quick fixed the mail cert, removing it; web certs keep it 'on', here.

testssl check of mail cert now confirms:
...
   Certificate Revocation List  --
   OCSP URI http://r3.o.lencr.org
   OCSP staplingnot offered
   OCSP must staple extension   --
...

tlsa/dane "3 1 1" usage is noted

thx for the 'danectl' script.
i've my own key/record mgmt script that deals with my distributed dns, web & 
mail servers. for LE-certs, DNSSEC, etc -- acme-based.
works well enough. especially, as mentioned, with the bind9 integrations for 
key mgmt.

yes, registrars' general lack of support for CDS/CDNSKEY is ... annoying.  from mine, 
i've got years of 'assurances' that "we're working on it.  it'll be done in 2-3 
months".
of course, not so much :-/  still 'someday' for _full_ automation.

thx all!

Re: TLS ciphers

[PGNet Dev]

for those following along, I find this a useful, summary reference

 Hands-on: implementing DANE in PostfixCryptographic security for mail transport
  https://www.sidn.nl/en/news-and-blogs/hands-on-implementing-dane-in-postfix

Re: GhettoForge Postfix3

[PGNet Dev]

Are there other options (repos) for getting current versions of Postfix using 
dnf on a RHEL system?


fwiw,

use existing pkgs from https://src.fedoraproject.org/rpms/postfix for 'Fedora 
ELN, if that fits your needs

or rebuild & package from those sources, or your own tweaked/modified .spec, on 
your own COPR (https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/), 
specifically for your chroot of choice

Fedora COPR certainly a variety of EPEL chroots, including 9,

  https://communityblog.fedoraproject.org/epel-9-is-now-available/

i regularly rebuild the rawhide sources, which only slightly/ocassionaly lag 
new Postfix releases, for F35 for production use; works a charm.

Re: Doing something wrong.

[PGNet Dev]

following along & just curious, i checked a postfix 3.6.3 here that's using 
LetsEncrypt certs, where conf includes

smtpd_tls_cert_file = /usr/local/etc/postfix/sec/fullchain.rsa.crt.pem
smtpd_tls_eccert_file = /usr/local/etc/postfix/sec/fullchain.ec.crt.pem
smtpd_tls_eckey_file = /usr/local/etc/postfix/sec/priv.ec.key
smtpd_tls_key_file = /usr/local/etc/postfix/sec/priv.rsa.key

cert verification FAILs

posttls-finger -cC -lsecure '[mx.example.com]'
posttls-finger: certificate verification failed for 
mx.example.com[XX.XX.XX.3]:25: untrusted issuer /O=Digital Signature Trust 
Co./CN=DST Root CA X3
...

checking

openssl crl2pkcs7 -nocrl -certfile fullchain.ec.crt.pem | openssl pkcs7 
-print_certs -text -noout | grep CN=
Issuer: C=US, O=Let's Encrypt, CN=R3
Subject: CN=mx.example.com
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root 
X1
Subject: C=US, O=Let's Encrypt, CN=R3
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root 
X1

openssl crl2pkcs7 -nocrl -certfile fullchain.rsa.crt.pem | openssl 
pkcs7 -print_certs -text -noout | grep CN=
Issuer: C=US, O=Let's Encrypt, CN=R3
Subject: CN=mx.example.com
Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root 
X1
Subject: C=US, O=Let's Encrypt, CN=R3
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: C=US, O=Internet Security Research Group, CN=ISRG Root 
X1

reading @ https://letsencrypt.org/certificates/, the LE cert's cross-signed by 
the DST root,

Root Certificates

Active
ISRG Root X1 (RSA 4096, O = Internet Security Research Group, 
CN = ISRG Root X1)
Self-signed: der, pem, txt
!!! Cross-signed by DST Root CA X3: der, pem, txt


and that appears in standard CA system certs,

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-bundle.crt | 
openssl pkcs7 -print_certs -text -noout | grep CN=DST
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-bundle.trust.crt | 
openssl pkcs7 -print_certs -text -noout | grep CN=DST
Issuer: O=Digital Signature Trust Co., CN=DST Root CA X3
Subject: O=Digital Signature Trust Co., CN=DST Root CA X3


You need to append the intermediate CA certificates.


also @ https://letsencrypt.org/certificates/

Intermediate Certificates

We do not use the X1, X2, X3, and X4 intermediates anymore.

Cross Signing
 Intermediates

Our RSA intermediates are signed by ISRG Root X1. ISRG Root X1 
is widely trusted at this point, but our RSA intermediates are still 
cross-signed by IdenTrust’s “DST Root CA X3” (now called “TrustID X3 Root”) for 
additional client compatibility
...
Almost all server operators will choose to serve a chain 
including the intermediate certificate with Subject “R3” and Issuer “ISRG Root 
X1”. The recommended Let’s Encrypt client software, Certbot, will make this 
configuration seamlessly.

iiuc, the certbot-retrieved LE 'fullchain' cert chains correctly include those 
two, and should be sufficient for cert validity checks.

but posttls-finger appears to also need the cross-signing root in the chain, 
and does not check/retrive OS cert paths?

i suspect i'm misunderstanding requirements &/or config here, as well

Re: Doing something wrong.

[PGNet Dev]

On 1/19/22 16:46, Viktor Dukhovni wrote:

Only "-l dane" can produce a "Verified" result with no explicit trust

...

the default is to not trust any CAs.



ah. thx! o/

posttls-finger -cC -lsecure  -F /etc/ssl/certs/ca-bundle.trust.crt 
'[mx.example.com]'
posttls-finger: mx.example.com[XX.XX.XX.X3]:25: matched peername: 
mx.example.com
posttls-finger: mx.example.com[XX.XX.XX.X3]:25: 
subject_CN=mx.example.com, issuer_CN=R3, fingerprint=..., pkey_fingerprint=...
posttls-finger: Verified TLS connection established to 
mx.example.com[XX.XX.XX.X3]:25: TLSv1.3 with cipher 
TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X448 server-signature 
ECDSA (P-384) server-digest SHA384

use of inet_protocols= option in policy maps?

[PGNet Dev]

i've a relay def'd in master.cf

relay-test  unix  -  -  n  -  -  smtp
  ...
  -o 
smtp_tls_policy_maps=${def_db_type}:${conf_dir}/test/relay_tls_policy

entries is 'relay_tls_policy' take usual form, per 
http://www.postfix.org/TLS_README.html#client_tls_policy, e.g.

[hostname.example.com]:25 securematch=hostname.example.com
...

for the relay, i can lockdown transport to a specific inet protocol,

-o inet_protocols=ipv4

but that applies to all hosts in the map

i haven't found (yet) a doc'd example of spec'ing per-host inet_protocols in 
maps.

is it doable? if so, what doc/example is relevant?

thx

Re: use of inet_protocols= option in policy maps?

[PGNet Dev]

On 2/3/22 9:28 AM, Viktor Dukhovni wrote:

Multiple transports can use the same policy table:

relay-test4 unix  -  -  n  -  -  smtp
  ...
   -o inet_protocols=ipv4
  -o 
smtp_tls_policy_maps=${def_db_type}:${conf_dir}/test/relay_tls_policy

relay-test6 unix  -  -  n  -  -  smtp
  ...
   -o inet_protocols=ipv6
  -o 
smtp_tls_policy_maps=${def_db_type}:${conf_dir}/test/relay_tls_policy


clean & simple. thx!

Re: Setting Up Header Checks

[PGNet Dev]

On 3/4/22 4:46 PM, Wietse Venema wrote:

Austin Witmer:

For some reason I can't make Milter-regex install on ubuntu? The
"make" command gives me an error when I try to run it. Does it
have to run on a BSD based server?


Did you try apt-get?

Wietse


sigh.

 
https://packages.ubuntu.com/search?keywords=milter-regex&searchon=names&suite=all§ion=all

You have searched for packages that names contain milter-regex in all 
suites, all sections, and all architectures.
Sorry, your search gave no results

milter-regex runs fine on linux

on ubu, you've got a couple of options


(1) find/convert a rpm with alien

https://manpages.ubuntu.com/manpages/trusty/man1/alien.1p.html

here's one

https://src.fedoraproject.org/rpms/milter-regex


(2) if you're building from src, on linux, you'll want to edit/modify 
`Makefile.linux`, as appropriate, then

make -f Makefile.linux clean
make -f Makefile.linux
make -f Makefile.linux install

instead of just `make`

(3) adapt an rpm.spec, e.g.


https://src.fedoraproject.org/rpms/milter-regex/blob/rawhide/f/milter-regex.spec

& build/package your own deb for convenient apt-get mgmt

Re: Setting Up Header Checks

[PGNet Dev]

What do I need to modify in the Makefile.linux file for my Ubuntu system?

short answer: to whatever YOUR system, and your interests, need

i don't use ubuntu, so can't help you specifically

i strongly suggest you look at the defaults, and modify path accordingly for your ubu 
sys; if you're building from src & installing, you should know your tools & 
path paths

fwiw, mine, for *my* fedoral install, which i do NOT recommend you blindly 
copy/use, is

  milter-regex-2.7/Makefile.my_linux
CFLAGS+=
LDFLAGS=-L/usr/lib64 -lmilter -lpthread -lbsd

all: milter-regex milter-regex.cat8

milter-regex: milter-regex.o eval.o y.tab.o
gcc -o milter-regex milter-regex.o eval.o y.tab.o $(LDFLAGS)

milter-regex.o: milter-regex.c eval.h
gcc $(CFLAGS) -c milter-regex.c

eval.o: eval.c eval.h
gcc $(CFLAGS) -c eval.c

y.tab.o: y.tab.c
gcc $(CFLAGS) -c y.tab.c

y.tab.c: parse.y
yacc -d parse.y

milter-regex.cat8: milter-regex.8
nroff -Tascii -mandoc milter-regex.8 > milter-regex.cat8

clean:
rm -f *.core milter-regex y.tab.* *.o *.cat8

install:
rm -rf /usr/local/milter-regex
mkdir -p /usr/local/milter-regex/{share/man/man8,sbin}
cp ./milter-regex /usr/local/milter-regex/sbin
cp milter-regex.8 milter-regex.cat8 
/usr/local/milter-regex/share/man/man8/

uninstall:
rm -rf /usr/local/milter-regex

Re: milter_header_checks, pcre, chroot

[PGNet Dev]

Just an FYI re: an alternative:

  https://github.com/fastmail/authentication_milter

It's freely available AND used in commercial production by the Fastmail crew.

I switched to it a while ago, from a similar setup.
I use it in its smtpd mode -- and does a good/reliable job of providing an 
integrated, well-behave header.
Very configurable, and the devs are very helpful/responsive.

On 3/18/22 8:46 AM, Jesper Dybdal wrote:



On 2022-03-18 13:07, Matus UHLAR - fantomas wrote:

On 18.03.22 12:35, Jesper Dybdal wrote:

I run postfix  3.4.14 (Debian Buster) with Amavisd-new as a pre-queue filter.

I would now like to add DMARC validation, done by the opendmarc milter in the 
after-Amavis smtpd instance.

This basically works: opendmarc inserts an "Authentication-Results" header.

I would now like to do something (e.g., reject) depending on that header.


opendmarc can reject itself, if you configure it to.


Thanks for your response.

If the version of opendmarc that is included in Debian Buster is configured to reject, 
then it also puts "quarantine" mails in postfix' hold queue, which is not 
practical.  So I would prefer to just get the header, and then control what happens after 
that with postfix header checks.


However, opendmarc milter requires those Authentication-Results headers for SPF 
and DKIM to be already present.  so you need spf/dkim milter(s) before 
opendmarc.

I use Amavis to generate and verify DKIM signatures, and policyd-spf-python to 
perform SPF checks.  That works, but means that the opendmarc milter must be 
run by the after-Amavis smtpd.

Re: DMARC in postfix ?

[PGNet Dev]

On 4/12/22 11:31 PM, John Levine wrote:

For doing DMARC validation, I know about the opendmarc milter.  Is that what
everyone uses?  Is there anything else used in pratice?


for inbound validation, i use

  https://github.com/fastmail/authentication_milter

usable as milter or smtp filter

integrates seamlessly into postfix mailflow

actively developed, and in use, commercially @ Fastmail

always_bcc for selected recipients? map support?

[PGNet Dev]

I'd like to have my Postfix receiving instance always bcc mail for a specific 
set of recipients to another , off-site server.
And to do so regardless of the intended 'main' recipient address being 'up' for 
receiving @ subsequent Postfix transport delivery targets, or not.

Reading,

https://www.postfix.org/postconf.5.html#always_bcc

straightforward for bcc'ing all.

But I don't immediately see that it support maps.

(1) does always_bcc support maps? (doc or example?)

(2) is there a better alternative that always_bcc for this use?

Re: always_bcc for selected recipients? map support?

[PGNet Dev]

Try sender_bcc_maps or recipient_bcc_maps.


once again, looking in the wrong place!

perfect, thx.

Re: Where to place spamhaus tests

[PGNet Dev]

For reference, a couple of samples of the blocked emails are:

NOQUEUE: reject: RCPT from o4.email.wetransfer.com[192.254.123.89]: 554 5.7.1 Service 
unavailable; Client host [192.254.123.89] blocked using zen.spamhaus.org; 
from= to=<(redacted)> 
proto=ESMTP helo=


Zen list is an amalgam of XBL, PBL, SBL, SBLCSS & PBL blocklists

Data can be transient or delisted ... policy depends on the specific list.

What were the return codes for the rejections above -- at the time of rejection?

When did you *check* listings, relative to the rejection time stamps?

What is your 'postscreen_dnsbl_threshold' setting, and wow are you scoring the 
individual spamhaus return-code ranges?

Re: Where to place spamhaus tests

[PGNet Dev]

ANY has to be after DIG, not at the end, but...


dig 2.0.0.127.zen.spamhaus.org. any

; <<>> DiG 9.16.30-RH <<>> 2.0.0.127.zen.spamhaus.org. any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16710
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8f85b18f84bef09b0146215782efc3bbe53357f6b72a0ee4 (good)
;; QUESTION SECTION:
;2.0.0.127.zen.spamhaus.org.IN  ANY

;; ANSWER SECTION:
2.0.0.127.zen.spamhaus.org. 60  IN  TXT 
"https://www.spamhaus.org/query/ip/127.0.0.2";
2.0.0.127.zen.spamhaus.org. 60  IN  TXT 
"https://www.spamhaus.org/sbl/query/SBL2";
2.0.0.127.zen.spamhaus.org. 60  IN  A   127.0.0.10
2.0.0.127.zen.spamhaus.org. 60  IN  A   127.0.0.4
2.0.0.127.zen.spamhaus.org. 60  IN  A   127.0.0.2

;; Query time: 254 msec
;; SERVER: 10.53.53.100#53(10.53.53.100)
;; WHEN: Sun Aug 07 09:52:59 EDT 2022
;; MSG SIZE  rcvd: 239


2.0.0.127.zen.spamhaus.org. 3579 INA127.255.255.254 

   

@ https://www.spamhaus.org/faq/section/DNSBL Usage

"If any of the tests return 127.255.255.254 then your queries (and very likely those of the 
mail server) are being blocked ("ACL'd") because the DNS resolver being used is an open 
public resolver. Some mail servers mistakenly reject all mail due to that 127.255.255.* return 
code. This can be resolved by changing how your mail server queries Spamhaus DNSBLs."

Re: Where to place spamhaus tests

[PGNet Dev]

You should read: 
https://www.spamhaus.org/news/article/788/spamhaus-dnsbl-return-codes-technical-update.

and
https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html


+1
and,

 https://www.google.com/search?q=spamhaus+postfix+zen

-> first four links:

Spamhaus Project Public Mirrors using Postfix
 
https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html

Configuring DQS on Postfix
 
https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/MTAs/020-Postfix.html

ZEN - The Spamhaus Project
 https://www.spamhaus.org/zen/

DNSBL Usage FAQ - Spamhaus
 https://www.spamhaus.org/faq/section/DNSBL Usage

Re: Where to place spamhaus tests

[PGNet Dev]

spamassassin isn't causing those rejections.
for that matter, neither is spamhaus.

something in your config is.

there are folks here that can likely assist.

unless/until your share the configs etc that've been asked for, noone's going 
to guess.

Re: Where to place spamhaus tests

[PGNet Dev]

I didn't say SA / spamhaus was causing rejections, merely that I was following 
up a discussion on the subject.

And I gave the relevant configs in the OP.


sounds like you're good then

o/
 

Re: Where to place spamhaus tests

[PGNet Dev]

http://rob0.nodns4.us/postscreen.html


+1

glad to see that's still there!

it's where *I* started oh so many years ago ;-)

Re: send mail from the domain directly to the local server without going out to the Internet

[PGNet Dev]

I'd say "especially for connections crossing not-secured network".
mails within LAN/DMZ should be safe unencrypted, unless you have reason not to 
trust the network or someone on it.


that's one choice.

some prefer to consider a Zero Trust policy

e.g., see

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

&,

  
https://www.microsoft.com/en-us/security/business/zero-trust#office-ContentAreaHeadingTemplate-ig3jspu

Zero Trust defined

Instead of assuming everything behind the corporate firewall is safe, 
the Zero Trust model assumes breach and verifies each request as though it 
originates from an open network. Regardless of where the request originates or 
what resource it accesses, Zero Trust teaches us to “never trust, always 
verify.” Every access request is fully authenticated, authorized, and encrypted 
before granting access. Microsegmentation and least privileged access 
principles are applied to minimize lateral movement. Rich intelligence and 
analytics are utilized to detect and respond to anomalies in real time.


for my own usage, every transit between services is SSL/TLS-wrapped -- local, 
or not.

overkill?  that's another choice.

Re: postfix service does not start, timeout

[PGNet Dev]

# journalctl -r -u postfix
Sep 29 15:55:48 vserver systemd[1]: Failed to start Postfix Mail Transport 
Agent.
Sep 29 15:55:48 vserver systemd[1]: postfix.service: Failed with result 
'timeout'.


1st quick check is to exec the systemd service's start cmd manually at shell.

outbound smtp " warning: DANE TLSA lookup problem" ... problem with my local resolver, or my postfix config?

[PGNet Dev]

running

postfix 3.7.2

mailing to

cas...@state.gov


i see lots of these,

2022-10-05T17:30:08.780807-04:00 mx03 postfix/qmgr[1392]: 4MjvVm57Jhz3n: 
from=, size=7604, nrcpt=1 (queue active)
2022-10-05T17:30:08.781256-04:00 mx03 
postfix/submit-from-local/smtpd[8477]: disconnect from 
internal.mx.example.net[10.17.1.32] ehlo=1 xforward=2 mail=1 rcpt=1 data=1 
quit=1 commands=7
2022-10-05T17:30:13.277421-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: DANE TLSA lookup problem: Host or domain name not found. Name service 
error for name=_25._tcp.christopher-ew.state.gov type=TLSA: Host not found, try 
again
2022-10-05T17:30:13.602684-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: DANE TLSA lookup problem: Host or domain name not found. Name service 
error for name=_25._tcp.christopher-ew.state.gov type=TLSA: Host not found, try 
again
2022-10-05T17:30:13.602980-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: TLS policy lookup for state.gov/christopher-ew.state.gov: TLSA lookup 
error for christopher-ew.state.gov:25
2022-10-05T17:30:14.353543-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: DANE TLSA lookup problem: Host or domain name not found. Name service 
error for name=_25._tcp.stimson.state.gov type=TLSA: Host not found, try again
2022-10-05T17:30:14.619838-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: DANE TLSA lookup problem: Host or domain name not found. Name service 
error for name=_25._tcp.stimson.state.gov type=TLSA: Host not found, try again
2022-10-05T17:30:14.620029-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: TLS policy lookup for state.gov/stimson.state.gov: TLSA lookup error 
for stimson.state.gov:25
2022-10-05T17:30:14.620076-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: TLS policy lookup for state.gov/stimson.state.gov: TLSA lookup error 
for stimson.state.gov:25
2022-10-05T17:30:14.620099-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: TLS policy lookup for state.gov/christopher-ew.state.gov: TLSA lookup 
error for christopher-ew.state.gov:25
2022-10-05T17:30:14.620133-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
warning: TLS policy lookup for state.gov/christopher-ew.state.gov: TLSA lookup 
error for christopher-ew.state.gov:25
2022-10-05T17:30:14.631186-04:00 mx03 postfix/smtp-out-ext/smtp[8484]: 
4MjvVm57Jhz3n: to=, relay=none, delay=5.9, 
delays=0.07/0.01/5.8/0, dsn=4.7.5, status=deferred (TLSA lookup error for 
christopher-ew.state.gov:25)

i personally don't recall every seeing one of these DANE TLSA errors

reading

Problem with TLSA & CNAME Wildcard
 
https://mailing.postfix.users.narkive.com/VGejQATw/problem-with-tlsa-cname-wildcard

suggests a resolver problem

checking with my local resolver (unbound),

dig +ad +noall +comment +ans +auth -t tlsa 
_25._tcp.christopher-ew.state.gov
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 491
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

vs Cloudflare

dig +ad +noall +comment +ans +auth -t tlsa 
_25._tcp.christopher-ew.state.gov @1.1.1.1
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64831
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, 
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; AUTHORITY SECTION:
state.gov.  900 IN  SOA 
o-bimc-dns001.grid.state.sbu. hostmaster.state.gov. 71488 10800 1080 2419200 900


anyone here have a hint what to test/check?

seems like it's my resolver ... and not postfix or its config. (?)
digging, so far, i'm seeing lots of references to the error online, and 
questions about unbound but no answer/resolution -- yet.

Re: egrep deprecation warning (Re: Urgent Postfix stable release 3.7.3 and non-urgent legacy releases 3.6.7, 3.5.17, 3.4.27)

[PGNet Dev]

perhaps of use

https://www.phoronix.com/news/GNU-Grep-3.8-Stop-egrep-fgrep
https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html

Re: egrep deprecation warning (Re: Urgent Postfix stable release 3.7.3 and non-urgent legacy releases 3.6.7, 3.5.17, 3.4.27)

[PGNet Dev]

I didn't suggest that it was, or should be.

As I didn't notice the reference in the thread, thought it might be helpful.

Not an issue for me either way.

real-world DANE -- which DNSSEC signing algo(s) to use?

[PGNet Dev]

when selecting DNSSEC signing algorithms for eventual use with DANE setup, 
checking first @


https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1

both algos 8 & 13 are listed as options:

 Number  Description  Mnemonic Zone Signing  
Trans.Sec.  Reference
 8   RSA/SHA-256  RSASHA256Y  * 
  [RFC5702][proposed standard]
 13  ECDSA Curve P-256 with SHA-256  ECDSAP256SHA256  Y  *  
 [RFC6605][proposed standard]

checking for signing algos @ root zone for my most-common in-use domains,

_r="http://www.internic.net/domain/root.zone";
curl -s $_r | egrep "^com\.|^net\.|^org\.|^io\." | awk '$4 == "DS" { printf 
"%-10s %s\n", $1, $6 }'

com.   8
io.8
net.   8
org.   8

none are currently signing with ECDSA algo 13.

and for root signing algo usage across all TLDs

curl -s $_r | awk '$4 == "DS" { print $6}' | sort -n | uniq -c
 68 5
 59 7
   1368 8
 33 10
 75 13
  1 14

the overall usage of 13 is still low, though incrementally better than a couple 
of years ago.

I'm interested in real-world production use -- specifically, NOT breaking 
postfix/DANE.

Given, e.g., Viktor's comment

https://blog.apnic.net/2021/11/10/rsa-vs-ecdsa-for-dnssec/#comment-65911

"Perhaps if we can coax more TLDs into moving to ECDSA P256, 
the ISPs will be more strongly incentivised to support the algorithm.

I'm unclear on what 'support' here means.

what's currently recommended/required?
*must* I sign my DNSSEC keys for my domains with the same algo in-use by the 
respective TLDs' roots in order to not fubar DANE usage specifically, or can I 
(arbitrarily) use any algo listed @ the iana.org link above, regardless of the 
root signing algo?

command (octal?) strings caught in postscreen pregreet ?

[PGNet Dev]

in postfix logs i see lots of these sort of entries

postfix/postscreen[46378]: PREGREET 182 after 0 from 
[137.220.233.97]:33196: 
\026\245\001\000\261\310\000\000\255\003\003'_\260T\362\266\255\001\370\255\037\003\000\334+\213\364

the backslashed/numeric strings vary from message to message

afaict, postscreen has a perfect batting record here; not a one of them ever 
gets past it.

idle curiosity ... what are those strings?  command injection attempts, i 
presume.

looks like octal expansion, but i haven't managed to translate to 
human-readable text form to see what those are

is there a postfix, or related, tool to translate & see?

Re: How do check DKIM and SPF on incoming email?

[PGNet Dev]

Is Postfix capable of checking DKIM and SPF records on incoming email
and adding headers based upon its findings?


Not the postfix code itself, but postfix supports milters which do this.



My google searches have only returned results on how to do DKIM
signing on outbound email and not how to verify them on inbound emails.


The milter that does the signing usually will also verify signatures on 
incoming, for example is OpenDKIM.


there are, as well, milters that verify incoming, but do not sign outgoing.

i typically use one with my postfix setup,

  https://github.com/fastmail/authentication_milter

Re: Spammer succeeded in relaying through my server

[PGNet Dev]

Actually I would appreciate advice on how to do this on an internal environment.


google's your friend on this one

https://www.google.com/search?q=postfix+docker+testing

first link,


https://fabianlee.org/2019/10/23/docker-running-a-postfix-container-for-testing-mail-during-development/

looks like a reasonable place to start

start simple, demonstrate basic setup works inbound & outbound, then worry 
about adding proxies, etc, and finally opening yourself up to the 'net -- and the 
'net to you.

Re: run script on new connection?

[PGNet Dev]

I want to be able to run my own "idp" type script when someone tries to connect 
to my mailserver. Basically I want to refuse them even a tcp connection to smtpd if the 
connecting ip is in our internal blacklist.


is there a reason you want to involve postfix at all?

fail2ban scans logs, and then creates firewall rules.
since your already have your IP lists, skip the scan & just create the fw rule 
in front of postfix.

populate the lists into an iptables firewall ipset.

then create a fw rule to reject traffic from those IPs to your smtpd IP/port.

Re: run script on new connection?

[PGNet Dev]

The first one is to avoid having a scheduled task running at least every minute to keep the list updated. 


How were you planning to get the lists into postfix, and keep them updated?


The second one is that I only want to add the relevant firewall rules to the 
mailserver. I don't know how many rules you can have before it starts to effect 
performance.


With ipsets (or nftables setc, etc) it's one rule ...
e.g., https://www.thegeekdiary.com/how-to-use-ipset-command-in-linux/

Re: Are non_smtpd_milters applied to mail delivered via smtpd?

[PGNet Dev]

I guess the best way to combat this would be to use spamassassin as
a milter as well?
Or do you have another idea?


I had exactly the same problem when I was configuring DKIM on my server, and
I did exactly this - switched from using SA as a post-queue filter to using
it as a milter. Works good for me.


postfix is really quite flexible here.  many ways, and tradeoffs, to approach 
filtering & delivery (and, to shoot yourself in your own foot!).

in one medium-duty case (~ 5K messages / day), I host a postfix instance on an 
edge VPS.

years ago it was bogging down with amavis/rspam. i looked for a lighter, 
better-behaved solution.

this works for me.
is it the most efficient, or guaranteed robust? certainly not, but it never 
noticeably bogs down for my usage, avoids double passes, and has been running 
in production since i switched to it.
and i find it easy to config & maintain.
YMMV.

for inbound, postscreen listens,

[mx.example.com]:25  inet  n  -  n  -  1  postscreen
  -o smtpd_service_name=postscreen-internal

is passed to internal smtpd,

postscreen-internal  pass  -  -  n  -  -  smtpd
  ...
  -o smtpd_proxy_filter=[127.0.0.1]:33010

where 127.0.0.1:33010 is the listener for Fastmail Authentication milter, which 
handles SPF/DKIM/DMARC/etc authentication + headers,

https://github.com/fastmail/authentication_milter

, and which I run in its 'smtp' mode.  After scan + header adds, it reinjects 
to postfix preq milters

[127.0.0.1]:33020  inet  n  -  n  -  -  smtpd
  ...
  -o milter_protocol=6
  -o milter_default_action=reject
  -o 
smtpd_milters=unix:/run/mregex/mregex.sock,unix:/run/clamav-milter/clamav-milter.sock,unix:/run/sa-milter/sa-milter.sock
  -o smtpd_service_name=[127.0.0.1]:33030

, passing through milter checks for

milter-regex (https://www.benzedrine.ch/milter-regex.html)
clamav   
(https://docs.clamav.net/manual/Usage/Configuration.html#clamav-milterconf)
spamassassin (https://crates.io/crates/spamassassin-milter)

which, on pass, inject again to

[127.0.0.1]:33030  inet  n  -  n  -  -  smtpd
  -o content_filter=${def_dbtype}:${cfgdir}/relay_transports

and sends along to final delivery destinations (e.g., over a VPN link to an 
internal box with a postfix+dovecot instance)

for outbound submissions, I sign with dkimpy milter

[int.mx.example.com]:465  inet  n  -  n  -  -  smtpd
  ...
  -o smtpd_milters=unix:/run/dkimpy-milter/dkimpy-milter.sock
  -o milter_macro_daemon_name=DKIM_ORIGINATING
  -o cleanup_service_name=cleanup-out

where, additionally, I do outbound header cleanup/rewrites

...
cleanup  unix  n  -  n  -  0  cleanup
cleanup-out  unix  n  -  n  -  0  cleanup
  ...
  -o syslog_name=cleanup-out
  -o mime_header_checks=pcre:${cfgdir}/header_checks-out.pcre
  -o header_checks=pcre:${cfgdir}/header_checks-out.pcre
...

of course, there's lots of add'l config that meets my specific needs; e.g., all 
transits are TLS protected, DANE's in place, etc etc.
it's fairly trivial to move/replace pieces to other boxes, add redundancy, etc.

smtp_line_length_limit vs Sendmail?

[PGNet Dev]

Current default for

 http://www.postfix.org/postconf.5.html#smtp_line_length_limit

is == 998, per smtp std.

Ages ago, Sendmail added an errant "!", causing overruns -- I think that's in 
part why the prior Postfix value == 990? to accommodate 'broken' Sendmail?

Time's passed, clearly the Postfix default has been raised to ==998, but ... 
has Sendmail actually been fixed to be 998-char compliant? And, in wide enough 
real-world deployment to be an acceptable risk?

Or is the real-world recommendation still to dumb-down to == 990?

Re: smtp_line_length_limit vs Sendmail?

[PGNet Dev]

> I don't see any mention of Sendmail in that text.

As I said, 'ages ago'.  Per a conversation,

  https://mailing.postfix.users.narkive.com/nhbtm7Fg/smtp-line-length-limit-998

It apparently was an issue; I'm asking if it still is.

Re: smtp_line_length_limit vs Sendmail?

[PGNet Dev]

> The limit was still 990 in Sendmail 8.15.

To deal with that in production, is setting value in Postfix to == 990 
sufficient? recommended?

Does a setting of == 990 (continue to) break any particular 
service/functionality?

The Sendmail 'Usenet'/Google Group is a bit of a sewer; cc'ing Claus to see if 
there's any newer comment/clarity as to why Sendmail's still not 
standards-compliant in this.

Re: smtp_line_length_limit vs Sendmail?

[PGNet Dev]

> No idea. One could equally-well argue for setting it to zero.

Noted.

It was changed here long-ago, guessing for a reason, but I've no current 
metrics to convince me, or not, that there's a problem (anymore).

My inclination is to stick with Postfix's 'new(er)' default/standard == 998, 
for no other reason than it IS the default/standard.

And simply allow the non-compliant "rest" cause whatever problems they will ...

postfix 3.5.0 + gcc10 build fail, "multiple definition of `var_inet_protocols'; master_vars.o:(.bss+0x10): first defined here" ?

[PGNet Dev]

(my bad, shouldn't have sent to -devel)

i'm building a new/clean postfix 3.5.0 instance on linux/64


currently, with

gcc --version
gcc (SUSE Linux) 10.0.1 20200408 (experimental) [revision 
13e41d8b9d3d7598c72c38acc86a3d97046c8373]

my usually problem-free `make`,

make V=1 -j8 DEBUG="" OPT="-O3"

now fails,

...
ranlib ../../lib/libmaster.a
/usr/bin/gcc-10 -I. -I../../include -DHAS_LMDB 
-I/usr/local/lmdb/include -DNO_DB -DNO_CDB -DNO_NIS -DUSE_TLS  
-I/usr/local/openssl11/include -DHAS_PCRE -I/usr/local/include 
-I/usr/include/db4 -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" 
-DMAX_DYNAMIC_MAPS -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" 
-DDEF_DATA_DIR=\"/var/lib/postfix\" -DDEF_QUEUE_DIR=\"/var/spool/postfix\" 
-DDEF_SENDMAIL_PATH=\"/usr/local/sbin/sendmail\" 
-DDEF_NEWALIAS_PATH=\"/usr/local/bin/newaliases\" 
-DDEF_MAILQ_PATH=\"/usr/local/bin/mailq\" -DDEF_COMMAND_DIR=\"/usr/local/sbin\" 
-DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" 
-DDEF_MANPAGE_DIR=\"/usr/local/man\" 
-DDEF_README_DIR=\"/usr/local/share/doc/packages/postfix-doc/README_FILES\" 
-DDEF_HTML_DIR=\"/usr/local/share/doc/packages/postfix-doc/html\" 
-I/usr/local/include -DHAS_DEV_URANDOM -UUSE_DYNAMIC_LIBS 
-DDEF_SHLIB_DIR=\"no\" -UUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat 
-Wno-comment  -O3 -I. -I../../include -DLINUX5  -o master master.o 
master_conf.o master_ent.o master_sig.o master_avail.o master_spawn.o 
master_service.o master_status.o master_listen.o master_vars.o master_wakeup.o 
master_watch.o master_flow.o master_monitor.o ../../lib/libglobal.a 
../../lib/libutil.a -L/usr/local/openssl11/lib64 
-Wl,-rpath,/usr/local/openssl11/lib64 -lssl -lcrypto -L/usr/local/lib64 
-Wl,-rpath,/usr/local/lib64 -lpcre -lpcrecpp -L/usr/local/lmdb/lib64 
-Wl,-rpath,/usr/local/lmdb/lib64 -llmdb -L/usr/local/lib64 
-Wl,-rpath,/usr/local/lib64 -lz -lm -lnsl -lresolv -ldl -L/usr/local/lib64 
-licui18n -licuuc -licudata

/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: 
../../lib/libglobal.a(mail_params.o):(.bss+0x270): multiple definition of 
`var_inet_protocols'; master_vars.o:(.bss+0x10): first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:146: master] Error 1
make: *** [Makefile:157: update] Error 1

looks like the source of the issue is (?),

grep var_inet_protocols `grep -rlni var_inet_protocols .`
./src/postconf/postconf_builtin.c:if (var_inet_protocols == 
0) {
./src/postconf/postconf_builtin.c:  var_inet_protocols = 
mystrdup(junk);
./src/postconf/postconf_builtin.c:  (void) 
inet_proto_init(VAR_INET_PROTOCOLS, var_inet_protocols);
./src/qmqpd/qmqpd_peer.c: "other", 
VAR_INET_PROTOCOLS, var_inet_protocols);
./src/qmqpd/qmqpd.c:  VAR_INET_PROTOCOLS, 
var_inet_protocols);
./src/master/master.c:(void) 
inet_proto_init(VAR_INET_PROTOCOLS, var_inet_protocols);
./src/master/master_ent.c:   VAR_INET_PROTOCOLS, 
var_inet_protocols);
>>> ./src/master/master_vars.c:char   *var_inet_protocols;
./src/master/master_vars.c: VAR_INET_PROTOCOLS, 
&var_inet_protocols, &saved_inet_protocols, 0, 0,
>>> ./src/global/mail_params.c:/*   char*var_inet_protocols;
./src/global/mail_params.c:char   *var_inet_protocols;
./src/global/mail_params.c: VAR_INET_PROTOCOLS, 
DEF_INET_PROTOCOLS, &var_inet_protocols, 0, 0,
./src/global/mail_params.c:(void) 
inet_proto_init(VAR_INET_PROTOCOLS, var_inet_protocols);
./src/global/mail_params.h:extern char *var_inet_protocols;
./src/smtpd/smtpd_peer.c: "other", 
VAR_INET_PROTOCOLS, var_inet_protocols);
./src/smtpd/smtpd.c:  VAR_INET_PROTOCOLS, 
var_inet_protocols);
./src/postscreen/postscreen.c:VAR_INET_PROTOCOLS, 
var_inet_protocols);

haven't seen this b4.  not sure if something's changed, my config's wrong, or 
this is a GCC-10 sensitivity ...

bug, or me?

Re: postfix 3.5.0 + gcc10 build fail, "multiple definition of `var_inet_protocols'; master_vars.o:(.bss+0x10): first defined here" ?

[PGNet Dev]

On 4/13/20 9:51 AM, PGNet Dev wrote:
> haven't seen this b4.  not sure if something's changed, my config's wrong, or 
> this is a GCC-10 sensitivity ...

looks like GCC10 related

switching from

CC=/usr/bin/gcc-10
CXX=/usr/bin/g++-10

to

CC=/usr/bin/clang
CXX=/usr/bin/clang++

seems to cure the issue

`make ...` & install complete with no errors

DNSSEC, DANE, Postfix for new-to-it admins?

[PGNet Dev]

all this back-n-forth on list re: DNSSEC/DANE has resulted in a flurry of 
interest among colleagues etc.  and i've been getting emails.  lots.

for the what/why i've been tossing them Viktor's now just slightly dusty preso

 Real World DANE Inter-domain email transport

  https://static.ptbl.co/static/attachments/169319/1520904692.pdf

for the how, my own brief deploy notes are not particularly useful in current 
form.


Any favorites/recommendations for current "what/why" & "how to" DNSSEC/DANE 
with Postfix docs/tutorials/posts/etc?

Particularly for completely-new-to-DNSSEC/DANE, but mostly self-sufficient with 
Postfix otherwise, admins?

Re: DNSSEC, DANE, Postfix for new-to-it admins?

[PGNet Dev]

On 4/17/20 4:29 PM, Viktor Dukhovni wrote:
> More at:

all links appreciated.

the summary's particularly nicely readable by those of among the minion masses 
of normal humans ;-)

> Postfix documentation covers the client side

still among the best, most-exhaustively detailed s/docs/reference man/ out 
there.  and still capable of causing fainting spells among said-same 
minion-masses.

> Writing all of this down in detail is a non-trivial project, and would
> perhaps be a small book.

a cradle-2-grave, human-speak ebook would certainly sell!

i'd have love to have one when I 1st got this running; still quite a tedious 
slog piecing it all together.  the good news is that the info _is_ there to 
find.  if you work at it.  a lot.

> I've not had the cycles... :-(

hear ya.

> I've started work on some text for this to add to the Postfix
> TLS_README, but it won't cover all the topics, and will only sketch out
> the requirements, the reader will need to fill in various details from
> other sources (or prior experience).

even 'just' that^, with links curated as being reliable, and a crude 
step-by-step will be useful.

ty o/

Re: Postfix stable release 3.5.1 and legacy releases 3.4.11, 3.3.9, 3.2.14

[PGNet Dev]

On 4/20/20 11:14 AM, Wietse Venema wrote:
> Postfix versions 3.5.1, 3.4.11, 3.3.9, 3.2.14:
> 
>* Bitrot workaround for broken builds after an incompatible change
>  in GCC 10.

confirming, 3.5.1 build/install/exec all well-behaved again with _both_ gcc-10 
& clang-10

  Apr 20 11:51:36 test postfix/master[43824]: daemon started -- version 3.5.1, 
configuration /usr/local/etc/postfix

ta!

are rsa certs/keys still needed/recommended for use in postfix? or can just ecc be relied on?

[PGNet Dev]

for websites it seems that, for all practical purposes, ecc ssl certs are all 
that's needed anymore

cref e.g. comments at


https://www.thesslstore.com/blog/you-should-be-using-ecc-for-your-ssl-tls-certificates/

" ... All modern Operating Systems and Browsers support ECC ..."

for my sites, i don't care about failing service to those using old browsers.

does the same hold true for smtp(d)?

in postfix, i've had for the longest time overrides in my main.cf,

smtpd_tls_eckey_file  = /etc/ssl/postfix/privkey_ec.pem
smtpd_tls_eccert_file = /etc/ssl/postfix/fullchain.ec.crt.pem
smtpd_tls_key_file= /etc/ssl/postfix/privkey_rsa.pem
smtpd_tls_cert_file   = /etc/ssl/postfix/fullchain.rsa.crt.pem

with letsencrypt happily renewing both the ecc & rsa algo certs,

as a 1st test i removed

smtpd_tls_eckey_file  = /etc/ssl/postfix/privkey_ec.pem
smtpd_tls_eccert_file = /etc/ssl/postfix/fullchain.ec.crt.pem
-   smtpd_tls_key_file= /etc/ssl/postfix/privkey_rsa.pem
-   smtpd_tls_cert_file   = /etc/ssl/postfix/fullchain.rsa.crt.pem

which iiuc drop back to 'empty' defaults of

postconf -d smtpd_tls_key_file smtpd_tls_cert_file
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_cert_file =

and, have seen no immediately adverse effects in mail flow.  far from robust 
testing at this point ...

i don't have any idea of what the stats are; thought best to ask -- as for 
mail, it's still arguably hit-and-miss for deliverability with disabling 'older 
tech' ciphers, etc., depending on your service case.

is it safe/recommended to not bother with the rsa certs anymore?

Re: The historical roots of our computer terms

[PGNet Dev]

This has become irrelevant to postfix-users, and any technical discussion.

Re: Postfix restrictions

[PGNet Dev]

On 6/7/20 4:23 AM, Laura Smith wrote:
> smtpd_recipient_restrictions = 
> permit_mynetworks,${indexed}custom_reject,reject_unauth_destination,
>  reject_rhsbl_sender 
> .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],
>  reject_rhsbl_helo   
> .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],
>  reject_rhsbl_reverse_client 
> .dbl.dq.spamhaus.net=127.0.1.[2;4;5;6],
>  reject_rhsbl_sender 
> .zrd.dq.spamhaus.net=127.0.2.[2..24],
>  reject_rhsbl_helo   
> .zrd.dq.spamhaus.net=127.0.2.[2..24],
>  reject_rhsbl_reverse_client 
> .zrd.dq.spamhaus.net=127.0.2.[2..24],
>  reject_rbl_client   
> .zen.dq.spamhaus.net=127.0.0.[2;3;4..7;10;11]
> smtpd_client_restrictions = reject_rbl_client  
> .zen.dq.spamhaus.net
> postscreen_dnsbl_sites =  
> .zen.dq.spamhaus.net=127.0.0.[2;3;4..7;10;11]

i've switched a postfix install to this^ usage of spamhaus dqs et al.

(hadn't even _noticed_ the dq option since release last year!)

in my logs, i see, e.g.

Jun  8 06:49:08 mx postfix/dnsblog[21103]: addr 151.20.170.84 listed by 
domain .zen.dq.spamhaus.net as 127.0.0.10

with the "" clearly displayed.

have you a setting/map in postfix that simply prevents/filters the 
"" value from explicit entry in the logs?

i haven't yet _seen_ it in any SMTP reply, reject or otherwise, but would like 
to ensure that that doesn't happen either.

Re: Postfix restrictions

[PGNet Dev]

On 6/8/20 7:12 AM, Dominic Raferd wrote:
> main.cf :
> 
> rbl_reply_maps = pcre:/etc/postfix/rbl_reply_maps.pcre
> postscreen_dnsbl_reply_map = pcre:/etc/postfix/postscreen_dnsbl_reply_map.pcre
> 
> 
> # cat /etc/postfix/rbl_reply_maps.pcre
> /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ $$rbl_code Service unavailable; 
> $$rbl_class [$$rbl_what] blocked using ${1}$${rbl_reason?; $$rbl_reason}
> # cat /etc/postfix/postscreen_dnsbl_reply_map.pcre
> /[a-z0-9]*\.([a-z]*\.dq\.spamhaus\.net)/ ${1}

ah, thx!

that seems to work nicely -- for the SMTP reply; doesn't affect the dnsblog 
output (yet; poking around now)

tho, reading some other examples I've now found in posts -- why the double "$$" 
here?

reading

http://www.postfix.org/pcre_table.5.html

I do see the

TEXT SUBSTITUTION
Substitution of substrings (text that  matches  patterns  inside  
"()")from  the  matched  expression into the result string is requested with$1, 
$2, etc.; specify $$ to produce  a  $  character  as  output.

, just not clear if/why it's needed here?

Re: Postfix restrictions

[PGNet Dev]

On 6/8/20 8:37 AM, Dominic Raferd wrote:
> This was discussed before:
> https://www.mail-archive.com/postfix-users@postfix.org/msg85706.html

thx!

i had similarly "interpreted the text 'specify $$ to
 produce a $ character as output' as meaning that $$ would produce a

hard-coded dollar sign"

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

[PGNet Dev]

i run postfix 3.5.2

i'm 

-- revisiting spamassassin integration with postfix

-- not interested in amavisd integration or rspamd alternative

-- looking for lightweight & known to be (still/currently) reliable & active

-- ideally, tho not absolutely req'd, milter-protocol

-- aware of 3 options, in order of decreasing 'dustiness',

   https://savannah.nongnu.org/projects/spamass-milt/
   https://github.com/mpaperno/spampd
   https://gitlab.com/glts/spamassassin-milter

anyone have any current experience with any of these?

recommendations, thoughts, etc?

or other SA-based options?

dnsblog filtering?

[PGNet Dev]

does dnsblog have a log map/filter/somesuch?

or does the capability exist elsewhere in postfix?

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

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

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

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

Re: dnsblog filtering?

[PGNet Dev]

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

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

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

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

> or patch the source.

unwise, at best.

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

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

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

[PGNet Dev]

On 6/9/20 5:40 AM, Marvin Renich wrote:
>> https://savannah.nongnu.org/projects/spamass-milt/
>> https://github.com/mpaperno/spampd
>> https://gitlab.com/glts/spamassassin-milter
>>
>> anyone have any current experience with any of these?
> 
> I also use the first one (Debian package spamass-milter) along with
> milter-greylist (only greylisting messages with a spam score in the
> lower end of the "positive" range to avoid rejecting false
> positives from spamassassin while not greylisting clearly legitimate
> email).


in some testing,

i found the idea of a 'modern' rust implementation in spamassassin-milter 
initially appealing.
simply could not manage to get it talking to a spamd backend.

spampd worked well enough, when listening on tcp host:port.
listening on socket, i couldn't get past postfix permissions issues, despite 
similar setup to other policy daemons in use.
that makes me a bit antsy. as does not using 'native', up-to-date spamd.

spamass-milter, despite being the 'dustiest' of the bunch, works without issue.
set up like other milters, it's a simple drop-in to postfix config.
uses native spamc+spamd, and my local configs as intended.

as it seems widely in-use, and appears to work well enough i'll take the 'risk' 

with, now, a working postfix setup that includes

  clamav-milter + clamd
  spamass-milter + spamd

and all traces of amavisd removed, mail's flowing smoothly. and, noticeably 
faster, with less resource use.

now, to get learning, headers, etc cleaned up the way i like them ...

thx 4 the input!

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

[PGNet Dev]

On 6/10/20 2:05 PM, Bill Cole wrote:
> It uses the installed SpamAssasssin Perl modules directly, just as spamd does.

fact noted.  details admittedly i'll have to poke around in.

> The socket permissions issues are probably solvable, but if running on the 
> loopback interface works,
> there's not a lot of reasons to prefer the socket.

just prefer the organization, limited clutter on loopback, and perms of 
sockets.  and, that's what i generally do 'everywhere else'.  mostly, anyway.

> I'm not a big fan of spampd because it uses the proxy model instead of milter,

yep; not a fan of swiss-army-knives either.

i'm now "all milters, all the time".  simpler config, and easier debug.

>  but at least it isn't abandonware.

spamass-milter has "signs of life" as recently as Jan '20 @

https://github.com/andybalholm/spamass-milter

not terrible for an assumed stable, though 'old', package

> My favorite SA integration tool is MIMEDefang, but it is far from lightweight.

there's a number of fatter options that work well for others.

i'm _trying_ to stay as 'simple' as possible, and fat/arcane config files make 
my old, tired eyes ache.

identifying _which_ milter rejects in private logs?

[PGNet Dev]

my postfix instance config currently includes my list of milters

-o 
smtpd_milters=unix:/run/opendkim/opendkim.sock,unix:/run/opendmarc/opendmarc.sock,unix:/run/milter-regex/milter-regex.sock,unix:/run/clamav/clamav-milter.sock,unix:/run/spamass-milter/spamass-milter.sock

for a rejection by any given milter, i see in cleanup log

Jun 11 04:33:18 mx postfix/cleanup[18542]: 49jV46213qzy59: 
milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Service 
unavailable; from= to= proto=ESMTP 
helo=

can postfix logging itself identify the specific milter that fails/rejects?

e.g., in this^ case, it's

unix:/run/spamass-milter/spamass-milter.sock

i can configure reject messages in (some) milters to provide identifying 
detail, but that reply gets passed on to external connection.

any way to log that detail only _privately_?

Re: identifying _which_ milter rejects in private logs?

[PGNet Dev]

On 6/11/20 11:24 AM, Wietse Venema wrote:
> PGNet Dev:
>> my postfix instance config currently includes my list of milters
>>
>>  -o 
>> smtpd_milters=unix:/run/opendkim/opendkim.sock,unix:/run/opendmarc/opendmarc.sock,unix:/run/milter-regex/milter-regex.sock,unix:/run/clamav/clamav-milter.sock,unix:/run/spamass-milter/spamass-milter.sock
>>
>> for a rejection by any given milter, i see in cleanup log
>>
>>  Jun 11 04:33:18 mx postfix/cleanup[18542]: 49jV46213qzy59: 
>> milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Service 
>> unavailable; from= to= proto=ESMTP 
>> helo=
>>
>> can postfix logging itself identify the specific milter that fails/rejects?
> 
> To find out WHY mail was rejected, the Milter needs to log what it
> is doing, or say something other than "Service unavailable". The
> IP address and port are poor substitutes for that.
> 
>> e.g., in this^ case, it's
>>
>>  unix:/run/spamass-milter/spamass-milter.sock
>>
>> i can configure reject messages in (some) milters to provide identifying 
>> detail, but that reply gets passed on to external connection.
>>
>> any way to log that detail only _privately_?
> 
> Postfix logs are private. They should be read by authorized personnel
> only.

if I add more detail to a milter's reject message,

a trigger spam sent to postfix triggers the spamass-milter

Jun 11 11:27:58 mx postfix/cleanup[6865]: 49jXR23vMMzy68: 
milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Service 
unavailable; Message Content blocked using SA-Milter; from= 
to= proto=ESMTP helo=

now 'identifying' the specific milter, 'privately', in logs

that's what I _do_ want

which passes the message to postscreen-internal

Jun 11 11:27:58 mx postfix/postscreen-internal/smtpd[6858]: 
proxy-reject: END-OF-MESSAGE: 550 5.7.1 Service unavailable; Message Content 
blocked using SA-Milter; from= to= 
proto=ESMTP helo=

and 'out', back to the sender; as received

The response from the remote server was:
550 5.7.1 Service unavailable; Message Content blocked using SA-Milter

that's what I do _not_ want; i.e., no milter-identifying message/data returned 
to the sender.

rather, JUST the reject

Re: identifying _which_ milter rejects in private logs?

[PGNet Dev]

On 6/11/20 12:57 PM, Bill Cole wrote:
> In the case of SpamAssassin, if your milter is spamass-milter or anything 
> else using spamd, you could just use spamd's logging and correlate it with 
> Postfix via Message-Ids.

sure. finding/correlating the information is certainly possible.

i'm just cleaning up reporting atm, separating what's needed privately/locally, 
and what's public.

the point is simply that postfix reports the reject message -- in full -- from 
the milter, back to the connecting sender.
 that's public, not private ...


> If you can set what the milter returns to Postfix, you can make it obscure to 
> the sender but identifying for you, e.g. "Message unacceptable under Rule 34" 
> This is better than a completely non-identifying message, because when you 
> have a false positive spam rejection, the sender will be able to tell you the 
> specific error message, revealing to you where the issue came from.

yep, that works.  an additional layer of obfuscation.  messy, but one makes do.

not all milters allow setting the reply/reject SMTP message.  for those, yet 
another trip to the milter logs.

alternative is dump 'all' logs to logstach/splunk, and massage there.

usage for late-match-> REJECT using milter_header_checks ?

[PGNet Dev]

I've set up a postfix instance

[127.0.0.1]:10003  inet  n  -  n -  -  smtpd
  -o syslog_name=postfix/after-filters
  ...
  -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings,no_milters
  -o content_filter=relay-internal:[internal-mx.example.com]:10001

which relays after all pre-queue filters, and final queuing via

relay-internal   unix - -   n   -   -   smtp
  ...

Mail flows as intended.

I'd like to do a final pcre header check BEFORE doing the relay, REJECTing on 
match of a X-Spam-Level header if/when set by ANY prior, pre-Q filter.

reading

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

where

cat /usr/local/etc/postfix/spamlevel.pcre
/X-Spam-Level: \*{10,}/ REJECT TEST

I note that for SMTP body checks, REJECT action

This feature is not supported with smtp header/body checks.

Instead, trying

http://www.postfix.org/postconf.5.html#milter_header_checks

, editing the instance config

[127.0.0.1]:10003  inet  n  -  n -  -  smtpd
  ...
- -o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings,no_milters
+ -o milter_header_checks=pcre:/usr/local/etc/postfix/spamlevel.pcre
  -o content_filter=relay-internal:[internal-mx.example.com]:10001

after service restart, non-spam mail still flows as expected.

BUT, so does tagged mail with X-Spam-Level > 10*; it's passed as well; i.e., 
NOT matched/REJECTed.

The final/received email is verified as tagged with

X-Spam-Level: **

which i'd hoped would match the regex, get the REJECT, and prevent the relay.

There's no obvious postfix error in logs.

Is my usage here wrong? If so, what's the problem/fix?

or am i trying to use the wrong tool with 'milter_header_checks' ?

Re: usage for late-match-> REJECT using milter_header_checks ?

[PGNet Dev]

On 6/13/20 4:05 PM, Wietse Venema wrote:
> Postfix has milter_header_checks for message headers
> that are added by a Milter.

yes. that's exactly what I referenced in my OP, and included in my config.

what exactly is your point?

latest postfix pkgs for Fedora32 ?

[PGNet Dev]

i typically build my own postfix. simple, and atm happily running 3.5.3 stable.

i'm _considering_ distro package deployment, specifically looking for F32 
packages.

afaict, what's available in official F32 repos is Postfix v3.5.2 -- with v3.5.3 
still in 'updates'testing'.

since released on 6/14, it seems a bit long for up-to-date pkg'ing to appear; 
is there another reliable source for Fedora Postfix packages?

or is updates-testing/updates 'it', and just a matter of waiting til whenever 
-- or sticking with DIY?

Re: latest postfix pkgs for Fedora32 ?

[PGNet Dev]

> impatient

not in the slightest.

i'm happy with the version I run, and prefer consistency.

just asked where currently up-to-date packages for Fedora32 can be found, if at 
all.

some distros have it; Fedora seems not to.

thx, tho.

fyi, +1 on lightweight postfix spam milter alternative: 'spamassassin-milter'

[PGNet Dev]

for anyone interested, 'spamassassin-milter'

https://gitlab.com/glts/spamassassin-milter

a modern/current, rust-coded, SpamAssassin milter -- that cleanly submits msgs 
via spamc to spamd -- is, for me, working quite nicely with current/latest 
Postfix.

it appears to be lightweight, fast & stable, so far. it's free of some of the 
restrictions of spamass-milter; for me, notably, the limited headers passed.

the dev has been very helpful/responsive/courteous to date, and is focussed on 
ensuring it works with Postfix; much appreciated!

i've switched a couple of servers to using it in production; watching logs for 
awhile.


it currently sits at the end of my milter-chain,

  opendkim -> opendmarc -> milter-regex -> clamav-milter -> spamassassin-milter

if all continues to goe well, I'll 'jump-ship' wholesale to its use soon.


atm, it's a DIY-build, though trivial.

prereqs include

sendmail-devel (libmilter)
cargo
rust

here i've

cargo -V
cargo 1.43.0
rustc -V
rustc 1.43.0

the build/install is straightforward

git clone https://gitlab.com/glts/spamassassin-milter
cd spamassassin-milter

note: edit milter.pc to your needs/liking

then build

PKG_CONFIG_PATH=. cargo build

move the excutable somewhere useful

cp -af target/debug/spamassassin-milter /usr/local/sbin/

set up a service file; mine's

/etc/systemd/system/spamassassin-milter.service
[Unit]
Description=SpamAssassin Milter
Wants  = spamd.service
After  = syslog.target local-fs.target network-online.target 
spamd.service
Before = postfix.service

[Service]
Type=simple
UMask = 0117
User=spamassassin-milter
Group=postfix-milter
PIDFile=/run/spamassassin-milter/spamassassin-milter.pid
ExecStart=/usr/local/sbin/spamassassin-milter \
 --verbose \
 --trusted-networks '...' \
 --max-message-size 1 \
 --reject-spam \
 --reply-code '550' \
 --reply-status-code '5.7.1' \
 --reply-text 'Service unavailable; REJECTED: Message Content' \
 unix:/run/spamassassin-milter/spamassassin-milter.sock
Restart=on-failure

[Install]
WantedBy=multi-user.target

make sure your chosen user:group exist & match the service file

enable/start the milter service (and of course spamd)

if interested, join in at the github project.  strength in numbers, rt?

lmd support -- available as an 'add on', or just 'compiled in'?

[PGNet Dev]

I build/use Postfix with LMDB.  Works great.

Looking at distro packages, don't alway find LMDB support compiled in.

I can certainly rebuild my own, but wanted to check first:

Reading

http://www.postfix.org/LMDB_README.html
"To build Postfix with LMDB support, use something like ..."

does that 'like' possibly include alternatives for building/adding LDMB support 
an addon/extension?  i.e., something we can trivially add-on to a 
distro-isntalled package that lacks it?

or is LMDB necessarily a compiled-in option only?

Re: lmd support -- available as an 'add on', or just 'compiled in'?

[PGNet Dev]

On 7/6/20 10:32 AM, Wietse Venema wrote:
> You can build plugins separately from Postfix, but it will not be
> supported.

noted, and found it I believe:

http://www.postfix.org/INSTALL.html#build_dll

will give it a whirl ...

thx

Re: lmd support -- available as an 'add on', or just 'compiled in'?

[PGNet Dev]

On 7/6/20 11:01 AM, Viktor Dukhovni wrote:
> Various OS distributions build separate packages for the Postfix
> database table drivers.  For example, in Fedora 31:
> 
>  $ rpm -qf /usr/lib64/postfix/postfix-cdb.so
>  postfix-cdb-3.4.13-1.fc31.x86_64
> 
> I don't see a similar package for lmdb in Fedora 31, but there is
> for example:
> 
>  
> https://centos.pkgs.org/7/ghettoforge-testing-x86_64/postfix3-lmdb-3.5.4-1.gf.el7.x86_64.rpm.html
> 
> So depending on your OS distribution, LMDB may be available as a
> separate package.

I'm considering Fedora 32 atm.  If it's "in there", I haven't see it.

That link should be helpful; I didn't think to dig back into Centos-land. 
Thanks!

I'm still/always tempted to build _my_ own from src -- it's really quite simple 
& very reliably consistent.  Tho', DIY does not scale terribly well in 
deployment.

A diy rpm spec is an alternative.  Lots of options!

Re: lmd support -- available as an 'add on', or just 'compiled in'?

[PGNet Dev]

>> Various OS distributions build separate packages for the Postfix
>> database table drivers.  For example, in Fedora 31:
>>
>> $ rpm -qf /usr/lib64/postfix/postfix-cdb.so
>> postfix-cdb-3.4.13-1.fc31.x86_64
>>
>> I don't see a similar package for lmdb in Fedora 31, but there is
>> for example:
>>
>> https://centos.pkgs.org/7/ghettoforge-testing-x86_64/postfix3-lmdb-3.5.4-1.gf.el7.x86_64.rpm.html
>>
>> So depending on your OS distribution, LMDB may be available as a
>> separate package.
> 
> It's available in Debian and derivatives for some time as postfix-lmdb 
> (Debian 9 and later).

iiuc both the centos & debian refs point to full postfix builds with "make 
makefiles dynamicmaps=yes ..." that split off and package the lmdb database 
plugin.

if I've got to do the full build ANYWAY, in order to build & 'get' the db 
plugin to install alongside the distro-pkg'd, lmdb-less, postfix install -- 
there's really no point :-/

what i was digging around about was whether it was possible to 
build/extract/install just the plugin ...
in a similar manner to phpize/compile (or pear or pecl install) a php plugin.

i.e. --- lazy person's "just the plugin" install.

seems N/A for F32 (that's a different issue as to WHY not?).

might as well just build the whole thing myself.

unless I've missed something here.

Re: lmd support -- available as an 'add on', or just 'compiled in'?

[PGNet Dev]

On 7/6/20 2:38 PM, Wietse Venema wrote:
> The plugin MUST be built with the exact same source code

That I figured.

> and the
> exact same compiler options that Postfix was built with.

that hadn't dawned on me yet.

> If there are differences then you end up with a Frankenstein monster
> with parts from different builds, and that is likely to misbehave.

thx for that clarification.  "Sold!"

then back to my own-builds -- either port-system-like local builds from source, 
or own rpms that fit the need (still useful to at least do the builds on 
external resources).

i've poked the F32 maintainer to get LMDB support added to their Postfix distro 
pkg builds; they've packaged lmdb already, after all.  THAT would be more 
convenient, and ensure the same-code/same-compiler req't; so far, no response. 
we'll see.

Re: lmd support -- available as an 'add on', or just 'compiled in'?

[PGNet Dev]

On 7/6/20 2:52 PM, Viktor Dukhovni wrote:
> Well, Fedora 31 does provide separate packages for multiple optional
> lookup table drivers:
> 
>  postfix-cdb.x86_64 : Postfix CDB map support
>  postfix-ldap.x86_64 : Postfix LDAP map support
>  postfix-mysql.x86_64 : Postfix MySQL map support
>  postfix-pcre.x86_64 : Postfix PCRE map support
>  postfix-pgsql.x86_64 : Postfix PostgreSQL map support
>  postfix-sqlite.x86_64 : Postfix SQLite map support
> 
> They just seem to have left out LMDB for some reason, don't know why.
> You reported opening an issue with the Fedora Postfix maintainers,
> that's the right thing to do.

For those interested,

LMDB support has now been added to Fedora builds of Postfix.

  https://src.fedoraproject.org/rpms/postfix/blob/master/f/postfix.spec#_787

I haven't yet installed / verified, but looking at the spec, it looks 
straightforward.

Atm, it's pending release; should promote soon-ish ...

re-directing disto-pkg'd postfix's bins etc to other config dir location?

[PGNet Dev]

i'm deploying a postfix server, using distr-pkg'd postfix

to date, i've always/only used postfix that i've built/installed to my liking.

i prefer to keep my configs under /usr/local/etc/postfix.

my postfix is config'd/built with config dir == /usr/local/etc/postfix.  so its 
bins (postconf, postfix, postsuper, etc etc) are are, by default, pointed to 
that config path.

distro pkgs are built with, typically, default config location == /etc/postfix. 
 similarly, its bins are pointed to THAT config path.

i simply want to ensure that the distro-pkg's bins get pointed to my configs in 
/usr/local/etc/postfix.

two simple ways to do that are

(1) ln -sf /usr/local/etc/postfix /etc/postfix

(2) shell alias each bin with "... -c /usr/local/etc/postfix", or 
shell-script-wrap in /usr/local/bin each postfix-bin, doing the same.

Is either (1) or (2) preferred for any reason?
Or is there a better way to accomplish this?

Re: re-directing disto-pkg'd postfix's bins etc to other config dir location?

[PGNet Dev]

On 7/17/20 7:52 PM, Viktor Dukhovni wrote:
> On Fri, Jul 17, 2020 at 07:31:11PM -0700, PGNet Dev wrote:
> 
>> I simply want to ensure that the distro-pkg's bins get pointed to my
>> configs in /usr/local/etc/postfix.
>>
>> two simple ways to do that are
>>
>> (1) ln -sf /usr/local/etc/postfix /etc/postfix
> 
> This would be the preferred approach.  But (don't recall the details)
> that might elicit complaints from postfix-check, because the global
> config_directory is not a directory.

got it.

tbh, never checked 'postfix-check' myself in the symlink case.

DIY builds with

  export CCARGS = '... -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" ...'

nicely avoided the issue here.


>> (2) shell alias each bin with "... -c /usr/local/etc/postfix", or
>> shell-script-wrap in /usr/local/bin each postfix-bin, doing the same.
> 
> The drawback here is that it is liable to break multi-instance support.
> The "postmulti -x" command runs variaus postfix commands with the
> "MAIL_CONFIG" environment variable set to point to the right instance,
> but your "-c options" would incorrectly always force the default
> instance.

ah, good point. i don't use multi-instance much anymore, but on occasion ...

noted. thx.

> The best way may well be a loopback mount, if a symlink (1) creates
> non-trivial friction.

fair enuf; ez to do.

thx!

Re: re-directing disto-pkg'd postfix's bins etc to other config dir location?

[PGNet Dev]

> (3) Move the damned files to /etc/postfix

honestly . take a pill.

do me a favor.  put me in your delete filter.

or feel free to screech into the wind ... 

permit_tls_clientcerts usage in multiple restrictions?

[PGNet Dev]

i'd like to clarify mumble restrictions' checking in the case of tls 
clientcerts.

with settings of

 relay_clientcerts=lmdb:/etc/postfix/relay_clientcerts
 smtp_tls_session_cache_database = lmdb:/var/lib/postfix/smtp_cache
 smtp_tls_session_cache_database = lmdb:/var/lib/postfix/smtpd_cache

if i also set mumble restrictions of

 smtpd_client_restrictions=permit_tls_clientcerts,reject
 smtpd_relay_restrictions=permit_tls_clientcerts,reject

is a "permit_tls_clientcerts" check against 'relay_clientcerts' executed twice, 
or simply once, cached & reused?

if the check result _is_ cached, _is_ it in the tls_session_cache? or is the 
session cache unrelated here, and the restriction check result is held 
elsewhere?

how to map per-smtp-transport ssl certs/keys ?

[PGNet Dev]

i'm modifying a relay config.  atm, i've

master.cf
...
[127.0.0.1]:10001  inet  n  -  n  -  -  smtpd
...
-o content_filter=lmdb:/etc/postfix/relay_transports

relay-out  unix  -  -  n  -  -  smtp
-o smtp_tls_policy_maps=lmdb:/etc/postfix/relay_tls_policy
-o smtp_tls_cert_file=/ssl/client.RSA.crt
-o smtp_tls_key_file=/ssl/client.RSA.key

cat /etc/postfix/relay_transports

example1.com  relay-out:[mx.example1.com]:25
example2.com  relay-out:[mx.example2.com]:10025
...

cat /etc/postfix/relay_tls_policy
[mx.example1.com]:25 secure  match=mx.example1.com
[mx.example2.com]:10025  secure  match=mx.example2.com
...


this^ has worked just fine. 

my config, atm, uses the single RSA crt/key for all transports.


example2.com has just changed its requirements, and uses/accepts only EC certs.

where/how would I specify a per-transport cert/key pair?


i've read through

http://www.postfix.org/TLS_README.html

and haven't ID'd a relevant per-transport cert/key mapping


i considered

http://www.postfix.org/postconf.5.html#tls_server_sni_maps

but that seems server-side only (?),

"map names received from remote SMTP clients via the TLS Server Name 
Indication (SNI) extension to the appropriate keys and certificate chains. This 
parameter is implemented in the Postfix TLS library, and applies to both 
smtpd(8) and the SMTP server mode of tlsproxy(8)."


i also took a look at

http://www.postfix.org/postconf.5.html#smtp_tls_per_site

but, again, haven't figured out where/how to provide the per-transport cert/key 
mappings.

what's the correct approach here?

Re: how to map per-smtp-transport ssl certs/keys ?

[PGNet Dev]

On 7/20/20 2:45 PM, Viktor Dukhovni wrote:
> Perhaps you meant per-nexthop?  That's not presently supported,

Well that'll certainly make it harder to find!  Noted.

> instead you can configure a second transport, with a different set of keys, 
> and
> use that transport for the destinations in question.

That's simple enough to manage. Thx.

> You keep saying "per-transport", but you clearly mean per-destination.

Yup; fair enuf. Thx for 'fixing' my bad-lingo!

more detail in diagnosing verify "conversation ... timed out while receiving the initial server greeting" error?

[PGNet Dev]

i'm setting up 2 postfix instances on 2 separate boxes, 'frontend' & 'backend', 
to use address verification probes from front- to back-end

testing @ 'frontend', I can see the VRFY offered by the backend

openssl s_client \
 -4 \
 -bind 10.0.0.11 \
 -connect internal.backend.example.com:25 \
 -cert /sec/client.EC.crt \
 -key  /sec/client.EC.key \
 -CAfile /sec/ca_chain.crt

ehlo localhost
250-backend.example.com
250-PIPELINING
250-SIZE 104857600
250-VRFY
250-XFORWARD NAME ADDR PROTO HELO SOURCE PORT IDENT
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8

a test send from shell @ 'frontend'

sendmail -i -f root -t <: Recipient address rejected: unverified address: 
conversation with internal.backend.example.com[10.0.0.21] timed out while 
receiving the initial server greeting; from= 
to= proto=ESMTP helo=
Jul 20 14:32:30 frontend postfix/postscreen-internal/smtpd[20101]: 
disconnect from out2-smtp.messagingengine.com[66.111.4.26] ehlo=2 starttls=1 
mail=1 rcpt=0/1 data=0/1 rset=1 quit=1 commands=6/8
Jul 20 14:32:35 frontend postfix/verify[20106]: connection closed fd 128

and never hits the backend; at least, I see nothing in its logs

to troubleshoot, I'd like to get more detail out of 'verify' than

"conversation with internal.backend.example.com[10.0.0.21] timed out 
while receiving the initial server greeting"

, specifically, to find out _why_ a time-out is occurring.

_is_ there additional debug detail available from verify?

&/or, is there a standalone approach to 'exercise' just the address probe 
verify step?
perhaps in the openssl s_client connection session?

Re: more detail in diagnosing verify "conversation ... timed out while receiving the initial server greeting" error?

[PGNet Dev]

On 7/20/20 10:19 PM, Viktor Dukhovni wrote:
> This is plainly logged as a *cache* lookup.  The data in the cache entry
> was set to expire at epoch time 1595290292, or 2020-07-20T20:11:32-0400.

although that doesn't tell me _why_ the problem exists, it did point to _what_ 
it (apparently) was.

waiting past the 'expiry' times did nothing; but, manually _deleting_ all 
/var/lib/postfix/*cache* & restarting did the trick.

no further adjustments to my config req'd.

thx!

managing multiple virtual_alias_map *flat* files ?

[PGNet Dev]

I'm exploring an all flat-file virtual-address-only postfix setup.  well, using 
lmdb -- NOT sql or ldap, to be accurate.

When it comes to alias management, I'm not convinced my approach is (easily) 
doable in flat-files.

For each virtual address defined in

virtual_mailbox_maps= lmdb:/etc/postfix/virtual_mailbox_maps

e.g.,

cat virtual_mailbox_maps
us...@example.com example.com/user1
us...@example.com example.com/user2

rather than a single alias map file, I'd _like_ a separate virtual alias map 
per real address. i.e.,

/etc/postfix/virtual_alias_maps/us...@example.com
/etc/postfix/virtual_alias_maps/us...@example.com

where, e.g.,

/etc/postfix/virtual_alias_maps/us...@example.com 
ali...@example.comJUNKTEXT
ali...@example2.com   JUNKTEXT

/etc/postfix/virtual_alias_maps/us...@example.com 
ali...@example3.com   JUNKTEXT
ali...@example4.com   JUNKTEXT


, with JUNKTEXT ignored, and the redirect_to replaced by the filename -- in 
this case, "us...@example.com" & "us...@example.com", respectively.

can that be managed with postfix out of the box?

if so, what would be the form of

virtual_alias_maps = 

in postfix config?

And, does postifx do any checking to avoid multiple-instances of a single 
alias? I.e., preventing collisioin of the same alias redirecting to same target 
virtual address?

All of that^ is certainly doable with SQL/LDAP.

For this setup, If I _can_ avoid DB/LDAP, I'd like to ... just not convinced 
if/how I manage this^ without too much 'kludge'.


Thoughts/suggestions?

Re: managing multiple virtual_alias_map *flat* files ?

[PGNet Dev]

On 9/12/20 3:26 PM, Viktor Dukhovni wrote:
> What is the actual goal here?

having recently migrated a few boxes from my own, DIY'd app & prereq builds to 
distro pkg'ing reminded of the 'joys' of pulling in bloated dependencies, etc. 


i'm simply exploring an as-thin-as-possible/lightweight deployment.  minimal 
external dependencies, etc. -- ideally _just_ requiring a postfix install, and 
flatfiles.


> What sort of virtual alias management
> problem are you trying to solve by partitioning virtual aliases across
> multiple source files.

an interest in matching the way I organize my own information.  

> Why are you loathe to consider a database, ...

hardly loathe.

see above re: exploring & thin/lightweight

> Are you experiencing Qmail nostalgia? :-)

don't we all, secretly?

> Questions about how to assemble virtual aliases are premature absent a clear 
> data model.

Re: managing multiple virtual_alias_map *flat* files ?

[PGNet Dev]

On 9/12/20 5:03 PM, Viktor Dukhovni wrote:
> If this is just your own way to organise data managed by a single
> authority (you)

in _this_ case, it is.

> then organise it any way you like, then run "make"
> to create a single virtual(5) aliases file that you "postmap" in
> the usual way.

to date, on my rather more expansive installs, I've kept a list of disparate 
sources

i had simply not thought to use make to consolidate whatever hodge-podge i 
cobble up into a single aliases file.


perfect!



thx o/

local postfix re-delivery of dovecot sieve-redirected mail fails; normal/direct deliveries are OK ?

[PGNet Dev]

i've postfix + dovecot running on the same box; delivery between them is via 
lmtp.

all in/out-bound, direct traffic flows as expected, securely with TLS.

i've set up a sieve redirect @ dovecot.  on test send, the filter triggers, 
submits the redirect to local postfix ... and then the delivery of the redirect 
fails.

logs report an SSL error ...  I don't know yet _what_ the source of that error 
is.  or if it's a red-herring.
i _suspect_ the problem is on the dovecot/sieve end; maybe my sieve service 
config -- or, perhaps a bug there; either way, i'd like (dis)prove it to myself.

my initial questions at this point are simply:

do the current logs, below, suggest an obvious cause of the problem, 
whether postfix- or dovecot-?
if not, what specific logging on the postfix end should be enabled, or 
increased in verbosity, so as to get more detail re: relevant cause? if any.

here's what I see atm; after clean start

==> /var/log/dovecot/dovecot.log <==
Sep 27 10:08:11 mx postfix/postfix-script[14388]: starting the Postfix 
mail system
Sep 27 10:08:11 mx postfix/master[14390]: daemon started -- version 
3.5.7, configuration /etc/postfix

==> /var/log/dovecot/dovecot-info.log <==
2020-09-27 10:08:12 master: Info: Dovecot v2.3.10.1 (a3d0e1171) 
starting up for imap, submission, lmtp, sieve

where

postfix submission listens on 10.0.1.17:465
dovecot submission listens on 10.0.1.17:60465


& dovecot config includes

submission_host = internal.mx.example.com:60465
submission_relay_host   = internal.mx.example.com
submission_relay_port   = 465
submission_relay_ssl= smtps
submission_relay_ssl_verify = yes
submission_relay_trusted= yes
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode  = 0600
user  = postfix
group = postfix
}


& with a defined sieve filter,

ls -al /srv/vmail/sieve-scripts/us...@example1.net.sieve
lrwxrwxrwx 1 vmail vmail 64 Sep 26 12:31 
'/srv/vmail/sieve-scripts/us...@example1.net.sieve' -> 
/srv/vmail/example1.net/user1/Maildir/sieve/managesieve.sieve

cat /srv/vmail/sieve-scripts/us...@example1.net.sieve
# rule:[SIEVETEST]
if header :contains "subject" "SIEVETEST"
{
redirect "us...@example2.net";
}


mail send, NOT triggering the sieve filter,

echo "Subject: DIRECT" | /usr/sbin/sendmail.postfix us...@example1.net

succeeds/logs,


==> /var/log/dovecot/dovecot-info.log <==
2020-09-27 10:12:58 lmtp(15360): Info: Connect from local
2020-09-27 10:12:58 
lmtp(us...@example1.net): Info: sieve: 
msgid=<4bzsff0zm0zw...@mx.example.com>: stored mail into mailbox 'INBOX'
2020-09-27 10:12:58 lmtp(15360): Info: Disconnect from local: 
Client has quit the connection (state=READY)

==> /var/log/postfix/postfix.log <==
Sep 27 10:12:58 mx postfix/pickup[15271]: 4Bzsff0zM0zWf9N: 
uid=0 from=
Sep 27 10:12:58 mx postfix/cleanup[15343]: 4Bzsff0zM0zWf9N: 
message-id=<4bzsff0zm0zw...@mx.example.com>
Sep 27 10:12:58 mx postfix/qmgr[15270]: 4Bzsff0zM0zWf9N: 
from=, size=297, nrcpt=1 (queue active)
Sep 27 10:12:58 mx postfix/lmtp-relay/lmtp[15354]: 
4Bzsff0zM0zWf9N: to=, 
relay=internal.mx.example.com[private/dovecot-lmtp], delay=0.08, 
delays=0.01/0.01/0.01/0.04, dsn=2.0.0, status=sent (250 2.0.0 
 KFvkCRrIcF8APAAA+IOfAw Saved)
Sep 27 10:12:58 mx postfix/qmgr[15270]: 4Bzsff0zM0zWf9N: removed


& mail send, NOT triggering the sieve filter,

echo "Subject: DIRECT" | /usr/sbin/sendmail.postfix us...@example2.net

also succeeds/logs

tail -f /var/log/postfix/* /var/log/dovecot/*

==> /var/log/dovecot/dovecot-info.log <==
2020-09-27 10:13:25 lmtp(15406): Info: Connect from local

==> /var/log/postfix/postfix.log <==
Sep 27 10:13:25 mx postfix/pickup[15271]: 4Bzsln6T8wzWfB1: 
uid=0 from=
Sep 27 10:13:25 mx postfix/cleanup[15389]: 4Bzsln6T8wzWfB1: 
message-id=<4bzsln6t8wzw...@mx.example.com>
Sep 27 10:13:25 mx postfix/qmgr[15270]: 4Bzsln6T8wzWfB1: 
from=, size=297, nrcpt=1 (queue active)

==> /var/log/dovecot/dovecot-info.log <==
2020-09-27 10:13:25 
lmtp(us...@example2.net)<52dpOCXJcF8uPAAA+IOfAw>: Info: 
msgid=<4bzsln6t8wzw...@mx.example.com>: saved mail to INBOX
2020-09-27 10:13:25 lmtp(15406): Info: Disconnect from local: 
Client has quit the connection (state=READY)

==> /var/log/postfix/postfix.log <==
Sep 27 10:13:25 mx postfix/lmtp-relay/lmtp

Re: local postfix re-delivery of dovecot sieve-redirected mail fails; normal/direct deliveries are OK ?

[PGNet Dev]

On 9/28/20 1:27 PM, Viktor Dukhovni wrote:
> On Sun, Sep 27, 2020 at 11:31:43AM -0700, PGNet Dev wrote:
> 
>> i've postfix + dovecot running on the same box; delivery between them
>> is via lmtp.
> 
> The main thing that stands to me is the timeout connecing to the
> Dovecot submission port.

that _is_ postfix connecting "back" to dovecot via lmtp relay, _after_ 
receiving the redirected message from the sieve filter action, correct?

i suspect i may be incorrectly assuming that the chronology in postfix+dovecot 
logs is meaningfu :-/

>> ( this is a reproducible, exactly 30-second delay ... )
>>
>>  ==> /var/log/dovecot/dovecot.log <==
>>  2020-09-27 10:15:49 
>> lmtp(us...@example1.net): Error: smtp-client: conn 
>> internal.mx.example.com:60465 (10.0.1.17:60465) [1]: 
>> connect(internal.mx.example.com:60465) failed: Connection timed out after 30 
>> seconds
> --  PROBLEM LIKELY HERE --->
>>  2020-09-27 10:15:49 
>> lmtp(us...@example1.net): Error: sieve: 
>> msgid=<4bzsg33hvqzw...@mx.example.com>: redirect action: failed to redirect 
>> message to : smtp(internal.mx.example.com:60465): RCPT 
>> TO failed: Connect timed out (temporary failure)
> -- <---
> 

i saw that's where/when the Error: is occurring; wasn't clear whether it's the 
result of some message- &/or ssl- munging 'during' the sieve -> postfix -> 
dovecot circuit.

will look more closely here.

> However, ...
> 
>>  2020-09-27 10:15:49 submission-login: Debug: SSL error: 
>> SSL_accept() failed: error:1408F10B:SSL routines:ssl3_get_record:wrong 
>> version number
> The above again looks like cleartext (e.g. "QUIT") sent to a port that
> expects TLS.
> 
> 
>>  ==> /var/log/dovecot/dovecot-debug.log <==
>>  2020-09-27 10:15:49 submission-login: Debug: SSL error: 
>> SSL_accept() syscall failed: Invalid argument
> 
> And the above may be the reason why connections are timing out...

i'm pausing at that 'however' ... 

couple of questions:


i typically turn ON implicit TLS, with cert verification, for any all TCP 
transports, local or not.

when a postfix/dovecot, same-machine setup 'share' an lmtp socket, e.g.,

@ dovecot

...
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode  = 0600
user  = postfix
group = postfix
}
...


@ postfix

...
virtual_transport = lmtp:unix:private/dovecot-lmtp
...


iiuc, there's no security need/benefit for any TLS/SSL in that 
handshake/transport, and can (should?) be disabled.

is that correct?


and,

re: the "port that expects TLS", that appears to be the dovecot 
'submission-port'.

to be clear, do I understand your comment

> Since both the server and the client here are Dovecot

correctly that -- by that point -- postfix is out of the picutre completely, & 
no longer involved, and it's all a dovecot 'issue'?

> you might have better luck on the Dovecot list.

already posted; waiting on any interest/reply there.

useful to know that this is completely !postfix, if indeed the case.

Re: local postfix re-delivery of dovecot sieve-redirected mail fails; normal/direct deliveries are OK ?

[PGNet Dev]

On 9/28/20 2:06 PM, PGNet Dev wrote:
> already posted; waiting on any interest/reply there.
> 
> useful to know that this is completely !postfix, if indeed the case.

ironically, the problem's NOT that postfix *is* 'involved', but that it *isn't*.

use of dovecot's

submission_host = ...

to either have sieve use dovecot's own submission port, or even postfix's, was 
causal.


switching 

-   submission_host = ...

+   sendmail_path = "/usr/sbin/sendmail.postfix"



to instead use postfix's sendmail binary does the trick.

once the switch is made, sieve script generated forwards/redirects seem to work 
without error.

( i _do_ need to figure out how to correctly lock down use of the binary ...

  iiuc, i think this

authorized_submit_users = root, filter, vmail

 in postfix conf should be sufficient.
)

sounds like a dovecot submission proxy issue to me; any further chat about it 
I'll take to dovecot list.

Re: Recommended milters for small setup

[PGNet Dev]

On 10/15/20 8:19 AM, Ian Evans wrote:

> Is there a more efficient, memory stingy, faster milter way to run 
> spamassassin, clamav, etc, or would you recommend sticking with amavis?



very much personal choice.  each comes with it's challenges.
  for any set of choices, you'll get the usual assortment of pundits telling 
you why it's Bad(tm).


i'm not a fan of 'swiss army knife' apps that try to be all things to all 
people; i prefer the option to rip out & swap individual pieces if/as needed.

having _had_ that^ same stack, i first rm'd amavis
.


now, i've got:

 inbound:

  postscreen

  spf-engine (policy service)

  pre-q milters:

   opendkim
   opendmarc
   milter-regex
   clamav-milter
   spamassassin-milter (https://lib.rs/crates/spamassassin-milter)

 outbound:

  opendkim


for inbound, i'd like to replace opendkim/opendmarc with 
fastmail/authentication_milter --
-- but the project devs aren't terribly responsive.  not clear yet whether it's 
as bad as 'Trusted Domain Project' opendkim/opendmarc ...

for outbound, i'd again like to get rid of opendkim. but, so far, i've found no 
good packaged options that fit my needs.

DIY with Mail::DKIM is a pain, but doable, and on my "I'll get around to it 
eventually" list.

atm -- although it all still _feels_ a bit fragile -- this current setup is 
working well enough.

certainly lighter-weight than b4, and for me simpler to configure/manage.

my $0.02.

implementing offline/maintenance mode, with SMTP reply?

[PGNet Dev]

my usual postfix front-end workflow is

postscreen
if 'fail', reject
if 'pass', then
internal smtp
etc

i'd like to implement a 'maintenance/offline mode' -- WITH smtp response -- 
effectively adding

postscreen
if 'fail', reject
if 'pass', then
+   if 'maintenance mode' = ON, then
+   reply SMTP 4XX, msg = (user specified message, 
e.g. down 4 maintenance, try again in X hours) 
+   else if 'maintenance mode' = OFF, then
internal smtp
etc

there are many paths to that particular mountain.

is there an already built-in maintenance-mode, or somesuch, in postfix?
it'd be most convenient; if it's in docs, i've missed it.

i thought about monkeying with stress-adaptive behavior, but that seems like a 
bad rabbit-hole for this ...

Re: implementing offline/maintenance mode, with SMTP reply?

[PGNet Dev]

On 10/16/20 11:54 AM, Viktor Dukhovni wrote:

If the custom 4XX response is not a hard requirement, the simplest
solution is:

 main.cf:
 # To defer all email, change to: lunchtime = y
 lunchtime =
 smtpd_recipient_restrictions =
 ${lunchtime?defer_if_permit}
 ...
Which will still reject invalid recipients, ... and only defer what



you'd otherwise accept.



hadn't thought to defer.

this should work nicely. thx.

tho, s/lunchtime/cocktails/ might be needed.


If you really must have a custom 4XX response, then you can use:

 main.cf:
 # To defer all email, change to: lunchtime = y
 lunchtime =
 smtpd_client_restrictions =
 ${lunchtime?check_client_access static:{450 4.3.2 Scheduled 
downtime, come back later}}
 ...

Note that sites that do sender-address-verification (does anyone still
do that?) may then tempfail your outbound mail, during the downtime and
likely for some time after after you restore service.


noted.

unfortunately plenty of financial institutions do.

one fail-to-deliver and they toggle user prefs back to snail-mail -- AND send a "we 
were unable to deliver to your email" _letter_.
the avalanche of dead-tree propectuses roll nicely into firelogs ...

address verify probe cache not refreshing on new user/alias add'n ?

[PGNet Dev]

i've set up two postfix instances on 2 separate machines

frontend
backend

'backend' gets user data via postfixadmin/sqlite3 DB

i've setup address verification between the instances

on mail receipt @ 'frontend', a verify probe is sent to 'backend'.
if 'exists', then mail is sent frontend->backend; otherwise, rejected.

it works as intended.

except -- updates to user DBs at backend aren't being made available promptly.

if I add a mail alias at backend, via postfix admin, and immediately try to 
send to 'frontend' @ that address, it fails the verify probe.

restarting/reloading the 'backend' postfix doesn't fix the probe fail.

but,

rm -f /var/lib/postfix/{verify,postscreen}_cache.lmdb
postfix reload

atm, here

postconf -n | egrep "address_verify"
address_verify_cache_cleanup_interval = 12h
address_verify_map = lmdb:${data_dir}/verify_cache
address_verify_poll_count = ${stress?{1}:{3}}
address_verify_sender = pr...@verify.mx.example.net
address_verify_sender_ttl = 28657s

notably,

address_verify_sender_ttl = 28657s

is changed from default

address_verify_sender_ttl = 0s

per docs, i'd originally set this, way back when, to "avoid problems with senders that use 
greylisting" and "To defeat address harvesting ..."

re-reading now, i'm not so sure.



(1) _is_ the likely cause of the verify probe fail due to my config, above? or 
am i looking in the wrong place?

(2) beyond possibly causing the probe cache issue, are there particular reasons 
_not_ to set

address_verify_sender = pr...@verify.mx.example.net
address_verify_sender_ttl = 28657s

?

right tool for creating an 'accurate' test email from an external domain?

[PGNet Dev]

I'm troubleshooting an annoyingly problematic single-sender's rejections.

With my usual simple monkeying with smtpd_mumble_restrictions, per-milter 
whitelisting, etc. I haven't yet found all the problems.

For testing, I'd *like* to 'accurately' spoof an email from sender's 
IP/helo/from/to -- without having my hands on a received email -- to (re)inject 
into my postfix et al chain.

Ideally, into the postscreen front-end. Or, at least, as early as possible ...

To date, I've really only ever made sure to _avoid_ spoofing, etc, and 
validated with real/legit senders.

What's the right tool/method for the job?  Specifically, for synthesizing a 
'faux legit' email?

Re: right tool for creating an 'accurate' test email from an external domain?

[PGNet Dev]

On 10/20/20 7:41 PM, Viktor Dukhovni wrote:

On Tue, Oct 20, 2020 at 07:22:24PM -0700, PGNet Dev wrote:


What's the right tool/method for the job?  Specifically, for
synthesizing a 'faux legit' email?


http://www.postfix.org/XCLIENT_README.html


simple & does the trick.

perfect.

thx!

sanity-check postfix XCLIENT usage ?

[PGNet Dev]

I'm using Postfix's XCLIENT to synthesize/inject a test email into my 
postfix->filter/milter->delivery chain.

I'd like to verify that my XCLIENT usage isn't the cause of the delivery 
failure I see below ...

@ this postfix instance, mail flows as

-> postscreen (@ IP = 203.0.113.1)
|
internal smptd
|
spf policy engine (no reject; check + header only)
|
preQ milters: opendkim, opendmarc, clamav-milter, spamassassin-milter
|
lmtp -> dovecot

I've no inbound/outbound issues.

Except ...

... from a single source -- @intuit.com.  it's FAIL'ing @ opendmarc checks.

I've online-checked SPF/DMARC records for 'intuit.com'; all _seems_ to be ok.
I've cranked up opendmarc logging level to

MilterDebug 5

with that, on failed attempt, I see only an unhelpful

Oct 21 09:43:39 mx.example.com opendmarc[7977]: 4CGbb3aX1Pz2N: 
intuit.com fail

I'm trying to use XCLIENT to replicate the issue so I can test, rinse & repeat.

Trying 1st from @gmail.com (or any domain i've tried _other_ than 'intuit.com')

using data pulled from postfix logs for a SUCCESSFUL fr...@gmail.com delivery,
@ an opened 'openssl s_client' session to my postfix external IP, injecting

XCLIENT NAME=mail-vs1-f46.google.com ADDR=209.85.217.46 PORT=40169 
PROTO=ESMTP HELO=mail-vs1-f46.google.com DESTADDR=203.0.113.1 DESTPORT=25
MAIL FROM:
RCPT TO:
DATA
test message
(CR/LF)
.
(CR/LF)

mail passes all filters, and is delivered cleanly.

I'm able to repeat the success for any/all of the non-intuit.com senders I try.

Switching to the data pulled from postfix logs for a FAILED fr...@intuit.com 
delivery,
again @ an opened 'openssl s_client' session to my postfix external IP, 
injecting

XCLIENT NAME=55.57.138.139.in-addr.arpa.iphmx.com ADDR=139.138.57.55 
PORT=62440 PROTO=ESMTP HELO=esa3.hc3812-35.iphmx.com DESTADDR=203.0.113.1 
DESTPORT=25
MAIL FROM:
RCPT TO:
DATA
test message
(CR/LF)
.
(CR/LF)

fails in the session with

550 5.7.1 rejected by DMARC policy for intuit.com

and is not delivered.

Before I take this up as an opendmarc question (my config &/or bug), & do more 
thorough digging re: intuit's published records,

(1) Is there anything obviously wrong/missing in that^ XCLIENT usage generally, 
or in the specific intuit.com case above, that would suggest a cause for the 
dmarc/milter FAIL, that 1st needs fixing?

I _suspect_ not, given the success with all _other_ domains ...