[pfx] Re: Which DKIM application for postfix 3.9.0

[A. Schulze via Postfix-users]

Am 07.03.24 um 23:06 schrieb postfix--- via Postfix-users:

I have done some research and opendkim is the most recommended, however, other 
research states the opendkim has been abandoned by it's maintainers.

well, long story. yes, it //seem// to be abandoned, but you may use it on 
production level.


I run Solaris and therefore need to compile my applications, postfix and dkim.

then you could give opendkim a change. use this branch as starting point:
https://github.com/trusteddomainproject/OpenDKIM/tree/develop
At the end you get signing+validation for rsa, ed25519 using openssl3

btw: there is a mailing-list dedicated to OpenDKIM:

List-Help: 
List-Unsubscribe: 

List-Id: 
List-Subscribe: 

List-Owner: 
List-Post: 

last post was in may 2023, maybe it's still operational.
well, long story ...

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

[pfx] Re: Postfix stopped logging lines with sender IP addresses after upgrade

[A. Schulze via Postfix-users]

Am 02.01.24 um 20:44 schrieb Vince Heuser via Postfix-users:

smtp   inet  n   -   y   -   -   smtpd



Hi,

the smtp server run chroot. You need to configure syslog to listen on 
/path/to/postfix-chroot/dev/log
(usually /var/spool/postfix/dev/log)

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

[pfx] Value of client certificates, was: Re: Re: [ext] list.sys4.de fails with starttls

[A. Schulze via Postfix-users]

Am 25.09.23 um 22:11 schrieb Viktor Dukhovni via Postfix-users:

...
So, unfortunate as it may seem, they just increase
opportunities for failure, without adding anything by way of security.
...
Client certificates serve no purpose unless the server requests them and
knows what to do with them.


Hello Viktor,

OK, so far I can follow your arguments. But there is one thing that don't match 
in that picture:
It's how I see Google's outbound servers operate. ¹)
If I read my mail archive right, Google use client certificates at least since 
2015!

If operating SMTP clients with a client certificate is so dangerous and has no 
value,
why would google go that?

Andreas

¹) grep 'Trusted TLS connection established from' /var/log/mail | grep 
'.google.com\['
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] surprise with strict_mime_encoding_domain

[A. Schulze via Postfix-users]

Hello,

an SMTP Server with strict_mime_encoding_domain=yes blocked some messages 
(which was ... unexpected)

# postconf mail_version
mail_version = 3.7.4

# postconf -n
alias_maps =
maillog_file = /dev/stdout
smtpd_recipient_restrictions = defer
strict_mime_encoding_domain = yes

# postconf -M
smtp   inet  n   -   -   -   -   smtpd
postlogunix-dgram n  -   -   -   1   postlogd
proxymap   unix  -   -   -   -   -   proxymap
rewriteunix  -   -   -   -   -   trivial-rewrite
cleanupunix  n   -   -   -   0   cleanup

# telnet localhost 25
220 d1fdbe288619.localdomain ESMTP Postfix
helo localhost
250 d1fdbe288619.localdomain
mail from:<>
250 2.1.0 Ok
rcpt to:
250 2.1.5 Ok
data
From: 
To: 
Subject: invalid message?
Date: Sat, 01 Apr 2023 18:00:00 +
Message-Id: 
Mime-Version: 1.0
Content-Type: multipart/signed;
boundary="mua-name=_some_random";
protocol="application/pkcs7-signature";
micalg=sha-256
Content-Transfer-Encoding: quoted-printable

--mua-name=_some_random
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8



--mua-name=_some_random
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64


--mua-name=_some_random--
.
550 5.6.0 invalid message/* or multipart/* encoding domain




https://www.postfix.org/postconf.5.html#strict_mime_encoding_domain mention it: 
"This blocks mail from poorly written software"
Well, the MUA is "Apple Mail" ...

I can't tell for sure if the message data is valid Mime.

Andreas

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

[P-U] OpenDMARC crash, was: Re: Postfix lists are migrating to a new list server

[A. Schulze via Postfix-users]

Am 07.03.23 um 20:37 schrieb postfix--- via Postfix-users:

OpenDMARC is segfaulting. That's what 'signal 11' means. Postfix fails to get 
an answer to its end-of-body milter call because of the segfault closing the 
other end of that socket. That failure results in Postfix sending a 4xx to the 
client.


To let postfix not defer such messages, one could define

  opendmarc_milter = { inet:host:port, default_action=accept }

see http://www.postfix.org/MILTER_README.html#per-milter

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

Re: dig reports NXDOMAIN but Postfix thinks otherwiese

[A. Schulze]

Am 06.12.22 um 19:06 schrieb Fred Morris:
 

This is a good use for DNS Response Policy Zones (RPZ) to prevent leakage, as 
well as an illustration of why doing some broad brush statistical monitoring of 
DNS traffic is a useful practice.


it's easier to consequent avoid 'search' in /etc/resolv.conf on servers ...

Andreas

Re: DMARC in postfix ?

[A. Schulze]

Am 13.04.22 um 05:31 schrieb John Levine:
> For doing DMARC validation, I know about the opendmarc milter.  Is that what
> everyone uses?  Is there anything else used in pratice?

Hello John,

rspamd handle DMARC as well.


But it's also a milter. This is intentional: Wietse / 
http://www.postfix.org/MILTER_README.html say
"Having yet another Postfix-specific version of all that software is a poor use 
of human and system resources."

Andreas

strict_7bit_headers, strict_8bitmime and strict_8bitmime_body

[A. Schulze]

Hello,

the documentation say for these settings:

> This feature should not be enabled on a general purpose mail server, because 
> it is likely to reject legitimate email

Is it possible to activate a kind of log only mode similar to "warn_if_reject"?
That would allow administrators to know, which kind of messages would be 
rejected.

Andreas

Re: logging from scripts executed by pipe

[A. Schulze]

Wietse Venema:


A. Schulze:

Is there a recommended/any way to log messages from a script via postfix?


Not at this time. Making the postlog command setgid requires a security
analysis and that may require some code restructuring before this can
be done without opening up a security hole.



Hello Wietse,

somehow I expected this "not yet supported"
That's OK for me, thanks for clarification.

I'll setup a separate syslogd for my application until better options  
are available.


Andreas

logging from scripts executed by pipe

[A. Schulze]

Hello,

I've to rebuild a service: messages to an address are delivered via postfix 
pipe to a script.
This script use syslog to write it's messages. That worked well for years.

Now, postfix run in a different way, supervised via "postfix start-fg" (docker)
Essentially the is no syslogd.

My idea was to use postlog.

Pipe refuse to execute an external script as root or mail system owner. 
(http://www.postfix.org/pipe.8.html, user= ...)
Users other then postfix/postdrop may invoke $command_directory/postlog,
but postlog could not connect to the postlogd as it's not running as root or 
postfix/postdrop.

Is there a recommended/any way to log messages from a script via postfix?

Andreas

Re: Mail server without MX record.

[A. Schulze]

Am 13.10.20 um 14:09 schrieb Jason Long:
> I want to know can I use it without MX record?
A records are used by default if no MX is available
That's nothing postfix specific - it's an RFC requirement for any MTA

Andreas

debugging strategy

[A. Schulze]

Hello,

I operate a postfix server + some milters. Some messages running over this MTA 
generate some trouble on the receiver side.
I nailed down the problem to be the content, I receive from the client. It's an 
application I personally don't control.
To Debug the problem, I must ask an other person to send a test message to me. 
Other messages I send by myself over the same channel
do not trigger the problem. So I can't reproduce the trouble myself.

My idea was to put relevant messages in the Hold queue. But from there I could 
release them exactly once.

I like to capture the problematic traffic and resend how often I like.
Any hints are appreciated.

Thanks,
Andreas

you may guess how my weekend will look like?

Re: Cannot assign requested address -- with "inet_protocol = ipv4" in main.cf

[A. Schulze]

Am 25.06.20 um 20:58 schrieb Greg Sims:
> I set "inet_protocol = ipv4" in main.cf .

postconf inet_protocol
postconf: warning: inet_protocol: unknown parameter

postconf inet_protocols
 ?

Andreas

Re: Postfix restrictions

[A. Schulze]

Am 07.06.20 um 14:38 schrieb yuv:
> Is there a valid reason for a sender not to fix something so essential
> as DNS configuration?

no valid reason but reality.

There are so many sendings hosts named "foobar.local". Via NAT they are visible 
with a public IP
and a perfect DNS. But this hosts still say "EHLO foobar.local"

It's the receivers policy how to handle such connections.
reject_unknown_helo_hostname reject them.

Andreas

Re: Postfix restrictions

[A. Schulze]

Am 07.06.20 um 11:51 schrieb Nicolas Kovacs:

using "reject_unknown_helo_hostname" may trigger some false positives. Not 
every sender have such perfect setups.
You may use "warn_if_reject reject_unknown_helo_hostname" for some time and 
check if loosing such traffic is acceptable for you.

Andreas

Re: Are there plans for a buld-in support of REDIS-tables?

[A. Schulze]

Am 09.01.20 um 17:12 schrieb kris_h:
> We distribute the more dynamic tables - e.g. cidr-tables with self-harvested
> current spammer's IPs - actually by simply distributing those files with
> rsync.

we use an rbldnsd to build and serve an internal zone with similar data.
Usual DNS lookups are done by postfix (reject_rbl_client and 
reject_rhsbl_client)
it's fast enough (for our use-cases)

Andreas

MDB_MAP_FULL: Environment mapsize limit reached

[A. Schulze]

Hello,

running postfix-3.4.7 on Debian 10 I found the following warning in my logs:

postfix/tlsmgr[705]: warning:  
lmdb:/var/lib/postfix/smtp_tls_session_cache is unavailable. open  
database /var/lib/postfix/smtp_tls_session_cache.lmdb: MDB_MAP_FULL:  
Environment mapsize limit reached


on two moderate loaded servers there where thousands of them, each  
generated by the same tlsmgr PID
Messages got delivered without other trouble. I guess, simply reusing  
TLS sessions did not happen.
The database files /var/lib/postfix/smtp_tls_session_cache.lmdb had  
sizes of ~20 and ~32 MB.


I've other instances with smtp_tls_session_cache of 400 MB but there I  
use old BDB format and postfix-3.4.6.
I've also other instances where also LMDB is used for  
smtp_tls_session_cache and the files are ~40 MB large.

But there, postfix-3.4.5 is installed.

smtp_tls_connection_reuse is explicit set to "yes" and lmdb_map_size  
is at it's default ( ~16 MB ) on all of my instances.


For now "rm /var/lib/postfix/smtp_tls_session_cache.lmdb; postfix  
reload" made the warning go away.


Wild guess: there where some code changes for tls_fast_shutdown_enable  
between 3.4.5 and 3.4.7

(20190615 and 20190723)

Andreas

Re: different message_size_limit per smtpd (solved)

[A. Schulze]

Am 20.11.19 um 17:57 schrieb @lbutlr:
>> The SMTP daemon also enforces the message size limit independently.
>> You can therefore specify different limits on the submission and
>> port25 services.
>>
>> However, those limits cannot be larger than the limit that is
>> enforced by the cleanup daemon.
> 
> How do you set a different limit in cleanup then? Or do you set 
> message_size_limit to the maximum size for submission and then set a separate 
> limit for smtpd? How would you do that?
> 
> main.cf:
>message_size_limit=4000
> 
> smtpinet  n - - - - smtpd
>   -o message_size_limit= 512
> 
> And leave submission alone?
just verified it work exactly this way...

Andreas
 

different message_size_limit per smtpd

[A. Schulze]

Hello,

My goal is to allow different message size on MX and submission.
As message_size_limit is a cleanup option, this is my (non working) setup
based on http://www.postfix.org/BUILTIN_FILTER_README.html#mx_submission

main.cf
  message_size_limit = 512

master.cf
  # define a separate cleanup service
  submission-cleanup unix  n - - - 0 cleanup
-o syslog_name=postfix/submission
-o message_size_limit=4000

  # MX smtpd use default cleanup with size=5 MB
  smtp   inet  n - - - - smtpd

  # Submission smtpd use separate cleanup with size=40 MB
  587inet  n - - - - smtpd
   -o cleanup_service_name=submission-cleanup
   -o smtpd_recipient_restrictions=permit_tls_clientcerts,reject
   -o syslog_name=postfix/submission

But that don't work as intended. Both smtpd announce size=5MB
Running multiple postfix instances should solve the problem.
are there other solutions?

Thanks
Andreas

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

[A. Schulze]

Am 19.11.19 um 10:58 schrieb Merrick:
> may we suggest ICANN not open a new TLD anymore?
yes, you can: https://www.icann.org/public-comments

Re: postfix startup sequence

[A. Schulze]

Am 12.11.19 um 03:52 schrieb Fourhundred Thecat:
>   /usr/sbin/postfix quiet-quick-start

this is Debian specific
https://sources.debian.org/src/postfix/3.4.5-1/debian/patches/09_quiet_startup.diff/

You've to ask on a Debian list because - Wietse already noted - it's unsupported

Andreas

build in EDH parameters

[A. Schulze]

Hello Developers,

postfix comes - like many other software - with build in DH Parameter (file: 
src/tls/tls_dh.c)
The documentation also suggest one may want to generate own DH parameters. 
(http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start)

Is that still the best solution? RFC 7919 (https://tools.ietf.org/html/rfc7919) 
offer a "Supported Groups Registry"

Andreas

Re: "SPF no-mail record" clashing with reject_unknown_recipient_domain

[A. Schulze]

Ehlers, Y.W. (Ydo):


There is no MX record, there is no A record, so mail can not be delivered.
And Microsoft tops it off by explicitely claiming no e-mail will be send
from this domain


for the record: one like to use RFC 7505 to express "this domain don't  
send / receive email"


adding an SPF -all is more one of many advises described in the fine  
MAAWG BCP:

https://www.m3aawg.org/sites/default/files/m3aawg_parked_domains_bp-2015-12.pdf

Andreas

Re: Respecting MTA-STS

[A. Schulze]

Am 11.10.19 um 18:10 schrieb Viktor Dukhovni:
> So likely at this point it is safe to conclude that sending SNI is
> unlikely to cause problems.  Your mileage may vary.

Hi,

that Gmail enabled SNI on their SMTP client is an indicator that using SNI may 
not cause relevant trouble.
But it's also known, Gmail is able to do such stuff very selective to prevent 
damage.

In theory, an SMTP client, postfix smtp for example, could always try to 
connect to a remote destination
using SNI, log success or failure and fallback to reconnect without SNI.
That would enable users to gather their own statistics.

reading http://www.postfix.org/postconf.5.html#smtp_tls_servername give me the 
impression one
could set "smtp_tls_servername = hostname". That would force the SMTP client to 
always send SNI.

The admin can monitor the log for additional delivery failures and gather 
statistics.
Right?

Andreas
 

Re: Respecting MTA-STS

[A. Schulze]

micah anderson:


If we want to try and respect MTA-STS, when doing STARTTLS, the sender
needs to send the right information in the TLS SNI (Server Name
Inidication) extension. An MTA-STS-honoring SMTP client expects to
validate the X.509 certificate of the receiving MTA, but that MTA might
be known by a dozen names, unless the SNI is provided.


I don't fully understand the value of SNI for MTA-to-MTA communication,
but that's an other problem.

I suggest to look at https://github.com/Snawoot/postfix-mta-sts-resolver ...

Andreas

Re: PATCH: tlsproxy failed / flooded log (WORKS)

[A. Schulze]

Am 06.09.19 um 20:50 schrieb A. Schulze:
> Hopefully I could report "works well" some days later.

Hello,

The patched version run here on some production server for a week without 
issues.
So here is the promised "works well" :-)

Andreas

Re: PATCH: tlsproxy failed / flooded log

[A. Schulze]

Am 06.09.19 um 18:30 schrieb Wietse Venema:
> To enable SMTP/TLS connection reuse on a running system:
> 
> postconf smtp_tls_connection_reuse=yes
> postfix reload
> 
> To disable SMTP/TLS connection reuse on a running system:
> 
> postconf smtp_tls_connection_reuse=no
> postfix reload (this also flushes the connection cache)
> manually kill any looping tlsproxy process
> 
> Unfortunately, already running SMTP client processes will keep using
> "smtp_tls_connection_reuse=yes" and talk to tlsproxy until they
> have exhausted alternate MXes (subject to smtp_mx_address_limit and
> smtp_mx_session_limit). But the odds of the problem returning will
> be small.
> 
>   Wietse
> 
> 20190906
> 
>   Bugfix: don't whitewash OpenSSL errors after the plaintext
>   channel is disabled, to avoid looping on "shutdown while
>   in init" errors. File: tlsproxy/tlsproxy.c.
> 
> diff --exclude=man --exclude=html --exclude=README_FILES --exclude=INSTALL 
> --exclude=.indent.pro --exclude=Makefile.in -r -ur 
> /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c 
> ./src/tlsproxy/tlsproxy.c
> --- /var/tmp/postfix-3.5-20190724/src/tlsproxy/tlsproxy.c 2019-07-23 
> 18:54:20.0 -0400
> +++ ./src/tlsproxy/tlsproxy.c 2019-09-06 12:12:27.0 -0400
> @@ -678,7 +678,8 @@
>   /*
>* Allow buffered-up plaintext output to trickle out.
>*/
> - if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
> + if (state->plaintext_buf && NBBIO_ACTIVE_FLAGS(state->plaintext_buf)
> + && NBBIO_WRITE_PEND(state->plaintext_buf))
>   return (TLSP_STAT_OK);
>   tlsp_state_free(state);
>   return (TLSP_STAT_ERR);
> 

Hello Wietse,

thanks for you effort. I'll deploy a patched version in my lab environment
and update the production systems next week. Hopefully I could report "works 
well" some days later.

nice weekend!
Andreas 

Re: tlsproxy failed / flooded log

[A. Schulze]

Am 06.09.19 um 14:24 schrieb Wietse Venema:

Hello Wietse!

> Any particular Postfix and OpenSSL version?
postfix-3.4.6
openssl-1.1.1c

> Does setting tls_fast_shutdown_enable (or tls_fast_shutdown)
> make a difference?
I could set tls_fast_shutdown = no and try again.
Unfortunately that mean I risk an outage on a production system.

Andreas

tlsproxy failed / flooded log

[A. Schulze]

Hello,

today I enabled smtp_tls_connection_reuse on some production server.
after approx. an hour and ~70 reused SMTP connections, tlsproxy on two  
machines logged this:


...
Sep  6 09:03:52 idvmailout03 postfix/tlsproxy[18637]: DISCONNECT  
[213.23.92.204]:25
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:1409F07F:SSL routines:ssl3_write_pending:bad  
write retry:ssl/record/rec_layer_s3.c:1131:
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:59 idvmailout03 postfix/tlsproxy[18637]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:

...

...
Sep  6 09:03:47 idvmailout04 postfix/tlsproxy[22852]: DISCONNECT  
[77.75.78.42]:25
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:1409F07F:SSL routines:ssl3_write_pending:bad  
write retry:ssl/record/rec_layer_s3.c:1131:
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:
Sep  6 09:03:49 idvmailout04 postfix/tlsproxy[22852]: warning: TLS  
library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown  
while in init:ssl/ssl_lib.c:2077:

...

that continue until the logfile occupied all diskspace with up to 15k  
lines per second



After I enabled smtp_tls_connection_reuse, there was only one tlsproxy process

Sep  6 08:26:21 idvmailout04 postfix/tlsproxy[21687]: CONNECT to  
[80.67.18.126]:25
Sep  6 08:28:19 idvmailout04 postfix/tlsproxy[21687]: DISCONNECT  
[193.158.9.202]:25


Sep  6 08:28:25 idvmailout04 postfix/tlsproxy[21832]: CONNECT to  
[176.9.125.207]:25
Sep  6 08:31:19 idvmailout04 postfix/tlsproxy[21832]: DISCONNECT  
[64.233.166.27]:25



but very fast postfix begun to spawn two instances overlapping


Sep  6 08:30:43 idvmailout04 postfix/tlsproxy[21961]: CONNECT to  
[104.47.4.36]:25
Sep  6 08:32:05 idvmailout04 postfix/tlsproxy[21961]: DISCONNECT  
[193.143.77.14]:25


Sep  6 08:31:25 idvmailout04 postfix/tlsproxy[22024]: CONNECT to  
[194.8.120.225]:25
Sep  6 08:32:48 idvmailout04 postfix/tlsproxy[22024]: DISCONNECT  
[185.15.192.56]:25


Sep  6 08:32:55 idvmailout04 postfix/tlsproxy[22075]: CONNECT to  
[95.130.253.60]:25
Sep  6 08:36:18 idvmailout04 postfix/tlsproxy[22075]: DISCONNECT  
[91.220.42.201]:25


these are the nondefault options for tlsproxy
tls_high_cipherlist =  
HIGH:+aRSA:+SHA384:+SHA256:+DH:+SHA:+kRSA:!eNULL:!aNULL:!PSK:!SRP:!AESCCM:!DSS:!ARIA

tls_medium_cipherlist = aNULL:-aNULL:CHACHA20:HIGH:MEDIUM:+RC4:@STRENGTH
tls_preempt_cipherlist = yes

interesting:
# postconf tls_fast_shutdown_enable
postconf: warning: tls_fast_shutdown_enable: unknown parameter

http://www.postfix.org/postconf.5.html#tls_fast_shutdown_enable say  
nothing about a specific postfix version number is required for this  
parameter
but http://www.postfix.org/tlsproxy.8.html do say,  
tls_fast_shutdown_enable is available in 3.4.6
also, it' a very new feature:  
http://www.postfix.org/announcements/postfix-3.4.6.html


# postconf mail_version
mail_version = 3.4.6

A grep in the source also found "tls_fast_shutdown" without "_enable"

# postconf tls_fast_shutdown
tls_fast_shutdown = yes

Looks, like the documentation is incorrect. But may that be related to  
the problem?

postconf -Mf and postfonf -f attached.
Just disabled smtp_tls_connection_reuse again...

Andreas
relay  unix  -   -   y   -   -   smtp
-o smtp_fallback_relay=
-o syslog_name=postfix/${service_name}
flush  unix  n   -   y   1000?   0   flush
trace  unix  -   -   y   -   0   bounce
verify unix  -   -   y   -   1   verify
proxymap   unix  -   -   -   -   -   proxymap
anvil  unix  -   -   y   -   1   anvil
scache unix  -   -   y   -   1   scache
discardunix  -   -   y   -   -   discard
tlsmgr unix  -   -   y   1000?   1   tlsmgr
retry  unix  -   -   y   -   -   error
pickup unix  n   -   y   60  1   pickup
cleanupunix  n   -   y   -   0   cleanup
qmgr   unix  n   -   y   300 1   qmgr
rewriteunix  -   -   y   -   -   trivial-rewrite
bounce unix  -   -   y   -   0   bounce
defer  unix  -   

Re: CAfile problem with OpenSSL-1.1.1c

[A. Schulze]

Christian Rößner:

Hello Christian,

By changing *_CAfile parameters to *_CApath, everything started  
working again.


nothing specific to your OpenSSL version but: do you run postfix chroot?
from http://www.postfix.org/postconf.5.html#smtpd_tls_CApath:

  "To use smtpd_tls_CApath in chroot mode, this directory (or a copy)  
must be inside the chroot jail."


Andreas

OT:

tls_ssl_options = NO_COMPRESSION


as you're using latest postfix+openssl, you may want to add "no_renegotiation"

Re: Is it possible to run postfix in a container (e.g. docker, red-hot)?

[A. Schulze]

Am 07.08.19 um 09:32 schrieb Gerben Wierda:
> Is it possible to run postfix in a container (e.g. docker, red-hot)? 

Yes, since postfix-3.4 you could start postfix with "postfix start-fg"
If you also set "maillog_file = /dev/stdout" in main.cf, any log will go to 
stdout which is the preferred "docker way"

We use this setup since a year or so, handover all logs to splunk and also this 
works like expected.

some advise:

 - do not use multi-instance setup -> use multiple container
 - make $(postconf data_directory) and $(postconf queue_directory) persistent 
volumes, separate per container
 - $(postconf config_directory) could be mounted read only
 - docker healthcheck can be used to monitor the number of items in a deferred 
queue
 - "postfix reload" works

-> works, give it a try :-)

Andreas

Re: Greylisting -- current recommendations?

[A. Schulze]

Am 23.06.19 um 16:57 schrieb Matus UHLAR - fantomas:
> On 22.06.19 14:43, A. Schulze wrote:
>> I'm still using greylisting with moderate effects. It catches some percent 
>> other AntiSpam technics doesn't
> 
> even compared to postscreen?
yes

while running postscreen and postgrey I still see some connections deferred by 
postgrey...
no more details available on a sunday.

Andreas

Re: Greylisting -- current recommendations?

[A. Schulze]

Am 22.06.19 um 02:49 schrieb Rich Wales:
> Any other suggestions?

I'm still using greylisting with moderate effects. It catches some percent 
other AntiSpam technics doesn't

Andreas

Re: Mails to gmail bouncing

[A. Schulze]

Am 19.06.19 um 12:53 schrieb Viktor Dukhovni:
>> On Jun 19, 2019, at 6:37 AM, Ralf Hildebrandt  wrote:
>>
>> The error message says:
>>
>> Protocol error: host gmail-smtp-in.l.google.COM[173.194.76.26] said: 250 
>> 2.1.5 OK w9si551343wmd.47 - gsmtp (in reply to DATA command)
> 
> Ralf, your inattention to detail disappoints me. :-(
> 
> The correct reply to "DATA" is "354" not "250".  Something is awfully
> out of sync if Gmail is returning "250" in response to "DATA".

to me this looks more as a 250 OK response _after_ data is sent because a 
typical queue ID is part of the response string.
I cannot see such errors at a "fast grep" here.

Wild guess: smtp-server (or your client) is abnormal and you hit exactly such 
an instance.
-> could you correlate the error with an IP?
-> could you enable debug_peer_list for one/some/all? servers generating this 
error?

and: which postfix version do you run?
( @mail-cvk <-> python.org )

Andreas 

Re: postfix and MTA-STS

[A. Schulze]

Hello Viktor,


Am 27.04.19 um 23:26 schrieb Viktor Dukhovni:
> The socketmap service could check for DANE TLSA records first, and> return 
> "dane", it would have to check that the domain is DNSSEC> signed, and then 
> check whether all of (the first 10 by preference> to reduce delay) the MX 
> hosts have TLSA records.
That mean the external application will do the same job as postfix does:
determine DANE TLSA records but not validating them, right?

Isn't implementing the same job in multiple places what Wietse name "waste of 
ressources"?
:-)

> Adding the full trust store is largely harmless, unless your goal
> is to "harden" MTA-STS by trusting only the subset of CAs actually
> used in practice by "real" MTA-STS domains.

sounds reasonable, will think about that...

Andreas

postfix and MTA-STS

[A. Schulze]

Hello,

one way to implement MTA-STS in postfix is a server that generate responses
that smtp_tls_policy_maps can consume. I evaluate 
https://github.com/Snawoot/postfix-mta-sts-resolver...

smtp_tls_policy_maps = socketmap:inet:mta-sts-resolver.example:8461:postfix


this works, but ...
the MTA-STS Policy is also locked up for destinations that may be verified by 
DANE.

So, where is the problem?

I could setup a MTA without access to the usual CA trust store data - SMTP via 
TLS is opportunistic.
Also image a destination (mail.de or my domain for example) that could be 
verified by DANE *and* publish
a MTA-STS policy.

If an MTA connect to such a destination the smtp_tls_policy_maps setup 
"overwrite" DANE
by returning "secure match=$(MX-List from MTA-STS)"
Now the MTA is required to have access to a CA truststore, otherwise the 
smtp_tls_policy_map result
let the MTA not deliver the message.

Somehow I feel uncomfortable with such a setup but I've no idea how to avoid 
that with the current postfix-3.4.5
(beside providing postfix access to a full CA trust store)

Andreas

unknown tls_ssl_options value "tlsext_padding"

[A. Schulze]

Hello,

postfix-3.4.4 linked with openssl-1.1.1b

$ postconf tls_ssl_options
tls_ssl_options = no_compression, tlsext_padding

produce such log:
Mar 30 21:04:12 danube postfix/smtpd[9075]: warning: unknown tls_ssl_options 
value "tlsext_padding" in "no_compression, tlsext_padding"

while it does make no sense, I placed all options [1] and still get only errors 
regarding tlsext_padding:
Mar 30 21:10:48 danube postfix/smtpd[9222]: warning: unknown tls_ssl_options 
value "TLSEXT_PADDING" in "ENABLE_MIDDLEBOX_COMPAT, LEGACY_SERVER_CONNECT, 
NO_TICKET, NO_RENEGOTIATION, NO_SESSION_RESUMPTION_ON_RENEGOTIATION, 
PRIORITIZE_CHACHA, TLSEXT_PADDING"

[1] http://www.postfix.org/postconf.5.html#tls_ssl_options

Andreas

documentation of mnaillog_file

[A. Schulze]

Hello,

http://www.postfix.org/postconf.5.html#maillog_file say
  "A non-empty value selects logging to syslogd"

I think it should say
  "A empty value selects logging to syslogd"

Andreas

Re: Understanding the importance of submission

[A. Schulze]

Am 20.03.19 um 16:18 schrieb Patrick Ben Koetter:
> Use submission on TCP/587 for MUA to MTA traffic.

Btw:

RFC 8314 describe Implicit TLS for POP3, IMAP and Submission
on ports 995, 993 and 465. Works fine the usual modern MUAs
and eliminate the opportunity for downgrades while talking plaintext+STARTTLS

Andreas

Re: Uhm... next bug or my faulty configuration?

[A. Schulze]

Viktor Dukhovni:


Your no-BDAT work-around is sufficient until the code is updated
along lines below



Hello Viktor,

Thanks for that patch. I confirm it works like expected

Andreas

Uhm... next bug or my faulty configuration?

[A. Schulze]

Hello,

updated from 3.4.1 to 3.4.3 and at the same time dovecot-2.2 to dovecot-2.3 ( + 
pigeonhole)
I assume the changes behavior is dovecot/pigeonhole now using the advertised 
"CHUNKING" extension.

Now an echo service (dovecot-2.3-pigeonhole) don't send messages anymore.
Reason: "Data command rejected: Multi-recipient bounce" while there is clearly 
only one recipient.

the relevant debug logs:

Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 220 signing-milter.org ESMTP 
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: < 
signing-milter.org[84.200.211.109]: EHLO signing-milter.org
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-signing-milter.org
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-PIPELINING
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-SIZE 128000
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-ENHANCEDSTATUSCODES
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-8BITMIME
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-DSN
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250-SMTPUTF8
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250 CHUNKING
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: < 
signing-milter.org[84.200.211.109]: MAIL FROM:<>
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250 2.1.0 Ok
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: < 
signing-milter.org[84.200.211.109]: RCPT TO:
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 250 2.1.5 Ok
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: < 
signing-milter.org[84.200.211.109]: BDAT 882 LAST
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: >>> START Data 
command RESTRICTIONS <<<
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: generic_checks: 
name=reject_multi_recipient_bounce
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: 44JCRG5tYPzCqt2: 
reject: BDAT from signing-milter.org[84.200.211.109]: 550 5.5.3 : Data 
command rejected: Multi-recipient bounce; from=<> to= 
proto=ESMTP helo=
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: generic_checks: 
name=reject_multi_recipient_bounce status=2
Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: >>> END Data command 
RESTRICTIONS <<<

Mar 11 23:27:54 dili postfix-smo/submission/smtpd[22427]: > 
signing-milter.org[84.200.211.109]: 550 5.5.3 : Data command rejected: 
Multi-recipient bounce, servertime=Mar 11 23:27:54, server=signing-milter.org, 
client=84.200.211.109


current solution: run the smtpd with "smtpd_discard_ehlo_keywords=CHUNKING"

Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 220 signing-milter.org ESMTP 
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: < 
signing-milter.org[84.200.211.109]: EHLO signing-milter.org
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: discarding EHLO 
keywords: CHUNKING
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: match_list_match: 
signing-milter.org: no match
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: match_list_match: 
84.200.211.109: no match
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-signing-milter.org
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-PIPELINING
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-SIZE 128000
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-ETRN
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-ENHANCEDSTATUSCODES
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-8BITMIME
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250-DSN
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250 SMTPUTF8
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: < 
signing-milter.org[84.200.211.109]: MAIL FROM:<>
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250 2.1.0 Ok
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: < 
signing-milter.org[84.200.211.109]: RCPT TO:
Mar 11 23:37:57 dili postfix-smo/submission/smtpd[22846]: > 
signing-milter.org[84.200.211.109]: 250 2.1.5 Ok
Mar 11 23:37:57 dili 

Re: PATCH: tls reuse and wrappermode (port 465)

[A. Schulze]

Am 19.02.19 um 19:48 schrieb Wietse Venema:
> A. Schulze:
>>> Feb 19 14:24:09 spider postfix/submissions/smtp[3895]: panic: 
>>> VSTREAM_CTL_SWAP_FD can't swap descriptors between single-buffered and 
>>> double-buffered streams
> 
> That was the result of wrappermode never having been tested with
> tlsproxy mode turned on.
> 
>   Wietse
> 
> *** src/smtp_proto.c- 2019-02-08 17:22:24.0 -0500
> --- src/smtp_proto.c  2019-02-19 13:46:58.0 -0500
> ***
> *** 337,342 
> --- 337,344 
>   && (state->misc_flags & SMTP_MISC_FLAG_IN_STARTTLS) == 0) {
>   /* XXX Mix-up of per-session and per-request flags. */
>   state->misc_flags |= SMTP_MISC_FLAG_IN_STARTTLS;
> + smtp_stream_setup(state->session->stream, var_smtp_helo_tmout,
> +   var_smtp_rec_deadline);
>   tls_helo_status = smtp_start_tls(state);
>   state->misc_flags &= ~SMTP_MISC_FLAG_IN_STARTTLS;
>   return (tls_helo_status);
> 

Hello Wietse,

that fixes the error...

Andreas

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

[A. Schulze]

Am 19.02.19 um 14:28 schrieb A. Schulze:
> 
> A. Schulze:
> 
>> Viktor Dukhovni:
>>
>>> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
>>> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
> 
> there is an other side effect:
> 
> I configured
> smtpd_tls_cert_file = /etc/ssl/${myhostname}/cert+intermediate.pem
> smtpd_tls_key_file = /etc/ssl/${myhostname}/key.pem
> smtp_tls_cert_file = /etc/ssl/${myhostname}/cert+intermediate.pem
> smtp_tls_key_file = /etc/ssl/${myhostname}/key.pem
> 
> now, on my lab maschine, a little bit complicated via
>     sender_dependent_relayhost_maps
>     @example.org [mail.example.org]:465
> 
> and to enforce the (local required) smtp_wrapper_mode
>     sender_dependent_default_transport_maps
>     @example.org submissions:
> 
> "submissions" is defined in master.cf:
>     submissions    unix  - - y - - smtp
>  -o smtp_tls_security_level=encrypt
>  -o smtp_tls_wrappermode=yes
>  -o syslog_name=postfix/${service_name}
> 
> now, "sendmail -f sen...@example.org -bc recipi...@example.org" throw this 
> error:
> 
> Feb 19 14:24:09 spider postfix/pickup[3865]: 443hK512TRzMvsx7: uid=1000 
> from=
> Feb 19 14:24:09 spider postfix/cleanup[3869]: 443hK512TRzMvsx7: 
> message-id=<443hK512TRzMvsx7@$myhostname>
> Feb 19 14:24:09 spider postfix/qmgr[3866]: 443hK512TRzMvsx7: 
> from=, size=302, nrcpt=1 (queue active)
> Feb 19 14:24:09 spider postfix/tlsproxy[3873]: CONNECT to [192.0.2.25]:465
> Feb 19 14:24:09 spider postfix/submissions/smtp[3895]: panic: 
> VSTREAM_CTL_SWAP_FD can't swap descriptors between single-buffered and 
> double-buffered streams
> Feb 19 14:24:09 spider postfix/tlsproxy[3873]: Trusted TLS connection 
> established to mail.example.org[192.0.2.25]:465: TLSv1.3 with cipher 
> TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) 
> server-signature RSA-PSS (4096 bits) server-digest SHA256
> Feb 19 14:24:10 spider postfix/qmgr[3866]: warning: private/submissions 
> socket: malformed response
> Feb 19 14:24:10 spider postfix/qmgr[3866]: warning: transport submissions 
> failure -- see a previous warning/fatal/panic logfile record for the problem 
> description
> Feb 19 14:24:10 spider postfix/master[2282]: warning: process 
> /usr/lib/postfix/smtp pid 3895 killed by signal 6
> Feb 19 14:24:10 spider postfix/master[2282]: warning: /usr/lib/postfix/smtp: 
> bad command startup -- throttling
> Feb 19 14:24:10 spider postfix/tlsproxy[3873]: DISCONNECT [192.0.2.25]:465
> Feb 19 14:24:10 spider postfix/error[3875]: 443hK512TRzMvsx7: 
> to=, relay=none, delay=1, delays=0.02/1/0/0.01, 
> dsn=4.3.0, status=undeliverable (unknown mail transport error)
> ( last line isn't the surprise ... )
> 
> I guess it's related to my previous posting.
> 
> Andreas
> 

but this error stay even with Viktor's patch applied.
smtpd_tls_cert_file + smtpd_tls_key_file need to be set, 
smtp_tls_cert_file+smtp_tls_key_file don't matter.


Andreas

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

[A. Schulze]

Am 19.02.19 um 15:37 schrieb Viktor Dukhovni:
>> On Feb 19, 2019, at 7:35 AM, A. Schulze  wrote:
>>
>> Feb 19 13:25:53 spider postfix/master[2282]: warning: process 
>> /usr/lib/postfix/tlsproxy pid 996 killed by signal 11
>> Feb 19 13:25:53 spider postfix/master[2282]: warning: 
>> /usr/lib/postfix/tlsproxy: bad command startup -- throttling
>> Feb 19 13:26:53 spider postfix/tlsproxy[1021]: warning: No server certs 
>> available. TLS can't be enabled
>> Feb 19 13:26:53 spider postfix/master[2282]: warning: process 
>> /usr/lib/postfix/tlsproxy pid 1021 killed by signal 11
>> Feb 19 13:26:53 spider postfix/master[2282]: warning: 
>> /usr/lib/postfix/tlsproxy: bad command startup -- throttling
>> Feb 19 13:27:53 spider postfix/tlsproxy[1046]: warning: No server certs 
>> available. TLS can't be enabled
>> Feb 19 13:27:53 spider postfix/master[2282]: warning: process 
>> /usr/lib/postfix/tlsproxy pid 1046 killed by signal 11
>> Feb 19 13:27:53 spider postfix/master[2282]: warning: 
>> /usr/lib/postfix/tlsproxy: bad command startup -- throttling
>> Feb 19 13:28:53 spider postfix/tlsproxy[1061]: warning: No server certs 
>> available. TLS can't be enabled
>> Feb 19 13:28:53 spider postfix/master[2282]: warning: process 
>> /usr/lib/postfix/tlsproxy pid 1061 killed by signal 11
>> Feb 19 13:28:53 spider postfix/master[2282]: warning: 
>> /usr/lib/postfix/tlsproxy: bad command startup -- throttling
>>
>> The discussion between Wietse and Viktor addresses exactly that point.
>> I only want to show/agree, Viktors Patch isn't ready to release.
> 
> Is that *with* my patch applied?  For me, applying the patch
> made the segfaults in a certificateless proxy configuration
> go away.  I see the same segfaults with 3.4.0-RC2 unpatched,
> but not with the patch...

indeed, my fault / I falsely assumed the autoupdater did it's job.
The tlsproxy start without noise in certificateless configuration.

Sorry for not checking that earlier.

Andreas

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

[A. Schulze]

A. Schulze:


Viktor Dukhovni:


diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c


there is an other side effect:

I configured
smtpd_tls_cert_file = /etc/ssl/${myhostname}/cert+intermediate.pem
smtpd_tls_key_file = /etc/ssl/${myhostname}/key.pem
smtp_tls_cert_file = /etc/ssl/${myhostname}/cert+intermediate.pem
smtp_tls_key_file = /etc/ssl/${myhostname}/key.pem

now, on my lab maschine, a little bit complicated via
sender_dependent_relayhost_maps
@example.org [mail.example.org]:465

and to enforce the (local required) smtp_wrapper_mode
sender_dependent_default_transport_maps
@example.org submissions:

"submissions" is defined in master.cf:
submissionsunix  - - y - - smtp
 -o smtp_tls_security_level=encrypt
 -o smtp_tls_wrappermode=yes
 -o syslog_name=postfix/${service_name}

now, "sendmail -f sen...@example.org -bc recipi...@example.org" throw  
this error:


Feb 19 14:24:09 spider postfix/pickup[3865]: 443hK512TRzMvsx7:  
uid=1000 from=
Feb 19 14:24:09 spider postfix/cleanup[3869]: 443hK512TRzMvsx7:  
message-id=<443hK512TRzMvsx7@$myhostname>
Feb 19 14:24:09 spider postfix/qmgr[3866]: 443hK512TRzMvsx7:  
from=, size=302, nrcpt=1 (queue active)

Feb 19 14:24:09 spider postfix/tlsproxy[3873]: CONNECT to [192.0.2.25]:465
Feb 19 14:24:09 spider postfix/submissions/smtp[3895]: panic:  
VSTREAM_CTL_SWAP_FD can't swap descriptors between single-buffered and  
double-buffered streams
Feb 19 14:24:09 spider postfix/tlsproxy[3873]: Trusted TLS connection  
established to mail.example.org[192.0.2.25]:465: TLSv1.3 with cipher  
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384)  
server-signature RSA-PSS (4096 bits) server-digest SHA256
Feb 19 14:24:10 spider postfix/qmgr[3866]: warning:  
private/submissions socket: malformed response
Feb 19 14:24:10 spider postfix/qmgr[3866]: warning: transport  
submissions failure -- see a previous warning/fatal/panic logfile  
record for the problem description
Feb 19 14:24:10 spider postfix/master[2282]: warning: process  
/usr/lib/postfix/smtp pid 3895 killed by signal 6
Feb 19 14:24:10 spider postfix/master[2282]: warning:  
/usr/lib/postfix/smtp: bad command startup -- throttling

Feb 19 14:24:10 spider postfix/tlsproxy[3873]: DISCONNECT [192.0.2.25]:465
Feb 19 14:24:10 spider postfix/error[3875]: 443hK512TRzMvsx7:  
to=, relay=none, delay=1, delays=0.02/1/0/0.01,  
dsn=4.3.0, status=undeliverable (unknown mail transport error)

( last line isn't the surprise ... )

I guess it's related to my previous posting.

Andreas

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

[A. Schulze]

Viktor Dukhovni:


diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c




Another issue remains, in that tlsproxy(8) wants
unconditional server-side support before it is willing to be a
client proxy, and therefore also wants server certificates.


that 'wants server certificates' becomes reality on on of my lab systems :-)

$ tail /var/log/messages
Feb 19 13:25:53 spider kernel: [93723.068442] tlsproxy[996]: segfault  
at 0 ip 55c62130f9b7 sp 7ffc3e867f80 error 4 in  
tlsproxy[55c6212c4000+6a000]
Feb 19 13:26:53 spider kernel: [93783.109960] tlsproxy[1021]: segfault  
at 0 ip 5581336789b7 sp 7fffbc8b67d0 error 4 in  
tlsproxy[55813362d000+6a000]
Feb 19 13:27:53 spider kernel: [93843.173476] tlsproxy[1046]: segfault  
at 0 ip 5606426ba9b7 sp 7ffe5cd674a0 error 4 in  
tlsproxy[56064266f000+6a000]
Feb 19 13:28:53 spider kernel: [93903.201985] tlsproxy[1061]: segfault  
at 0 ip 556dff47c9b7 sp 7ffceb0de480 error 4 in  
tlsproxy[556dff431000+6a000]


$ tail /var/log/mail
Feb 19 13:25:53 spider postfix/master[2282]: warning: process  
/usr/lib/postfix/tlsproxy pid 996 killed by signal 11
Feb 19 13:25:53 spider postfix/master[2282]: warning:  
/usr/lib/postfix/tlsproxy: bad command startup -- throttling
Feb 19 13:26:53 spider postfix/tlsproxy[1021]: warning: No server  
certs available. TLS can't be enabled
Feb 19 13:26:53 spider postfix/master[2282]: warning: process  
/usr/lib/postfix/tlsproxy pid 1021 killed by signal 11
Feb 19 13:26:53 spider postfix/master[2282]: warning:  
/usr/lib/postfix/tlsproxy: bad command startup -- throttling
Feb 19 13:27:53 spider postfix/tlsproxy[1046]: warning: No server  
certs available. TLS can't be enabled
Feb 19 13:27:53 spider postfix/master[2282]: warning: process  
/usr/lib/postfix/tlsproxy pid 1046 killed by signal 11
Feb 19 13:27:53 spider postfix/master[2282]: warning:  
/usr/lib/postfix/tlsproxy: bad command startup -- throttling
Feb 19 13:28:53 spider postfix/tlsproxy[1061]: warning: No server  
certs available. TLS can't be enabled
Feb 19 13:28:53 spider postfix/master[2282]: warning: process  
/usr/lib/postfix/tlsproxy pid 1061 killed by signal 11
Feb 19 13:28:53 spider postfix/master[2282]: warning:  
/usr/lib/postfix/tlsproxy: bad command startup -- throttling


The discussion between Wietse and Viktor addresses exactly that point.
I only want to show/agree, Viktors Patch isn't ready to release.

Andreas

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

[A. Schulze]

Am 18.02.19 um 12:04 schrieb Viktor Dukhovni:

> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c

Hello Viktor,

I confirm these modifications fix the delivery failure.

... $ sendmail -f sen...@example.org -bv recipi...@gervers.com

Feb 18 19:09:26 mail postfix/tlsproxy[10971]: CONNECT to [5.9.100.168]:25
Feb 18 19:09:26 mail postfix/tlsproxy[10971]: Verified TLS connection 
established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 18 19:09:26 mail postfix/smtp[10969]: Verified TLS connection established 
to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 18 19:09:26 mail postfix/tlsproxy[10971]: DISCONNECT [5.9.100.168]:25
Feb 18 19:09:29 mail postfix/smtp[10969]: 443Bhj6rYCzyC: 
to=, relay=sys1.mmini.de[5.9.100.168]:25, delay=4, 
delays=0.1/0.04/0.47/3.4, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
Feb 18 19:09:29 mail postfix/cleanup[10975]: 443Bhn6tnBzyS: 
message-id=<443bhn6tnb...@mail.example.org>
Feb 18 19:09:30 mail postfix/bounce[10972]: 443Bhj6rYCzyC: sender delivery 
status notification: 443Bhn6tnBzyS
...


> These address missing DANE and TLS library initialization in the
> TLS proxy.  Another issue remains, in that tlsproxy(8) wants
> unconditional server-side support before it is willing to be a
> client proxy, and therefore also wants server certificates.

that's limitation I currently could tolerate :-)

Thanks!
Andreas

Re: DANE issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 22:40 schrieb Wietse Venema:
> A. Schulze:
>> https://andreasschulze.de/tmp/reuse_on.txt
>> https://andreasschulze.de/tmp/reuse_off.txt
> 
> These deliver to different server IP addresses, therefore the 
> results may differ.

the destination MX has IPv4 and IPv6 working. Depends on what postfix selected 
first.

Andreas

Re: DANE issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 21:24 schrieb Viktor Dukhovni:

Hello Viktor,

> If you performed a "reload" to get that to take effect, that would
> also have flushed the TLS session cache.  And perhaps disabling
> connection re-use is a distraction.  It may well have been sufficient
> to just "postfix reload".
no, also "postfix stop; postfix start; postfix flush" (it's a low volume system 
with only this message in the deferred queue) did not deliver the message.
but "smtp_tls_connection_reuse = no" did.

> This is more interesting.  What OpenSSL version is your Postfix
> linked with? 
a self-compiled openssl-1.1.1a (using a shlib_variant like you show me some 
years ago)

> Please post the outputs of "postconf -nf" and "postconf -Mf", and
> information about the OpenSSL version, checking "ldd" to make sure
> you're reporting the version of the correct library.
https://andreasschulze.de/tmp/postconf_nf.txt
https://andreasschulze.de/tmp/postconf_Mf.txt

https://andreasschulze.de/tmp/ldd_smtp.txt

> If you re-enable use of the proxy, does the problem come back?
yes

> You don't need to send messages that reach the recipient.  You can
> send "delivery probes" via:
> 
> sendmail -f your-address -bv recipient-address
> 
> These drop the connection after "RCPT TO", without delivering a message.
ok, so I start silent testing ...

https://andreasschulze.de/tmp/reuse_on.txt
https://andreasschulze.de/tmp/reuse_off.txt

> We might temporarily need to raise the TLS loglevel to 2 in the
> proxy just before sending a delivery probe.  It should then be
> possible to see more of the TLS handshake details.
tests above run with "smtp_tls_loglevel = 2"

>>> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
>> smtp/unix/chroot = y
>> tlsproxy/unix/chroot = y
> 
> You should make sure your DNS is correctly configured in the chroot
> jail.  Are any of the upstream resolvers perhaps not configured to
> do DNSSEC?
only one DNS resolver (@::1) is also configured inside the chroot jail.

Andreas

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 18:23 schrieb Wietse Venema:
> Conclusion: Postfix works as expected?

hard to say...

delivery deferred if smtp_tls_connection_reuse = yes
delivery works if smtp_tls_connection_reuse = no

http://www.postfix.org/TLS_README.html#client_tls_reuse say "As of Postfix 3.4, 
TLS connection reuse is disabled by default."
As usual, you select good defaults :-)

I'll make some further test next week and report my findings...

Andreas

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 16:10 schrieb Wietse Venema:

> How do those 'other' connections differ from what is shown above?
I don't see differences. This tlsproxy process handled a connection to gmail, 
outlook.com and some other destinations. All unverified because I did not 
configure the matching root certificates.
Interesting: it also handled later an other connection to an other destination 
that *could* be verified using DANE (verified connection established to ...)
 
> What I see is an SMTP client deferring delivery with a NEW TLS
> connection. That is different from your earlier report about a
> REUSED connection.
> 
> Can you confirm that the SMTP client will not deliver to this
> destination with NEW and REUSED tlsproxy connections?
cannot check that without bothering the receiver with annoying test messages.
Will ask for permission...

> The error message suggests a problem in the certificate trust chain,
> like an unknown root certificate.

that's the point I started with subject "DANE issue..."
The destination don't need any certificate chains. The destination can be 
validated using DANE.

> What is the output from:
> 
> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
smtp/unix/chroot = y
tlsproxy/unix/chroot = y

Andreas

Re: PATCH: non-Postfix processes in init mode

[A. Schulze]

Am 17.02.19 um 16:01 schrieb Tamás Gérczei:
> Anyway I'm invoking postfix-script in order to start master:

I wonder why you don't use "postfix start-fg" available since postfix-3.3.1
(http://www.postfix.org/announcements/postfix-3.3.1.html)

Andreas

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 15:24 schrieb Wietse Venema:
> A. Schulze:
>> Hello,
>>
>> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
>> Now I notice delivery problems to "gervers.com". DANE setup looks OK. 
>> https://dane.sys4.de/smtp/gervers.com
>>
>> "posttls-finger gervers.com" also show
>> posttls-finger: Verified TLS connection established to 
>> sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>>
>> But a message to the domain is not delivered. Instead I found this logged by 
>> tlsproxy:
>>
>> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: 
>> re-using session with untrusted certificate, look for details earlier in the 
>> log
>> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection 
>> established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
>> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>>
>> But I did not found anything special "earlier in the log" ...
> 
> Surely the SMTP client logged SOMETHING?
> 
> Surely the tlsproxy daemon logged SOMETHING when it created the TLS 
> connection?

Hello Wietse,

thanks for asking :-) Yes, of corse, there are other loglines...
Here are the all message and connection related entries (I found):

Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: 
client=localhost[127.0.0.1]
Feb 17 10:27:54 mail postfix/cleanup[9442]: 442M9Q3L8Kzkn: message-id=<>
Feb 17 10:27:54 mail opendkim[19651]: 442M9Q3L8Kzkn: DKIM-Signature field added
Feb 17 10:27:54 mail postfix/qmgr[29788]: 442M9Q3L8Kzkn: from=<...>, size=1802, 
nrcpt=1 (queue active)
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification failed 
for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: Untrusted TLS connection 
established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:55 mail postfix/smtp[9452]: Untrusted TLS connection established 
to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:55 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: Server certificate not 
trusted
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: DISCONNECT [5.9.100.168]:25
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CONNECT to 
[2a01:4f8:162:32ac::2]:25
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CA certificate verification failed 
for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: Untrusted TLS connection 
established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:56 mail postfix/smtp[9452]: Untrusted TLS connection established 
to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:56 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: to=<***@gervers.com>, 
relay=sys1.mmini.de[2a01:4f8:162:32ac::2]:25, delay=1.6, 
delays=0.11/0.02/1.5/0, dsn=4.7.5, status=deferred (Server certificate not 
trusted)
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: DISCONNECT 
[2a01:4f8:162:32ac::2]:25

the same tlsproxy process handled 5 other connections before this one. All 
logged as 'Untrusted TLS connection established to'

Andreas

Re: DELIVERY issue with postfix 3.4.0-RC2

[A. Schulze]

Am 17.02.19 um 14:41 schrieb A. Schulze:
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"

corrected the subject, as DANE is not necessary related here.

DANE issue with postfix 3.4.0-RC2

[A. Schulze]

Hello,

I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
Now I notice delivery problems to "gervers.com". DANE setup looks OK. 
https://dane.sys4.de/smtp/gervers.com

"posttls-finger gervers.com" also show
posttls-finger: Verified TLS connection established to 
sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

But a message to the domain is not delivered. Instead I found this logged by 
tlsproxy:

Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: 
re-using session with untrusted certificate, look for details earlier in the log
Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection 
established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

But I did not found anything special "earlier in the log" ...

Message was delivered immediately as I disabled smtp_tls_connection_reuse:
Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established 
to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

I could provide further information off-list.

Andreas

Re: smtp_fallback_relay TLS with authentication - possible?

[A. Schulze]

Viktor Dukhovni:



So yes, you can't have wrapper mode for just the fallback relay.



Hello,

I had a similar problem some time ago and also found what you sumarize now.

I'm still using 587+STARTTLS but that "break" our `more general rule`  
to prefer implicit TLS over STARTTLS


So, at least I would now announce that it would be nice to have  
something like this:


master.cf
  smtp  unix  -   -   n   -   -   smtp
-o smtp_fallback_relay=[relayhost.example]:465
# not yet existing option :-)
-o smtp_fallback_relay_wrappermode=on

Andreas

Re: Regenerating DHparams

[A. Schulze]

Viktor Dukhovni:


It is easy to set up a cron job that runs every 30 days,


Hello,

that's the first time I personally note a specific time windows.
Thanks for sharing your position.

I also regenerate dhparameter on monthly base,
not every month but approximately every half year...

  if [ "$( hexdump -n 1 -e '/2 "%u"' /dev/urandom )" -gt 42 ]; then
echo 'skip dh generation this month'
  else
... new dh parameter
  fi

Andreas

postfix & TLS1.3 problems

[A. Schulze]

Hello,

today I noticed a significant amount of TLS failures in my postfix log.

Oct 11 17:43:35 mta postfix/smtpd[23847]: SSL_accept error from  
client.example[192.0.2.25]:34152: -1


I traced some sessions and found the problematic client is announcing  
the special cipher "TLS_FALLBACK_SCSV"
in a TLSv1.2 ClientHello message. Now, as my server support TLSv1.3,  
my SSL library (openssl-1.1.1) assume a downgrade attack an close the  
connection with an SSL error message "inappropriate fallback"


The core issue is a client with a nonconforming TLS implementation.

To circumvent the problem I tried to disable TLS1.3 on my server by setting
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1.3

But that does not help.
The Client still fail an deliver the message by falling back to plain text :-/

The only option to force encrypted traffic again would be a library  
downgrade on my side.

Any other suggestions?

Andreas

Re: smtp_tls_policy_maps on a per tls user basis

[A. Schulze]

Stefan Bauer:


Am Sonntag, 9. September 2018 schrieb Wietse Venema :

Instead, you can use transport_maps to choose between different
Postfix SMTP clients (with different configurations) based on the
recipient address or domain.

You can use the access map or header/body_checks FILTER action
("FILTER name-of-transport:", without a domain after the ":") to
choose delivery methods based on other message properties, with
some loss of elegance.


I see no way to combine both. I want to enforce tls for sender1 to
google.com but not for sender2 to google.com.



you may route messages from sender1 to a second postfix instance
and configure that instance to enforce tls to $destination for _any_ sender

Andreas

Re: New to Postfix. 3 questions about security functions.

[A. Schulze]

Viktor Dukhovni:

Therefore, if a system is upgraded to OpenSSL 1.1.1, Postfix will  
use 1.1.1 without a rebuild.


but the mail log get flooded with ugly warnings:
https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L971

I do run postfix-3.3.1 + openssl-1.1.1-pre* since some months without  
any negative impact.

But that's only a low volume, non-imortant infrastructure (my MX)...


Andreas

Re: TLS1.3 only

[A. Schulze]

Am 13.07.2018 um 02:43 schrieb Viktor Dukhovni:
> That is, you'd need to use "smtpd_tls_mandatory_protocols", assuming
> that for the subission service you also have:
> 
>   -o smtpd_tls_security_level=encrypt


Hello,

like assumed it was my mistake.

yes, on the submission port I do have "-o smtpd_tls_security_level=encrypt"
and if I set "-o 
smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1,!TLSv1.2"
I really could connect *only* using TLS1.3.

-> everything works like documented :-)

Thanks Viktor!
Andreas

Re: TLS1.3 only

[A. Schulze]

Am 12.07.2018 um 22:39 schrieb Wietse Venema:
> A. Schulze:
>> Hello,
>>
>> postfix-3.3.1 + openssl-1.1.1pre8
>>
>> For fun I tried to disable all TLS protocol versions other then TLS1.3
>>
>> master.cf:
>>   submission.local inet n - - - - smtpd
>>-o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1,!TLSv1.2
> 
> That setting is ONLY in effect with 'smtpd_tls_security_level = may'.
> 
>> but I'm still able to connect using TLS1.2
> 
> Insufficient information.
> 
>   Wietse
> 

ok, will simply my setup to provide more settings ( maybe it's also my fault, 
we'll see )
but not today, it's late here ...

Andreas

TLS1.3 only

[A. Schulze]

Hello,

postfix-3.3.1 + openssl-1.1.1pre8

For fun I tried to disable all TLS protocol versions other then TLS1.3

master.cf:
  submission.local inet n - - - - smtpd
   -o smtpd_tls_protocols=!SSLv2,!SSLv3,!TLSv1,!TLSv1.1,!TLSv1.2

but I'm still able to connect using TLS1.2

$ openssl version
OpenSSL 1.1.1-pre8 (beta) 20 Jun 2018

$ openssl s_client -connect submission.local:587 -starttls smtp -tls1_2
...
Start Time: 1531425453
Timeout   : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
250 SMTPUTF8

Shouldn't that fail like this one?

$ openssl11 s_client -connect submission.example:587 -starttls smtp 
-tls1_1
CONNECTED(0003)
140205388985856:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert 
protocol version:ssl/record/rec_layer_s3.c:1557:SSL alert number 70
...

Andreas

Re: openDKIM and postfix

[A. Schulze]

On May 20, 2018, at 7:24 PM, John Levine  wrote:
>
>  Has anyone actually seen it happen in the
> wild in the past decade?

yes, web.de, gmx.net and other domains operated by 1&1 for example.
or freemail.de or all the domains hosted by Eleven (today Cyren)

For that it /is/ a huge problem in Germany...
John, you may know me, I asked them many times but that changed nothing :-/

Andreas

Re: Question regarding OpenDKIM milter with Postfix 3.1.0

[A. Schulze]

Am 15.05.2018 um 02:40 schrieb J Doe:
> I apologize for asking a question that is only tangentially related to 
> Postfix, however the OpenDKIM mailing lists do not appear to be accessible.


yes, the OpenDKIM lists are unfortunately broken since a long time. I hope I 
could push the list admin to fix that.


> I am using Postfix 3.1.0 and OpenDKIM 2.10.3.  Upon reboot of my server, I 
> noticed “normal” stats regarding caching (which I have enabled in 
> opendkim.conf), in OpenDKIM:
> 
> May 14 20:10:45 server opendkim[1950]: cache: 0 queries, 0 hits (0%), 16 
> expired, 0 keys
> 
> ..however, after a connection, I receive the following:
> 
> May 14 20:16:35 server opendkim[1950]: cache: 32563 queries, 1104666192 
> hits (94967%), 16 expired, 0 keys
> 
> I stopped and restarted OpenDKIM via systemd as I assume that would empty the 
> in memory cache and any possible corruption, but a spurious number returns.
I never used caching in OpenDKIM and disable it where ever possible. I prefer a 
local DNS resolver and a fast/local database (for signing).

Andreas

Re: Question about list.dnswl.org

[A. Schulze]

Am 15.04.2018 um 00:22 schrieb Christos Chatzaras:
> I create a new account at www.dnswl.org  and add my 
> primary domain in their portal.
> 
> I also request them to add my outgoing SMTP IPs (I think they manually check 
> it before add).
> 
> To query their database, do I have to ask them to add my resolver's IPs too?
> 
> It looks like they allow access from "unknown" IPs (test it with nslookup), 
> but I want to make sure that registering resolver's IPs is not needed to 
> avoid them block the requests made by my resolvers in the future.

try to use the dnswl.org Mailing list: https://www.dnswl.org/?page_id=13

Andreas

Re: Keep Postfix running in the foreground

[A. Schulze]

Eray Aslan:


On Wed, Apr 04, 2018 at 07:19:56PM -0400, Wietse Venema wrote:

I also need you guys to verify that with the Postfix master running
as PID=1, "docker stop" will no longer leave the master daemon
running until Docker times out and forcibly terminates everything.

By default, "docker stop" should send signal SIGTERM (signal 15) which
is what Postfix expects, but it is good to verify.


Looks good.  Thank you.

$ docker run -d -v /dev/log:/dev/log eraya/postfix:3.4_pre20180404-r1
9cb6c36eb8f2e03785389521a601a54be49c817522a35f8464ae7b71a8e51fe6
$ docker ps
CONTAINER IDIMAGE  COMMAND
   CREATED STATUS  PORTS  
  NAMES
9cb6c36eb8f2eraya/postfix:3.4_pre20180404-r1
"/usr/sbin/postfix s…"   5 seconds ago   Up 4 seconds 
25/tcp  laughing_chebyshev

$ docker exec 9cb6c36eb8f2 ps aux
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root 1  0.0  0.1  71540  2880 ?Ss   06:42   0:00  
/usr/libexec/postfix/master -i
postfix 76  0.0  0.1  71524  2840 ?S06:42   0:00  
pickup -l -t unix -u
postfix 77  0.0  0.1  71572  2864 ?S06:42   0:00  
qmgr -l -t unix -u

root78  0.0  0.0  17556  1188 ?Rs   06:42   0:00 ps aux
$ docker exec 9cb6c36eb8f2 postconf mail_version
mail_version = 3.4-20180404
$ time docker exec 9cb6c36eb8f2 postfix stop

real0m0.172s
user0m0.067s
sys 0m0.008s
$ docker ps
CONTAINER IDIMAGE   COMMAND CREATED   
   STATUS  PORTS   NAMES

$ docker run -d -v /dev/log:/dev/log eraya/postfix:3.4_pre20180404-r1
d9a7e481bfec046b5cdd859b61a8dacb3958cf7ce32af9e22bfca0a9e88504d0
$ docker ps
CONTAINER IDIMAGE  COMMAND
   CREATED STATUS  PORTS  
  NAMES
d9a7e481bfeceraya/postfix:3.4_pre20180404-r1
"/usr/sbin/postfix s…"   4 seconds ago   Up 3 seconds 
25/tcp  ecstatic_mccarthy

$ time docker stop d9a7e481bfec
d9a7e481bfec

real0m0.210s
user0m0.068s
sys 0m0.007s
$ docker ps
CONTAINER IDIMAGE   COMMAND CREATED   
   STATUS  PORTS   NAMES


--
Eray


Hello,

I like to confirm that explicit. That's what I mean with "it does in  
any way" yesterday...


Andreas

Re: Keep Postfix running in the foreground

[A. Schulze]

Am 04.04.2018 um 19:08 schrieb Wietse Venema:
> Eray Aslan:
>> On Tue, Apr 03, 2018 at 07:46:42PM -0400, Wietse Venema wrote:
>>> I updated both the postfix-script file and the master daemon.
>>>
>>> I'd appreciate it if someone could verify that this will run the
>>> master daemon with PID 1, and that 'postfix stop' in the container
>>> will stop the master daemon. If it doesn't, then Linux does weird
>>> stuff with PID 1 processes.

I found the same...

> Just for the heck of it, can you replace in src/master/master_sig.c
> this code:
> 
> if (kill(pid, SIGKILL) < 0)
> msg_fatal("%s: kill myself: %m", myname);
> 
> With this code:
> 
> exit(0);
> 
> And see if that fixes the PID=1 behavior?

it does in any way. Thanks, Wietse!

I tried both, exit(0) and _exit(0) :-)

Andreas

Re: Keep Postfix running in the foreground

[A. Schulze]

Wietse Venema:


I'd appreciate it if someone could verify that this will run the
master daemon with PID 1, and that 'postfix stop' in the container
will stop the master daemon.


I'll verify that in the next days ...

Andreas

Re: Keep Postfix running in the foreground

[A. Schulze]

Am 02.04.2018 um 19:30 schrieb Wietse Venema:
> -   "") exec $daemon_directory/master
> +   "") exec $daemon_directory/master -d
> +   $FATAL "could not start-fg $daemon_directory/master"

version 3.3.0 don't contain the "exec $daemon_directory/master" but only 
"$daemon_directory/master"
anyway, the patched version run master as PID 1. fine!

root@postfix:/# ps afx
  PID TTY  STAT   TIME COMMAND
  336 pts/0Ss 0:00 /bin/bash
  342 pts/0R+ 0:00  \_ ps afx
1 ?Ss 0:00 /usr/lib/postfix/master -d
  334 ?S  0:00 pickup -l -t unix -d -u
  335 ?S  0:00 qmgr -l -t unix -d -u

or from outside/docker host:
23584 ?Ssl0:00  \_ docker-containerd --config /var/run/docker/contai
23794 ?Sl 0:00  \_ docker-containerd-shim -namespace moby -workd
23811 ?Ss 0:00  \_ /usr/lib/postfix/master -d
24193 ?S  0:00  \_ pickup -l -t unix -d -u
24194 ?S  0:00  \_ qmgr -l -t unix -d -u

But "docker stop $postfix_container" don't let exit master:
23584 ?Ssl0:00  \_ docker-containerd --config /var/run/docker/contai
23794 ?Sl 0:00  \_ docker-containerd-shim -namespace moby -workd
23811 ?Ss 0:00  \_ /usr/lib/postfix/master -d


I tried "postfix stop" inside the container. That also terminate all child 
processes but not the master itself.
So a container receiving "stop", still run with only master as PID 1
expected: master process exit and container terminate.

that's better then without the patch as postfix processes are shut down more 
properly...

> See what happens with 'postfix stop' and if it kills too much.
in a container it don't hurt: there is nothing other

Andreas

Re: Keep Postfix running in the foreground

[A. Schulze]

Am 02.04.2018 um 16:10 schrieb Michael Segel:
> Has anyone successfully implemented a Kubernetes / Docker container setup for 
> Postfix/Dovecot? 

it works in my lab environment.

$ docker-compuse up -d postfix
Creating dockerpostfix_postfix_1 ... done
$ docker-compose exec postfix /bin/bash
root@postfix:/# postconf mail_version
mail_version = 3.3.0
root@postfix:/# ps afx
  PID TTY  STAT   TIME COMMAND
  338 pts/0Ss 0:00 /bin/bash
  345 pts/0R+ 0:00  \_ ps afx
1 ?Ss 0:00 /bin/sh /usr/lib/postfix/postfix-script start-fg
  335 ?Ss 0:00 /usr/lib/postfix/master
  336 ?S  0:00  \_ pickup -l -t unix -u
  337 ?S  0:00  \_ qmgr -l -t unix -u

The container's entrypoint is a binary, but at run time PID 1 is /bin/sh.
That result in hard container shutdown: Docker send SIGTERM to a sh, not to 
usr/lib/postfix/master.
As the sh will not terminate "master", Docker will KILL the whole container 
later.
It would be better, if /usr/lib/postfix/master is PID 1.

To be complete: that's my docker-compose.yml:
services:
  postfix:
entrypoint: ["/usr/sbin/postfix", "start-fg"]
hostname: postfix
image: $(replace_with_your_postfix_image)
restart: unless-stopped
volumes:
- /dev/log:/dev/log
- ./config:/etc/postfix/config
- ./lib:/var/lib/postfix
- ./spool:/var/spool/postfix
version: '2.3'

and the Dockerfile:
FROM $(replace_with_your_debian_base)
RUN set -ex ; \
   apt-get -qq update \
&& apt-get -qq --no-install-recommends install 
$self_compiled_postfix_package \
&& apt-get -qq --purge autoremove \
&& apt-get -qq clean \
&& rm -rf /var/lib/apt/lists/*

Andreas

SMTP session caching

[A. Schulze]

Hello,

I like to ask about a documented limitation 
(http://www.postfix.org/CONNECTION_CACHE_README.html#limitations)

"For this reason, the Postfix smtp(8) client always closes the connection after 
completing an attempt to deliver mail over TLS."

I'm concerned becaus I see increasing traffic delivered via TLS.
It is true that now /every single message/ require TCP connect, TLS Handshake, 
message transmission and TCP close?
So SMTP Session caching don't happen anymore?

Given a sending server handle 3000 messages per hour to a specific destination 
that use DANE.
Virtually every 1-2 seconds the server open and close a connection. Why 
shouldn't it be possible
to recycle an established connection for multiple message?

I only like to /understand/ the above "this reason" ...

Andreas

Re: Berkeley DB and new install

[A. Schulze]

@lbutlr:

I know that the Berkeley DB still works in postfix if compiled with  
that option, but is it the best choice for a new install of postfix?

no

I have only a couple of tables that use it, but since I am moving  
entirely to a new machine and new compiles, I don't want to drag  
along an "old" format if I don't need to.



What other options are there for a virtual table in the form of

us...@localdomain.tld us...@fred.exampl.com

or the similar alias table

user:  otheruser

(alias is used entirely on my system to redirect mail to the root  
account from names like admin, daemon, etc)


I mean, I could move them all into my virtual_prce file relatively  
easily if that is best?


I'm not limited while using only lmdb, texthash, pcre, ldap or sql

Andreas

Re: smtpd_milters

[A. Schulze]

Am 30.12.2017 um 22:55 schrieb Michael Grimm:
> Hi
> 
> After reading http://www.postfix.org/MILTER_README.html there are some 
> questions unanswered to me.
also read the milter documentation part of the opensource sendmail for example 
at
https://sources.debian.org/data/main/s/sendmail/8.15.2-9/libmilter/docs/index.html

> Let's assume one does define:
> 
>   smtpd_milters = milter1, milter2, …, milterX
> 
> README:
>   "Milter applications are applied in the order as specified, and the 
> first Milter application that rejects a command will override the responses 
> from other Milter applications."
> 
> I do understand:
>   milter2 rejects the mail in question, and thus, overrides all responses 
> from milter1, …, milterX.
override is the wrong word. ,Say "milter1 did not reject" and milterX is not 
relevant anymore.
 
> What I do not understand:
>   Will all milters *after* milter2 become invoked although milter2 
> already did reject the mail in question?
> 
> In other words:
>   Is there a way to stop invoking milters after the first "reject"?
> 
> Sorry, but I do not understand that README well enough to answer that 
> questions by myself.

Milters callbacks are invoked for every smtp state. every milter may give one 
of seven answers.
https://sources.debian.org/data/main/s/sendmail/8.15.2-9/libmilter/docs/api.html#Miscellaneous

notice the concept of "connection-oriented" vs. "message- or 
recipient-oriented" callbacks.
https://sources.debian.org/data/main/s/sendmail/8.15.2-9/libmilter/docs/overview.html#ControlFlow

Andreas

Re: smtp-sink on ipv4 and ipv6?

[A. Schulze]

Am 05.11.2017 um 19:40 schrieb Wietse Venema:
> A. Schulze:
>> Hello,
>>
>> postfix usually listen on both protocols if main.cf contain "inet_protocols 
>> = all" and myhostname is setup properly.
>> May I expect that also for smtp-sink?
> 
> The manpage for these programs do not mention main.cf. They do
> however describe command-line options to select protocols.
> 
> smtp-sink listens on one port. To listen on both IPv4 and IPv6
> ports:
> 
> smtp-sink -4 ...
> smtp-sink -6 ...
> 
> This is a test program, so it does not get the same level of support
> as non-test code. If someonme feels strongly about this they can
> submit a manpage change, or they can send me code that duplicates
> parts from the master daemon's connection management (build an
> inet_addr_list; for each address in that list call inet_listen();
> wait for events on all sockets returned by inet_listen(). Maybe
> some of that can be encapsulated in library functions that can
> also be called by the master daemon).

Hello Wietse,

I'm aware smpt-sink/source are programs with limited level of support.
I was able to setup listener on IPv4 using -4 OR on IPv6 using -6. That works. 
But the manpage say

  Connections  can  be  accepted  on  IPv4  or  IPv6  endpoints,  or   on
  UNIX-domain  sockets.   IPv4 and IPv6 are the default.

And exactly that default is what I like but can't manage to setup.
Therefore my question...
If I re-read it as "inet is default, UNIX-domain sockets must be specified 
explicit"
it matched the current behavior :-)

Currently I'm fine with two separate instances.

Thanks!
Andreas

smtp-sink on ipv4 and ipv6?

[A. Schulze]

Hello,

postfix usually listen on both protocols if main.cf contain "inet_protocols = 
all" and myhostname is setup properly.
May I expect that also for smtp-sink?

$ host mail.example.com
mail.example.com has address 192.0.2.25
mail.example.com has IPv6 address 2001:db8::25

$ smtp-sink inet:mail.example.com:25 &

now I've only a listener on 2001:db8::25 but not on 192.0.2.25, but I would 
like smtp-sink listen on ipv4 AND ipv6.
is that possible?

Andreas

Re: sendmail cannot read CDB tables

[A. Schulze]

Am 23.10.2017 um 17:16 schrieb Ulrich Zehl:
> On Mon, Oct 23, 2017 at 01:37:19PM +, Scott Kitterman wrote:
>>
>> On October 23, 2017 9:15:17 AM EDT, Ulrich Zehl  
>> wrote:
>>> When I try to use a CDB table for authorized_submit_users with Postfix
>>> 3.1.6, the sendmail command exits with error "unsupported dictionary
>>> type: cdb".
>> [...]
>>
>> I believe taking Postfix out of the chroot that is the Debian default will 
>> likely
>> resolve it.  I think that is documented in README.Debian.
> 
> As far as I know, sendmail(1) is not a master(8) service, and thus not
> affected by the chroot settings in master.cf.
> 
> Nevertheless, I disabled chroot for all services in master.cf, restarted
> Postfix, and tried again. It did not change the result.

maybe an older or wrong sendmail binary...

I would check 
"ls -la /usr/bin/sendmail* /usr/sbin/sendmail* /usr/lib/sendmail* 
/etc/alternatives/sendmail*"
to find sendmail binaries.

My system (not using debian postfix) has only one at /usr/sbin/sendmail.

I expect "ldd /usr/sbin/sendmail" don't mention libcdb.
In contrast ldd /usr/sbin/postconf does.

"postconf -h mail_version" give your postfix version. As you said earlier, it 
should be "3.1.6"

This versionstring is present in every postfix binary. so check it:

# strings /usr/sbin/postconf | grep "$( postconf -h mail_version )"
3.1.6

$ strings /usr/sbin/sendmail | grep 3.1.6
# expected to be empty, aka not 3.1.6

Andreas

Re: is this the correct DKIM mailing list ?

[A. Schulze]

Am 19.10.2017 um 20:34 schrieb Fazzina, Angelo:
> http://mipassoc.org/mailman/listinfo/ietf-dkim
 
> I joined but after a few days nothing but crickets after my post to the list.
I cannot see your post to that list: http://mipassoc.org/pipermail/ietf-dkim/
You should check your subscription.

> Is there a different list you guys use to discuss DKIM ?
it depends on the DKIM implementation you use. The most popular Open-Source 
implementation is OpenDKIM.
Unfortunately this specific lists (via http://lists.opendkim.org) seem to be 
down currently :-/


Andreas

Re: bcc emails to two addresses

[A. Schulze]

A. Schulze:


(braindump, I'll post an update tomorrow if I'm wrong...)

pcrefile:
  /^(.+)\@(.+)$/ someuser+$1_at_$2@archive

transport_maps:
  archive   smtp_to_archive:

main.cf:
 recipient_bcc_maps = pcre:/path/to/pcrefile
 transport_maps = hash:/path/to/transport_maps
 smtp_to_archive_destination_recipient_limit = 1

master.cf
  smtp_to_archiveunix  - - - - - smtp
   -o syslog_name=postfix/to_archive



it's simpler.
you do not need a separate transport to enforce destination_recipient_limit=1

pcrefile:
  /(.+)@(.+)/ someuser+${1}_at_${2}@archive
  /(.*)/  someuser+${1}@archive

main.cf:
  recipient_bcc_maps = pcre:/path/to/pcrefile

Andreas

Re: bcc emails to two addresses

[A. Schulze]

Am 18.10.2017 um 14:54 schrieb Tavolodo Bela:
> Hello,
> 
> I have a mail server running postfix, and another server running an email 
> archive software
> which can talk smtp.
> 
> Postfix is configured to pass a copy of each emails to the archive, using
> always_bcc = someuser@archive
> 
> When an email is received it's copied to the archive properly, so far, so 
> good.
> 
> Now the problem: I have several customers and domains hosted on the mail 
> server.
> When customer1 sends an email to customer2, then the email appears only in 
> customer2's
> archive (it's a multitenant solution).
> 
> I've managed to narrow the issue, and it seems that the problem is that the 
> archive identifies the customer with the rcpt to: (=envelope) address, eg.
> 
> EHLO aaa.fu
> MAIL FROM: 
> RCPT TO: 
> ...
> 
> Thus the archive doesn't matches this email with customer1 as well.
> 
> So my question is that is it possible that when customer1 sends an email to 
> customer2
> then to send a bcc email to customer1@archive address, and another to 
> customer3@achive
> address?
> 
> Thank you,
> 
> Bela

try this
(braindump, I'll post an update tomorrow if I'm wrong...)

pcrefile:
  /^(.+)\@(.+)$/ someuser+$1_at_$2@archive

transport_maps:
  archive   smtp_to_archive:

main.cf:
 recipient_bcc_maps = pcre:/path/to/pcrefile
 transport_maps = hash:/path/to/transport_maps
 smtp_to_archive_destination_recipient_limit = 1

master.cf
  smtp_to_archiveunix  - - - - - smtp
   -o syslog_name=postfix/to_archive

with this setup message to multiple recipients are duplicated.

Andreas

Re: OpenDKIM SOCK path on Debian Jessie

[A. Schulze]

Am 16.10.2017 um 18:51 schrieb Davide Marchi:
> SOCKET="local:/var/spool/postfix/var/run/opendkim/opendkim.sock"
vs.
> smtpd_milters = unix:/var/run/opendkim/opendkim.sock
> non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock

postfix and sendmail/milter use different notation to describe the same socket 
location.

http://www.postfix.org/MILTER_README.html#smtp-only-milters
vs.
http://opendkim.org/opendkim.conf.5.html (search for "Socket" ...)

to me your setup looks fine...
Andreas

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[A. Schulze]

Am 15.10.2017 um 15:29 schrieb Jozef Matický:
> Hello Andreas,
> 
> Had some users complaining about mailboxes (and catch-alls) they created were 
> not accepting e-mails - Postfix, due to caching, was rejecting the e-mail as 
> if the mailbox wouldn't exist (apparently due to a fact someone was trying to 
> send an e-mail to that mailbox before it even existed - maybe spammer, maybe 
> a legit user).

That's a use case we where also faced years ago. We solved it by documentation. 
Also we "train" our users: whatever you configure, wait an hour!
(No matter if it' really required or not)

Then we consequently arrange our systems so every change is visible within one 
hour: address_verify_negative_refresh_time = 30m in this case.
Simple but understandable for our users

Andreas

Re: Strange issue with reject_unverified_recipient (LMTP/Dovecot)

[A. Schulze]

Am 14.10.2017 um 23:23 schrieb Jozef Matický:
> Hello,
> 
> I've been struggling with this for about a week now.
> In smtpd_recipient_restrictions I have reject_unverified_recipient.
> For recipient address verification I'm using Dovecot's LMTP.
> Everything is working as expected when address_verify_negative_cache = yes - 
> unknown recipients are rejected with 550 (NOQUEUE: reject), for known the 
> mail is delivered.
> 
> The problem I have is when I set address_verify_negative_cache = no.
> It goes like this:
> 
> - Sender connects to Postfix
> + Postfix is checking address with Dovecot
> + Dovecot responds (almost instantly) with 550 5.1.1 User doesn't exist; 
> status=undeliverable-but-not-cached
> - Above + points are repeated as many as address_verify_poll_count times (in 
> my case 5 times, with default it happened 3 times)
> - Postfix then replies to sender with 450 Recipient address rejected: 
> unverified address: Address verification in progress.
> - After a while sender is trying to deliver the same e-mail again and the 
> same thing is happening - it is deffered with 450
> - This goes on and on and on
> 
> It looks like when there is status=undeliverable-but-not-cached Postfix is 
> trying to verify the recipient address address_verify_poll_count times and 
> doesn't understand the Dovecot's 550 reply 
> (status=undeliverable-but-not-cached), after which it should reject sender 
> with 550 (NOQUEUE: reject).
> 
> Am I doing something wrong or is this some kind of a bug?
> The reason I'm trying to turn off negative cache is due to the catch-all.
> For example, user is trying to send an email to mailbox that doesn't exist. 
> The e-mail will be rejected with 550.
> Then user creates a catch-all for the domain and will send e-mail to the same 
> address.
> Due to the negative cache it again will be rejected with 550 despite the fact 
> there now is catch-all configured.
> 
> This is with Postfix 3.2.3 which I just upgraded from 3.1.6 (on which it was 
> exactly the same). I also have unverified_recipient_reject_code = 550 set.
> If something else is needed, like logs or postconf, please let me know.
> Don't want to spam mailing list if this is a problem between the chair and 
> the keyboard.

Josef,

Could you explain why you completely disable address_verify_negative_cache?
I personally would only shorten address_verify_negative_refresh_time if caching 
would be an issue.

Andreas
> 
> Thank you.

Re: address verification and tarpitting

[A. Schulze]

wietse:


A. Schulze:

Hello,

we're facing the following problem:
postfix is configured to verify recipient addresses. The backend  
servers are mostly Exchange in various versions.

Many of them use tarpitting. We guess that are default values.
The address probe sent by postfix receive a result after 5 seconds  
delay. reason: tarpitting.

Meanwhile postfix accept the message and we generate bounces later :-/


That's because you configured it to accept mail.

http://www.postfix.org/postconf.5.html#unverified_recipient_tempfail_action
http://www.postfix.org/postconf.5.html#unverified_sender_tempfail_action

Wietse


ok, thanks

I currently fail on reproducint the "error". Maybe because my server  
isn't under stress now.

May I force smtpd act with stress=1 for a specific smtp client?

@Viktor:
yes, you're right, our back-end servers shouldn't tarpitting our  
front-end servers.
but that's a long term goal and require reconfiguration on customers  
back-end servers...


Andreas

address verification and tarpitting

[A. Schulze]

Hello,

we're facing the following problem:
postfix is configured to verify recipient addresses. The backend servers are 
mostly Exchange in various versions.
Many of them use tarpitting. We guess that are default values.
The address probe sent by postfix receive a result after 5 seconds delay. 
reason: tarpitting.
Meanwhile postfix accept the message and we generate bounces later :-/
The next message to a - now known undeliverable - address is directly rejected 
by postfix. That's expected.

Does the parameter address_verify_poll_count and address_verify_poll_delay 
control these timings?
Looking at the defaults it matches perfect to the volume of affected messages 
here.

Am I right to interpret address_verify_poll_count=3 + 
address_verify_poll_delay=1 (under stress)
is to short for 5 seconds tarpitting? If so, what are the suggested changes?
I would try address_verify_poll_delay=2 first. 3x2 seconds = 6s > 5s tarpitting

Opinions?
Andreas

Re: postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[A. Schulze]

A. Schulze:


off-list...

ok not "off list", my fault :-)

Re: postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[A. Schulze]

wietse:


OK, now please (install and) use ltrace. This provides more details
what happens in postqueue itself (strace gives insight into system
calls, i.e.  the postqueue-kernel interface).


off-list...

I installed ltrace.
I modified pfqgrep: $mailq = "/usr/bin/ltrace /usr/sbin/postqueue -p |";

# pfqgrep -r '+123456789012' > /tmp/ltrace.txt 2>&1
available at https://postmaster.datev.de/tmp/ltrace.txt

There are two strings looking like a queueid in this trace:
3xhXFj2Wt7z4FL3* and 3xhXDS3PqBz4FK9*

that are two messages in the active queue just in the moment I run the  
command above.

postfix delivered both messages as usual...

Btw: as I said, I fixed the initial problem by calling "qshape -w 100"
Is 100 safe? Or even 1000?

I'm fine if you say "Oh ... Andreas run old perl ..." without further  
investigation.

Otherwise I'm willing to support you wherever possible :-)

Andreas

Re: postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[A. Schulze]

wietse:


A. Schulze:

postqueue: panic: vbuf_print: output for '%s' exceeds space 0




this is pfqgrep:

  $mailq = "/usr/sbin/postqueue -p |"; # added 'strace -f' here
  open(MAILQ, $mailq) or die;
  while () {
# read from STDIN
  }

execve("/usr/sbin/postqueue", ["/usr/sbin/postqueue", "-p"], [/* 52  
vars */]) = 0

...
chdir("/var/spool/postfix") = 0
rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTORER|SA_RESTART,  
0x7f4c8e917910}, {SIG_DFL, [], 0}, 8) = 0

getuid()= 0
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
fcntl(4, F_SETFL, O_RDWR)   = 0
connect(4, {sa_family=AF_FILE, path="public/showq"}, 110) = 0
poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
read(4, "queue_name\0active\0queue_id\0003xdsD"..., 4096) = 149
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(1, "Queue ID- --Size-- ---Ar"..., 218) = 218
poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
read(4, "queue_name\0active\0queue_id\0003xgg0"..., 4096) = 1453
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(1, "\n3xgg0L0F7Lz4FLj* 30013 Mon "..., 257) = 257
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 1234567890123/ at /usr/sbin/pfqgrep line 158,  chunk 1.

write(1, "\n3xgfY21WScz4FLZ* 32602 Mon "..., 241) = 241
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(1, "\n3xgWSk0qGbz4FKf* 42628 Mon "..., 257) = 257
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(1, "\n3xgh1z1cT1z4FLr* 76609 Mon "..., 184) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
read(4, "queue_name\0active\0queue_id\0003xgKR"..., 4096) = 4096
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
read(4, "3xdqXK4q4lz4FLK\0time\0001503639089\0"..., 4096) = 4096
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localt

postfix/postqueue[5742]: panic: vbuf_print: output for \%s\ exceeds space 0

[A. Schulze]

Hello,

I found the message in my logs. It turns they where triggered by a  
housekeeping script.


I did "qshape deferred" and used the first row (domainname) as  
argument to pfqgrep -r
For long domainnames qshape shorten the output and prefix the domain  
with a '+' character.

(described in man qshape, -w option)

Now my script called pfqgrep -r "+truncated-domain" which trigger the  
panic message sometimes


# pfqgrep -r '+12345678901'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 12345678901/ at /usr/sbin/pfqgrep line 158,  chunk 1.

# pfqgrep -r '+123456789012'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 123456789012/ at /usr/sbin/pfqgrep line 158,  chunk 1.

# pfqgrep -r '+1234567890123'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 1234567890123/ at /usr/sbin/pfqgrep line 158,  chunk 1.

postqueue: panic: vbuf_print: output for '%s' exceeds space 0
# pfqgrep -r '+12345678901234'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 12345678901234/ at /usr/sbin/pfqgrep line 158,  chunk 1.

# pfqgrep -r '+123456789012345'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 123456789012345/ at /usr/sbin/pfqgrep line 158,  chunk 1.

postqueue: panic: vbuf_print: output for '%s' exceeds space 0
# pfqgrep -r '+1234567890123456'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 1234567890123456/ at /usr/sbin/pfqgrep line 158,  chunk 1.

postqueue: panic: vbuf_print: output for '%s' exceeds space 0
# pfqgrep -r '+12345678901234567'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 12345678901234567/ at /usr/sbin/pfqgrep line 158,  chunk 1.

# pfqgrep -r '+123456789012345678'
Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
HERE 123456789012345678/ at /usr/sbin/pfqgrep line 158,  chunk 1.


I'm Unsure what's the really wrong part (beside input santisation in  
my script) but I guess, postqueue should not panic...


The messages went away after I changed my script to call "qshape -w  
100". This avoid domainname truncation for now.

Is there a safe way to avoid truncation completely?

postfix-3.2.0 is installed on the host.
pfqgrep is loaded from  
https://github.com/mikewaters/scripts/blob/master/mta/pfgrep.pl


Andreas

Re: NOTIFY=SUCCESS in Milter

[A. Schulze]

Am 03.08.2017 um 07:32 schrieb Tomas Macek:

> I'm trying to get to know, if there is a chance to see in Milter that the 
> "NOTIFY=xxx,yyy,zzz" was specified by a client at rcpt to command

Hello Tomas,

from the milter API Doku:

xxfi_envrcpt:
  ctx   Opaque context structure.
  argv  Null-terminated SMTP command arguments; argv[0] is guaranteed to be the 
recipient address. Later arguments are the ESMTP arguments. 

The "Later arguments are the ESMTP arguments" is your "hope" ...
but I never tested/used that.

Andreas

Re: verification levels and Milter (solved)

[A. Schulze]

Am 31.07.2017 um 20:43 schrieb A. Schulze:
> seeing cert_subject + cert_issuer inside a milter may be an indicator of 
> "trusted connection"
> and report my findings ...

as Viktor said:

a milter get issuer and subject only for connections SMTPD also log as "trusted"
On untrusted and anonymous connections the macros are empty.

That's enough for me...

Andreas

Re: verification levels and Milter

[A. Schulze]

Am 31.07.2017 um 20:16 schrieb Wietse Venema:

> I looked at the code for the cleanup daemon which is TLS unaware.
> So the corrected reply would be that we may have partial support.

Hello,

thanks to all. I'll give Viktor's point a try:
seeing cert_subject + cert_issuer inside a milter may be an indicator of 
"trusted connection"
and report my findings ...

Andreas

verification levels and Milter

[A. Schulze]

Hello,

postfix smtp server may classify incoming TLS sessions as anonymous, untrusted 
and trusted.
(http://www.postfix.org/FORWARD_SECRECY_README.html#status)

Is it possible to access this information from within a milter?

I did not found such funktionallity on 
http://www.postfix.org/MILTER_README.html#macros
so I expect "not documented -> not implemented" but I would like to be sure. 
Maybe I've overseen it...

Andreas

Re: Forward to gmail and DMARC

[A. Schulze]

Am 17.07.2017 um 09:48 schrieb Alex JOST:

> AFAIK Authenticated Received Chain (ARC) was designed for exactly this use 
> case. Wondering if anyone has some experience with it or knows if Gmail is 
> already honouring ARC-headers.

yes, there are multiple ARC implementations between alpha and production state.

a good entry for further information is http://arc-spec.org/
I personally work with OpenARC which is more alpha state.

At IETF 99 there was a Hackathon last weekend. People also worked on ARC.
(https://mailarchive.ietf.org/arch/msg/dmarc/CnIGMxYfiyuquzvr_KZ_uCvRW8I)

Andreas

Re: Forward to gmail and DMARC

[A. Schulze]

Am 16.07.2017 um 02:55 schrieb Peter:
> When Google sees SPAM coming form your server it will
> affect your server's IP reputation with Google

"your server's IP" has to be clarified:
as far as I know it's /32 for IPv4 and /64 for IPv6 ...

Andreas

Re: Forward to gmail and DMARC

[A. Schulze]

Am 15.07.2017 um 00:15 schrieb @lbutlr:
> On 14 Jul 2017, at 09:41, Dominic Raferd  wrote:
>> Me:
>>> Automated? Or is that something you do manually?
>>
>> Yes I have it automated
> 
> Oh, we'll that would be nifty to see what you've done if it's not too much 
> trouble.
> 

+1

Re: Any better ideas for grabbing Yahoo's known SMTP servers?

[A. Schulze]

Am 01.05.2017 um 06:19 schrieb Steve Jenkins:

> Yahoo! has always been problematic (no surprise) because unlike all the other 
> big mailers that Postwhite queries, they don't expose the IP addresses of 
> their outbound mailers via their SPF records.
Hello Steve,

SPF is intended for an other use case. It authenticates and given IP. Postwhite 
try to use SPF data bye reverse means so it's obvious limited.

Andreas

Re: connection caching - limitations

[A. Schulze]

Viktor Dukhovni:


You've provided no information on where the performance bottleneck lies.
What are the averages of the delays=a/b/c/d log values?


Thanks to Viktor for the reminder to "proof the performance bottleneck"
Today I send 5k messages and /measure/ the times.


  time for i in `seq 1 5000`; do sendmail -f $sender $recipient <  
msgfile; done

  real3m34.281s
  user0m13.120s
  sys 0m9.764s

first message
Apr 24 10:45:22 submitter postfix/pickup[14884]: 3wBKfp0Q7MzDYR:  
uid=12345 from=<$sender>
Apr 24 10:45:23 submitter postfix/smtp[17141]: 3wBKfp0Q7MzDYR:  
to=<$recipient>, relay=$MSA:25, delay=1.5, delays=0.05/0.01/0.49/1,  
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3wBKfp49pbz3h1D)


last message
Apr 24 10:48:56 submitter postfix/pickup[29155]: 3wBKkw1tlJzGNV:  
uid=12345 from=<$sender>
Apr 24 10:51:43 submitter postfix/smtp[30768]: 3wBKkw1tlJzGNV:  
to=<$recipient>, relay=$MSA:25, delay=167, delays=0.03/165/0.41/1.2,  
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3wBKp60c9kzXN9)


and some minutes later:
Apr 24 10:55:03 submitter postfix/scache[17300]: statistics: start  
interval Apr 24 10:45:23
Apr 24 10:55:03 submitter postfix/scache[17300]: statistics: domain  
lookup hits=0 miss=4995 success=0%



  the last message arrived ~4 minutes later at $recipient mailbox
  -> there is no problem (for me)

lesson learned: measure, don't suspect

Andreas

Re: connection caching - limitations

[A. Schulze]

Am 21.04.2017 um 16:08 schrieb Viktor Dukhovni:
> Message injection via sendmail(1) is much less efficient than injection
> via SMTP.  The message is synced to disk twice, and the pickup(8) service
> can only process one message at a time, while SMTP inject can handle
> multiple messages in parallel.

I'm aware of that. But (I think) submission is not the problem to me: The 
script take seconds only.
but then the messages are visible in the active queue. postfix start relaying 
to the MSA
one by one message up to $relay_destination_concurrency_limit (20) parallel.

> You've provided no information on where the performance bottleneck lies.
> What are the averages of the delays=a/b/c/d log values?
can look on Monday for these values

> Sure, and connection re-use is mainly helpful when some of the IP addresses
> of the SMTP servers for the nexthop domain are non-responsive and connections
> are timing out.
that's not the case

> Otherwise, connection caching offers only marginal gains.
> (If PTR records for your client's IP address are registered at a 
> non-responsive
> DNS server, that could be another source of per-connection overhead).
also not happen here

>> as expected, even "smtp_connection_cache_destinations = static:all" doesn't 
>> help.
>>
>> So what may be the strategy to speed up?
> 
> First identify the origin of the delays.  Lack of connection reuse is rarely
> the problem.
> 
> See:
> 
>   http://www.postfix.org/TUNING_README.html
>   http://www.postfix.org/QSHAPE_README.html
> 
OK, will read again, Thanks

One point to answer Wietse's suggestion: "Sending MULTI-RECIPIENT messages"
That's impossible because every message contain unique content for the
specific receiver. ( really 10k /different/ messages )

Andreas

connection caching - limitations

[A. Schulze]

Hallo,

that's my (legacy) setup:

a script generate 10k message files, same sender, different receiver.
they are injected using "sendmail -t -f sender < messagefile" in the local MTA
The MTA is configured to forward all messages to a central MSA.

This MSA require authentication and STARTTLS
All works fine, except speed.

The MTA uses one SMTP-Session per message. I think the reason is documented:
http://www.postfix.org/CONNECTION_CACHE_README.html#limitations, first bullet

as expected, even "smtp_connection_cache_destinations = static:all"  
doesn't help.


So what may be the strategy to speed up?

Thanks for ideas!
Andreas