[pfx] Re: [ext] active queue is too high

[Ralf Hildebrandt via Postfix-users]

* Gino Ferguson via Postfix-users :
> Hi,
> 
> 
> We have a relay server which has been working fine (postfix 3.3.0-1ubuntu0.4)
> 
> Now there are ~20K mails in the active queue for a certain recipient and they 
> are just sitting there.

mailq is reporting what reason?
 
> Such an email just comes in from the client, gets its queue id, etc. and 
> lands in the active queue. Then it stays there.

OK

> There are regularly repeated postfix/qmgr logs like this but nothing more:
> postfix/qmgr ... from=..., size=9499, nrcpt=1 (queue active)
> 
> How can I tell why postfix keeps them in the active queue for so long? 

Try grepping for the queueid of such an email.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: Feature request

[Ralf Hildebrandt via Postfix-users]

* Allen Coates via Postfix-users :

> > Better yet, don't be lazy, include a fingerprint string in your RHS
> > reject rule values.

> Postscreen doesn't have the option of unique RHS fingerprints;  nonetheless, 
> it would useful to see which (of several)
> ACLs was rejecting an incoming connection.

Luckily, postscreen doesn't use regexp (which was my use case) either :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Feature request

[Ralf Hildebrandt via Postfix-users]

Hi!

I wonder if this is possible:

If a PCRE/regexp style map is triggering, it can be quite hard to
find out WHICH pattern actually caused the action.

So maybe postmap (when invoked with "-b", "-h" or "-q key") could emit
which regular expression (or which line it was in) actually matched.

Yes, I could give all my regular expressions patterns a unique RHS or
find the regular expressions by divide-et-impera, but I'm being lazy.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: [OT] postfwd3 as check_policy_service hogging the CPU

[Ralf Hildebrandt via Postfix-users]

* Viktor Dukhovni via Postfix-users :

> Note that if you want the actual recipient addresses, (not just a
> count),

I just need the count in this case

> you'll need to also intercept recipient restrictions.

oh!

> The Postfix smtpd(8) server does not keep the recipient list in memory, the
> list is streamed out into the queue file (really cleanup service or
> pre-queue proxy filter).

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: [OT] postfwd3 as check_policy_service hogging the CPU

[Ralf Hildebrandt via Postfix-users]

* Matus UHLAR - fantomas via Postfix-users :

> > envelope sender address and number of recipients.
> 
> not authenticated user? ;-)

Yes, I'm also checking if the come from our exchangeserver.

> if you want to see/process mail size, using it in
> smtpd_end_of_data_restrictions is necessary.
> if not, you can use it in smtpd_data_restrictions.

Then I shall try that instead, since I don't care about the size of
the mail.

> However, I'd say the optimal place is where you need it.  Before
> smtpd_data_restrictions you don't see recipient_count either.

Yup.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] [OT] postfwd3 as check_policy_service hogging the CPU

[Ralf Hildebrandt via Postfix-users]

I'm using postfwd3 as a policy service for rate limiting based on the
envelope sender address and number of recipients.

We're both limiting "freemailer" senders (they can only reach a low
number of internal recipients before being restricted) as well as our
internal users (they can only reach a low number of external
recipients before being subject to inspection)

The integration into postfix boils down to:

smtpd_end_of_data_restrictions =
   check_policy_service  inet:127.0.0.1:10040

Now postfwd3 is written in Perl, and that thing is hogging the CPU:

# ltrace -c -p 2722940
% time seconds  usecs/call calls  function
-- --- --- - 
 24.955.368282  86 62012 free
 16.653.582837  86 41368 memmove
 15.743.387136  86 38990 malloc
 15.653.368211  86 39100 __errno_location
 10.812.327013  85 27109 calloc
 10.312.217849  86 25717 memcpy
  2.960.637078  85  7418 memcmp
  2.780.597770  85  6958 memchr
  ... snip ...
-- --- --- - 
100.00   21.516662249020 total
  
I put the check into smtpd_end_of_data_restrictions, so all recipients
are known... 

Is smtpd_end_of_data_restrictions maybe a suboptimal place for that 
check_policy_service?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] reject_unverified_recipient triggers Recipient address rejected

[Ralf Hildebrandt via Postfix-users]

>   postfix/submission/smtpd[23263]: NOQUEUE: reject: RCPT from
> unknown[21.193.143.55]: 450 4.1.1 : Recipient address rejected:
> unverified address: unknown mail transport error; from=
> to= proto=ESMTP helo=

The verification fails with a "unknown mail transport error"

Check the logs (on both sides, sending and receiving):

egrep "(error|fatal):" /var/log/mail.log (or wherever your logs are)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: transport_maps : fatal: garbage after "]" in server description...

[Ralf Hildebrandt via Postfix-users]

> i am running Postfix 3.4.14 and try to set up mailrouting to multiple
> smtp hosts.
>  transport_maps = hash:/etc/postfix/mailertable
> 
> example.com  smtp:[mx1.foobar.com],smtp:[mx2.foobar.com]
> 
> However i get:
>  fatal: garbage after "]" in server description:
> [mx1.foobar.com],smtp:[mx2.foobar.com]
> 
> Whats the correct syntax? I cant find a hint in the docs :-/

example.com   smtp:[mx1.foobar.com],[mx2.foobar.com]

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Logging of SMTP smuggling mitigation

[Ralf Hildebrandt via Postfix-users]

> Would it be possible to log at least the queue-id as well? Also sender
> and/or recipient would be nice ;-) Or is it for security that no more
> information is logged?

20240104

Cleanup: when the Postfix SMTP server rejects bare ,
log the helo, mail and rcpt information if available. Files:
smtpd/smtpd.c, smtpd/smtpd_check.c.

Will be in 3.9, but I guess not in the other versions.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Downloadlinks for postfix-3.9-20240109 seem to be broken

[Ralf Hildebrandt via Postfix-users]

http://ftp.porcupine.org/mirrors/postfix-release/index.html

lists:

http://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.9-20240109.tar.gz
http://ftp.porcupine.org/mirrors/postfix-release/experimental/postfix-3.9-20240109.HISTORY

both of which report:

The requested URL 
/mirrors/postfix-release/experimental/postfix-3.9-20240109.tar.gz was not found 
on this server.
The requested URL 
/mirrors/postfix-release/experimental/postfix-3.9-20240109.HISTORY was not 
found on this server.
Apache/1.3.29 Ben-SSL/1.53 Server at ftp.porcupine.org Port 80

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] 25 years today

[Ralf Hildebrandt via Postfix-users]

* Wietse Venema via Postfix-users :

> As a few on this list may recall, it is 25 years ago today that the
> "IBM secure mailer" had its public beta release. This was accompanied
> by a nice article in the New York Times business section.

Ah, it's today. Recently I scrolled through the Changelog and wondered
"oh, it's 25 years soon".
 
> That was a long time ago. Postfix has evolved as the Internet has
> changed. I am continuing the overhaul of this software, motivated
> by people like you on this mailing list.

Cheers, on to the next 25 years :*

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Why can't I get /etc/aliases to do anything?

[Ralf Hildebrandt via Postfix-users]

* Chris Green via Postfix-users :
> On Tue, Dec 05, 2023 at 05:41:11PM +0100, Ralf Hildebrandt via Postfix-users 
> wrote:
> > * Chris Green via Postfix-users :
> > 
> > > mydestination = 
> > 
> > no mail is delivered locally. Thus "/etc/aliases" doesn't get to do
> > anything
> > 
> Ah, that explains it.
> 
> So what's the minimal way of doing this?
> 
> I don't want to deliver any mail locally but I do want something like
> /etc/aliases to redirect mail sent to root (i.e. errors) to me off site.

I'd say:
leave mydestination at the default (delete the line from main.cf)
then it should work.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Why can't I get /etc/aliases to do anything?

[Ralf Hildebrandt via Postfix-users]

* Chris Green via Postfix-users :

> mydestination = 

no mail is delivered locally. Thus "/etc/aliases" doesn't get to do
anything

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] non_smtpd_milters = $smtpd_milters

[Ralf Hildebrandt via Postfix-users]

* duluxoz via Postfix-users :
> A quick question (just to clarify things in my own mind):
> 
> If `non_smtpd_milters = $smtpd_milters`, does this mean that an email
> received on port 25 passes through the milters twice; once for the
> `smtpd_milters` (from the `smtpd(8)` process) and again for the
> `non_smtpd_milters` (from the `cleanup(8)` process)?

No.

non_smtpd_milters are for new mail that does not arrive via the
Postfix smtpd server. This includes local submission via the
sendmail command line, new mail that arrives via the Postfix
qmqpd server, and old mail that is re-injected into the queue with
"postsuper -r".

smtpd_milters are for new mail that arrives via the Postfix smtpd(8)
server.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] gmail failing SPF/DKIM

[Ralf Hildebrandt via Postfix-users]

* Linkcheck via Postfix-users :

> If someone wishes to check this, a typical form (which is sent to me with
> copy to "you") is at
> https://www.linkcheck.co.uk/
>   under menu option Contact & Enquiries.

I tried your form:

Authentication-Results: mail-cbf-ext.charite.de;
dkim=pass header.d=linkcheck.co.uk header.s=mail header.b=LiOUpR1t;
spf=pass (mail-cbf-ext.charite.de: domain ofenquiryf...@linkcheck.co.uk 
designates 185.35.151.121 as permitted sender) 
smtp.mailfrom=enquiryf...@linkcheck.co.uk; 
dmarc=pass (policy=reject) header.from=linkcheck.co.uk

Looking good if you ask me :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] CORRECTION: How to temporarily pause virtual mail delivery

[Ralf Hildebrandt via Postfix-users]

* Wietse Venema via Postfix-users :
> Wietse Venema via Postfix-users:
> > If you use defer_transports to freeze mail deliveries, then some
> > messages may get close to the bounce_queue_lifetime, meaning that
> > Postfix will try to deliver them only once.
> 
> And that was incorrect. defer_transports will not freeze mail in
> the queue, it just moves a message to the deferred queue withoout
> trying to deliver it. After a message reaches bounce_queue_lifetime,

bounce_queue_lifetime or maximal_queue_lifetime (depending on what it
is)?

> it may be returned to sender just like any deferred message.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: Question about postscreen

[Ralf Hildebrandt via Postfix-users]

* Matus UHLAR - fantomas via Postfix-users :

> > And thus the solution is: Don't use the dnsbl in postscreen, but ONLY
> > in spamassassin/rspamd instead.
> 
> No problem, you can safely use postscreen with multiple DNSBLs and DNSWLs.
> - just don't rely on single hit, unless it's your own DNSBL.

Hey, it was not my idea, but the OP's :)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: Question about postscreen

[Ralf Hildebrandt via Postfix-users]

* Matus UHLAR - fantomas via Postfix-users :
> On 02.11.23 10:49, Ivan Ionut via Postfix-users wrote:
> > Hi, it's possible that  postscreen does not block the email when
> > postscreen_dnsbl_threshold is reached but to pass that email to
> > spamassassin(with a score and a tag).
> 
> Postscreen does not tag. It passes or blocks the mail.

And thus the solution is: Don't use the dnsbl in postscreen, but ONLY
in spamassassin/rspamd instead.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] *.mail.protection.outlook.com reporting "452 4.5.3 Too many recipients (AS780090)" for many domains

[Ralf Hildebrandt via Postfix-users]

Hi!

Since this morning, various MX hosts in *.mail.protection.outlook.com
reporting are reporting back temporary errors for us:

Exhibit A) 

host ohri-ca.mail.protection.outlook.com[104.47.75.228] said: 452 4.5.3 Too 
many recipients (AS780090) [YQBCAN01FT018.eop-CAN01.prod.protection.outlook.com 
2023-10-11T02:11:41.144Z 08DBC99CDEC51952] (in reply to RCPT TO command)
(for a mail with 4 recipients, in that particular case)

Exhibit B)

host fraport-de.mail.protection.outlook.com[52.101.73.16] said: 451 4.7.500 
Server busy. Please try again later from [193.175.73.209]. (S77719) 
[AMS0EPF019E.eurprd05.prod.outlook.com 2023-10-11T01:32:21.804Z 
08DBC9B278D9A989] (in reply to end of DATA command)
(for a single recipient mail)

This is happening for multiple tenants on *.mail.protection.outlook.com
Has anybody made similar observations? According to
https://sendersupport.olc.protection.outlook.com/snds/ : "All of the specified 
IPs have normal status."

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] milter outgoing not working

[Ralf Hildebrandt via Postfix-users]

* Ralf Hildebrandt via Postfix-users :
> * Stanislav via Postfix-users :
> > Greetings,
> > 
> > After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email
> > is not signed with DKIM anymore. After further investigation, I've found
> > that Postfix ignores milter on outgoing emails (incoming goes through milter
> > ok).
> 
> How is the milter being invoked?
> postconf -n |grep milter

In my case this yields:

# postconf -n |fgrep milter
non_smtpd_milters = $smtpd_milters
smtpd_milters = inet:127.0.0.1:7357 inet:127.0.0.1:8891

^ so, two milters are used: clamav-milter and opendkim

# netstat -tulpen | egrep "(7357|8891)"
tcp0  0 127.0.0.1:8891  0.0.0.0:* LISTEN  983
295923257  3588942/opendkim
tcp0  0 127.0.0.1:7357  0.0.0.0:* LISTEN  981
318524015  39048/clamav-milter 

(you might be using milters in master.cf, selectively for some
processes only, so also check master.cf)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] milter outgoing not working

[Ralf Hildebrandt via Postfix-users]

* Stanislav via Postfix-users :
> Greetings,
> 
> After upgrading from postfix 3.7.3 to postfix 3.8.2, I've noticed my email
> is not signed with DKIM anymore. After further investigation, I've found
> that Postfix ignores milter on outgoing emails (incoming goes through milter
> ok).

How is the milter being invoked?
postconf -n |grep milter

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] pipelining issue

[Ralf Hildebrandt via Postfix-users]

* Joey J via Postfix-users :

> I have been getting a ton of pipelining errors over the past few weeks and
> I can't figure out why.

I'm not seeing any here, so let's focus on what you're posting here.

> It keeps saying queue write error, but disk & cpu performance is good, disk
> space is good.

What does your log day for those events?

>  In:  MAIL FROM: SIZE=36318
>  In:  RCPT TO:

Most likely it's a filter of some sort, probably a milter or a
pre-queue filter.

Show "postconf -n" output.

>  In:  MAIL 
> FROM:<3yzajzrukbnydggc6j-klm5ag-fgj6hdq8gg8d6.4ge2d6p2f5j6mk@data-studio.bounces.google.com>

Given thar address, this event should be easy to find in the logs

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netz | Netzwerk-Administration
  Invalidenstraße 120/121 | D-10115 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] TLS issues

[Ralf Hildebrandt via Postfix-users]

> smtpd_tls_cert_file = /etc/pki/tls/certs/postfix.pem
> smtpd_tls_key_file = /etc/pki/tls/private/postfix.key

Try adding:

smtp_tls_key_file = $smtpd_tls_key_file
smtp_tls_cert_file = $smtpd_tls_cert_file

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] warn_if_reject and MILTER

[Ralf Hildebrandt via Postfix-users]

* Patrick Ben Koetter via Postfix-users :
> Greetings,
> 
> I was wondering if there's something similar to warn_if_reject when it comes
> to dry-run  / test-run MILTER applications in Postfix. The documentation on
> warn_if_reject does not mention MILTERs, which usually means the feature isn't
> there because otherwise it would be documented, and the per-Milter settings in
> MILTER_README don't mention something I could use to warn_if_reject either.

If I remember correctly, sof_bounce is some sort of el-cheapo "replace
5 with 4 in the output to the client"-thing. And thus should work even
with milters.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Help with spamhaus listing

[Ralf Hildebrandt via Postfix-users]

* Tom Reed via Postfix-users :
> 
> Dear lists,
> 
> I in fact use rarely this mailbox: t...@dkinbox.com
> But today I found both my domain "dkinbox.com" and the mailserver IP:
> 38.45.66.54 are listed into spamhaus "css" and "dbl" blacklists.

Checking https://multirbl.valli.org/lookup/38.45.66.54.html yields
other listings, sometimes with reasons:

"Spamtrap hit"

another listings ( https://matrix.spfbl.net/38.45.66.54 ) shows:

"This IP was flagged due to misconfiguration of the e-mail service or
the suspicion that there is no MTA at it." (and it's not rDNS - my
addition!)

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: DKIM and DMARC

[Ralf Hildebrandt via Postfix-users]

* Scott Kitterman via Postfix-users :

> DKIM has no policy mechanism associated with it, so there's no basis in any 
> standardized mechanism to determine if a DKIM failure should be cause for 
> rejection.  I don't think it makes logical sense to treat a message with a 
> DKIM signature that failed to verify any more harshly than you would unsigned 
> mail.
> 
> DMARC does have such a policy component.  Rejecting mail which fails DMARC 
> for domains that have a policy of p=reject is common.  DMARC does have a high 
> error rate for some types of email, so I would recommend a careful evaluation 
> of what you would be rejecting before you do so.

I always thought DMARC was the policy component for DKIM.
-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] how to implement plus address

[Ralf Hildebrandt via Postfix-users]

* Tom Reed via Postfix-users :
> Hello
> 
> How can I implement the following feature?
> the messages sent to:
> 
> foo+la...@sample.com
> foo+lab...@sample.com
> ...
> 
> all them will be delivered into:
> f...@sample.com

recipient_delimiter = +

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] multi smtp servers question

[Ralf Hildebrandt via Postfix-users]

* Corey Hickman via Postfix-users :
> Hello list,
> 
> We have 3 smtp servers for sending messages. When mail in one server has
> delivery issue, how can we setup it to use another more servers for
> second/third delivery?

You could use smtp_fallback_relay

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Question to reject_rbl_client zen.spamhaus.org

[Ralf Hildebrandt via Postfix-users]

> smtpd_recipient_restrictions =
>permit_mynetworks,
>permit_sasl_authenticated,
>reject_unauth_destination,
>check_policy_service unix:private/policyd-spf,
>reject_rbl_client zen.spamhaus.org,
>reject_rbl_client bl.spamcop.net
> 
> When I sent message from a Spamhaus Zen listed IP (this IP not in my
> whitelist), the message still came into system.

In that case you either sent from:

a client in $mynetworks (permit_mynetworks)
or
an authenticated client (permit_sasl_authenticated)

Another option might be that your mailserver is querying
zen.spamhaus.org and bl.spamcop.net via a public resolver (1.1.1.1,
8.8.8.8 or the like) which might cause all kinds of odd problems --
thus examine /etc/resolv.conf

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: Issues on incoming queue

[Ralf Hildebrandt via Postfix-users]

* Wietse Venema via Postfix-users :

> Start by looking for "@domain" wildcards in virtual_alias_maps or

Somewhat related: I was under the impression that virtual_alias_maps
"@domainA @domainB" did NOT break recipient verifiction. Or am I
hallucinating?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Issues on incoming queue

[Ralf Hildebrandt via Postfix-users]

* Israel britto via Postfix-users :

> Hey, I have a strange problem, my incoming queue is growing and my
> active and deferred queues are low on queue items. I checked and I
> have a lot of incoming mailer-daemon and double-bounce emails, is
> there a way to discard these messages?

Read them using "postcat -q QUEUEID" to find out what's causing them.
Then fix that first.

> I've already tried to create a transport_map by sending all incoming messages 
> to my domain to be discarded, like this @mydomain discard:silently
> But even so I continue to be flooded with messages of this type in incoming.

Yes, since they come in FIRST to be discarded after!

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] secondary MX server

[Ralf Hildebrandt via Postfix-users]

* Corey Hickman via Postfix-users :

> Since almost every sending MTA has the queues, do I need a secondary MX for
> my domain email?

I don't know if the RFC mandate it, but nowadays everbody knows
better, so WTF.

> I am afraid the secondary MX was abused by spammers.

Indeed. The secondary basically needs to have the same setup as the
primary in terms of anti spam and recipient lists.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] Re: Configuration of postfix on Ubuntu 22

[Ralf Hildebrandt via Postfix-users]

* Aosars Repository via Postfix-users :
> Hi all,
> I have installed postfix on Ubuntu server 22 and configured to use gmail
> smtp.But it fails to send mails.

The log should inform you why it's failing.

I have a config snippet here:

main.cf:

smtp_use_tls=yes

relayhost = smtp.gmail.com:587
# we want to relay all mails via smtp.gmail.com (port 587)

smtp_sasl_auth_enable = yes
# we need username password for that

smtp_sasl_password_maps = hash:/etc/postfix/sasl_password_maps
# username password are stored in /etc/postfix/sasl_password_maps

/etc/postfix/sasl_password_maps contains:

smtp.gmail.com
my-gmail-addr...@gmail.com:theapplicationspecificpasswordforthisserver

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [ext] difference between relay and smtp

[Ralf Hildebrandt via Postfix-users]

* Gino Ferguson via Postfix-users :

> Can you explain me the practical difference between relay and smtp delivery 
> on a relay server? 

The "relay" and "smtp" service are both "smtp" services.

But: If you seperated "relay" from "smtp" you can do stuff like:

defer_transports = relay

without affecting mail to other destinations.

Also, the qmgr is assigning delivery slots to services in a
round-robin fashion, so having one for "relay" and one for "smtp"
ensures fairness for relaying duties vs. delivery to external sites.

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

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

[Ralf Hildebrandt via Postfix-users]

* Benny Pedersen via Postfix-users :
> Mar 17 11:38:31 localhost postfix/smtpd[22150]: lost connection after 
> STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]
> Mar 17 12:09:10 localhost postfix/smtpd[23415]: lost connection after 
> STARTTLS from list.sys4.de[2a03:4000:10:51d:b8ce:63ff:feca:a5a0]
> 
> maybe it works ?

I'll check. Which IP is that?

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: A new Postfix book in the making - "Run Your Own Mail Server"

[Ralf Hildebrandt via Postfix-users]

> The books Michael writes are little gems, nice to read, often funny,
> always "to-the-point" and not expensive. This might be his most
> important (technical) book.

I took a quick glance, and Chapter 0 is looking good!

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | https://www.charite.de

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

[pfx] Re: [P-U] Re: New List Host and Reply-to Header

[Ralf Hildebrandt via Postfix-users]

* Patrick Ben Koetter via Postfix-users :

> approach to subscriber self management. Once you've become a registered
> MLM platform participant you can easily change settings that will apply to all
> lists you've subscribed to in one place. I consider that a great usability
> benefit for subscribers.

Furthermore, mm2 get's rid of the awful "this is your password" mails.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
___
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

[Ralf Hildebrandt]

* Wietse Venema :

> Look in $queue_directory/etc/resolv.conf or /etc/resolv.conf.

nameserver 127.0.0.1
search DOMAINS

Interesting side effect. I need to check all my systems for this :(

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: dig reports NXDOMAIN but Postfix thinks otherwiese

[Ralf Hildebrandt]

> Dec  6 12:41:02 mail-cvk-int postfix/smtp[1145453]: connect to 
> kompetenznetz-darmerkrankungen.com[18.64.79.37]:25: Connection timed out
> Dec  6 12:41:32 mail-cvk-int postfix/smtp[1145453]: connect to 
> kompetenznetz-darmerkrankungen.com[18.64.79.121]:25: Connection timed out
> 
> WTF? I'll try query logging in unbound to see what is happening here.

Dec  6 12:46:49 mail-cvk-int unbound: [1147087:6] info: 127.0.0.1 
kompetenznetz-darmerkrankungen.com. MX IN
Dec  6 12:46:49 mail-cvk-int unbound: [1147087:5] info: 127.0.0.1 . NS IN
Dec  6 12:46:49 mail-cvk-int unbound: [1147087:7] info: 127.0.0.1 
kompetenznetz-darmerkrankungen.com. A IN
Dec  6 12:46:49 mail-cvk-int unbound: [1147087:7] info: 127.0.0.1 
kompetenznetz-darmerkrankungen.com. A IN
Dec  6 12:46:49 mail-cvk-int unbound: [1147087:5] info: 127.0.0.1 
kompetenznetz-darmerkrankungen.com.DOMAINS. A IN

And alas, kompetenznetz-darmerkrankungen.com.DOMAINS. resolves to:

# host kompetenznetz-darmerkrankungen.com.DOMAINS.
kompetenznetz-darmerkrankungen.com.DOMAINS has address 18.64.79.37
kompetenznetz-darmerkrankungen.com.DOMAINS has address 18.64.79.121
kompetenznetz-darmerkrankungen.com.DOMAINS has address 18.64.79.28
kompetenznetz-darmerkrankungen.com.DOMAINS has address 18.64.79.17

But what is appending ".DOMAINS."?

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: dig reports NXDOMAIN but Postfix thinks otherwiese

[Ralf Hildebrandt]

* Wietse Venema :

> > >From my queue:
> > ==
> > 
> > 4NRDBY1xyHz1Z1SX286400 Tue Dec  6 09:30:29 sen...@charite.de
> > (connect to kompetenznetz-darmerkrankungen.com[18.64.79.37]:25: Connection 
> > timed out)
> >
> > recipi...@kompetenznetz-darmerkrankungen.com
> 
> Is the SMTP client chrooted? Try: postconf -F "*/*/chroot"

smtp/unix/chroot = y
 
> You have "smtp_host_lookup = dns, native" which means that the
> Postfix SMTP client will use nsswitch.conf if a name is not found
> in DNS.

Yes, but I don't have kompetenznetz-darmerkrankungen.com in my hosts
file.

# grep hosts /etc/nsswitch.conf
hosts:  files dns

But anyway, I'll simply un-chroot smtp, stop & start postfix and see
what's happening:

Dec  6 12:41:02 mail-cvk-int postfix/smtp[1145453]: connect to 
kompetenznetz-darmerkrankungen.com[18.64.79.37]:25: Connection timed out
Dec  6 12:41:32 mail-cvk-int postfix/smtp[1145453]: connect to 
kompetenznetz-darmerkrankungen.com[18.64.79.121]:25: Connection timed out

WTF? I'll try query logging in unbound to see what is happening here.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

dig reports NXDOMAIN but Postfix thinks otherwiese

[Ralf Hildebrandt]

>From my queue:
==

4NRDBY1xyHz1Z1SX286400 Tue Dec  6 09:30:29 sen...@charite.de
(connect to kompetenznetz-darmerkrankungen.com[18.64.79.37]:25: Connection 
timed out)
   
recipi...@kompetenznetz-darmerkrankungen.com

and dig says:
=

# host kompetenznetz-darmerkrankungen.com
Host kompetenznetz-darmerkrankungen.com not found: 3(NXDOMAIN)
# host -t mx kompetenznetz-darmerkrankungen.com
Host kompetenznetz-darmerkrankungen.com not found: 3(NXDOMAIN)

I restarted the local "unbound" process. Same result.

Relevant options ( postconf |egrep "(resolv|dns)" ):


disable_dns_lookups = no
dns_ncache_ttl_fix_enable = no
smtp_dns_reply_filter =
smtp_dns_resolver_options =
smtp_dns_support_level = dnssec
smtp_host_lookup = dns, native

What am I doing wrong here?
Why is this mail not bouncing?

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: 20200108 -- nexthop destinations separated by comma or whitespace

[Ralf Hildebrandt]

* Viktor Dukhovni :

> > exchange.charite.de   
> > exchange:s-mx14-ht01.charite.de,exchange:s-mx14-ht02.charite.de
> 
> This looks wrong, it should be :
> 
> exchange.charite.de   
> exchange:s-mx14-ht01.charite.de,s-mx14-ht02.charite.de
> 
> One "exchange" transport, multiple nexthop hosts.

Cool.
 
> Not sure why it worked, it wasn't supposed to. :-)

Maybe it always tried the first entry, and once the first machine was
unreachable (or failed, see the log snippet) it tried the second
machine - just to find a broken nexthop!

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

20200108 -- nexthop destinations separated by comma or whitespace

[Ralf Hildebrandt]

I don't see the change 20200108 reflected in the transport(5) man page.

While this isn't a problem per se, I have been using this form for
internal routing:

exchange.charite.de   
exchange:s-mx14-ht01.charite.de,exchange:s-mx14-ht02.charite.de

to get rid of the pesky internal MX record for exchange.charite.de.

This worked until this morning 09:10:59 (I 've been using 20200112, I
upgraded now, though):

Jan 29 07:14:10 mail-cbf-int postfix/master[3584]: reload -- version 
3.5-20200112, configuration /etc/postfix
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32685]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32885]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32884]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32943]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[33545]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[33707]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:12:00 mail-cbf-int postfix/smtp[34103]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:12:48 mail-cbf-int postfix/master[3584]: reload -- version 
3.5-20200112, configuration /etc/postfix

Interesting logs:

Jan 29 09:10:59 mail-cbf-int postfix/tlsproxy[33285]: DISCONNECT 
[10.32.37.105]:25
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32685]: 486x4x5kyfz20krL: lost 
connection with s-mx14-ht01.charite.de[10.32.37.105] while sending end of data 
-- message may be sent more than once
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32685]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32885]: 486x4x5tWJz20kyZ: lost 
connection with s-mx14-ht01.charite.de[10.32.37.105] while sending end of data 
-- message may be sent more than once
Jan 29 09:10:59 mail-cbf-int postfix/tlsproxy[33285]: DISCONNECT 
[10.32.37.105]:25
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32885]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp
Jan 29 09:10:59 mail-cbf-int postfix/tlsproxy[33285]: DISCONNECT 
[10.32.37.105]:25
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32884]: 486x4y0nSFz20l2f: lost 
connection with s-mx14-ht01.charite.de[10.32.37.105] while sending end of data 
-- message may be sent more than once
Jan 29 09:10:59 mail-cbf-int postfix/smtp[32884]: fatal: unknown service: 
s-mx14-ht02.charite.de/tcp

and later:

Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange 
failure -- see a previous warning/fatal/panic logfile record for the problem 
description
Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange 
failure -- see a previous warning/fatal/panic logfile record for the problem 
description
Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange 
failure -- see a previous warning/fatal/panic logfile record for the problem 
description
Jan 29 09:11:00 mail-cbf-int postfix/qmgr[2174]: warning: transport exchange 
failure -- see a previous warning/fatal/panic logfile record for the problem 
description

I checked that transport_maps has not been changed prior to the failure:

Jan 29 09:26:31 mail-cbf-int postfix/trivial-rewrite[46120]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:27:11 mail-cbf-int postfix/trivial-rewrite[46273]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:27:12 mail-cbf-int postfix/trivial-rewrite[46290]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:28:12 mail-cbf-int postfix/trivial-rewrite[46471]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:28:20 mail-cbf-int postfix/trivial-rewrite[46558]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:36:58 mail-cbf-int postfix/trivial-rewrite[49739]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:37:00 mail-cbf-int postfix/trivial-rewrite[46807]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:37:04 mail-cbf-int postfix/trivial-rewrite[47049]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting
Jan 29 09:40:06 mail-cbf-int postfix/trivial-rewrite[51439]: table 
cdb:/etc/postfix/transport(0,lock|no_regsub|fold_fix|utf8_request) has changed 
-- restarting


-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer

[OT] SOPHOS savdid/savd privilege question

[Ralf Hildebrandt]

Currently I'm using SOPHOS savdid/savd within rspamd.

* savdid is running as unprivileged user "sophosav"
* savd, on the other hand, is run as root - probably by default :(

Naturally, I'd like savd to run as a non-root user, but is that
possible at all? Anybody got some hints and caveats for such a setup?

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: outbound.protection.outlook.com

[Ralf Hildebrandt]

* ratatouille :
> Hello!
> 
> Do I really have to whitelist all the IPs of outbound.protection.outlook.com 
> in postgrey?

Yes. There's a script for that:

# Postwhite - Automatic Postcreen Whitelist / Blacklist Generator #
# https://github.com/stevejenkins/postwhite   #
# By Steve Jenkins (https://www.stevejenkins.com/)#

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: sasl config confusion postfix 2.10.1

[Ralf Hildebrandt]

* Fazzina, Angelo :
> 
> Hi, I added this to main.cf
> 
> relayhost = [massmail.uconn.edu]:587
> smtp_fallback_relay = [massmail.uconn.edu]:587
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/nexus_passwd
> smtp_sasl_security_options =

This is looking ok. You're talking to [massmail.uconn.edu]:587
using SASL and the password is in /etc/postfix/nexus_passwd

> I added this to master.cf
> submission inet n   -   n   -   -   smtpd
>   -o syslog_name=postfix/submission
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o milter_macro_daemon_name=ORIGINATING

I don't think you need this at all.

> Aug  7 12:27:28 production0 postfix/cleanup[18993]: 89C1F121242FF: 
> message-id=<20190807162728.89c1f12124...@production0.nexus.uconn.edu>
> Aug  7 12:27:28 production0 postfix/bounce[19011]: 85A08121242FE: sender 
> non-delivery notification: 89C1F121242FF
> Aug  7 12:27:28 production0 postfix/qmgr[18989]: 89C1F121242FF: from=<>, 
> size=3290, nrcpt=1 (queue active)
> Aug  7 12:27:59 production0 postfix/smtp[18995]: 89C1F121242FF: 
> to=, 
> relay=massmail.uconn.edu[137.99.26.55]:587, delay=31, delays=0/0/31/0, 
> dsn=5.7.0, status=bounced (host massmail.uconn.edu[137.99.26.55] said: 530 
> 5.7.0 Must issue a STARTTLS command first (in reply to MAIL FROM command))
> Aug  7 12:27:59 production0 postfix/qmgr[18989]: 89C1F121242FF: removed
> 
> 
> What am I doing wrong ?

Your machine is client to massmail.uconn.edu
Your machine needs to use STARTTLS before it issues a SMTP AUTH command

smtp_tls_security_level = may

smtp_tls_loglevel  = 1
smtp_tls_note_starttls_offer = yes

# you might need to use your own keys/certificates here, these are
# mine and my paths
smtp_tls_key_file  = /etc/ssl/private/mail-cvk-int.charite.de.key
smtp_tls_cert_file = /etc/ssl/certs/mail-cvk-int.charite.de.pem-chain
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt


-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails to gmail bouncing

[Ralf Hildebrandt]

* Wietse Venema :
> Viktor Dukhovni:
> > > On Jun 21, 2019, at 3:32 AM, Ralf Hildebrandt  wrote:
> > > 
> > > /^452-4\.2\.2 (The email account that you tried to reach is over 
> > > quota.*)/ 552 5.2.2 ${1}
> > 
> > Just as I expected. Now change that to:
> > 
> >   /^4(52[- ]4\.2\.2 The email account that you tried to reach is over 
> > quota.*)/ 5${1}
> > 
> > and don't do it again! :-)
> > 
> 
> Use smtp_delivery_status_filter instead.
> 
> (Postfix uses the last 452-4.2.2 from the multiline response)

Thanks!

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Smptd intruder

[Ralf Hildebrandt]

* John Plate :
> Hi
> 
> I introduced "smtpd_reject_unlisted_sender=yes" in main.cf to avoid attempts 
> to login to my smtpd.

This doesn't block logins, it merely blocks envelope sender addresses
it KNOWS NOT TO exist (mainly stuff from your own domain -- i.e. if you
only have the address a@domain.example, nobody can use
b@domain.example or c@domain.example as sender)

> This morning it looks like an unknown ip-number succeded:
> 
> Jun 23 07:38:02 lunar postfix/smtpd[14806]: connect from 
> unknown[185.137.111.22]

What you want is
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname
or
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname

in Postfix lingo it means "block IP addresses with no hostname assigned
or the assigned hostname doesn't resolve back to the same IP.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails to gmail bouncing

[Ralf Hildebrandt]

* Viktor Dukhovni :
> > On Jun 21, 2019, at 3:32 AM, Ralf Hildebrandt  wrote:
> > 
> > /^452-4\.2\.2 (The email account that you tried to reach is over quota.*)/ 
> > 552 5.2.2 ${1}
> 
> Just as I expected. Now change that to:
> 
>   /^4(52[- ]4\.2\.2 The email account that you tried to reach is over 
> quota.*)/ 5${1}
> 
> and don't do it again! :-)

I rather deleted the whole thing. Better not meddle with that stuff.

Sorry for the noise. I cut & pasted the erroneous regexp to
mail.python.org as well -- which Is why I was seeing it there as well

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails to gmail bouncing

[Ralf Hildebrandt]

* Wietse Venema  Ralf, you need to fix your smtp_reply_filter :-( You replace "452-"
> with "552 ", and break one multiline response into two responses.
> We can help if you share the regexp.

That's probably the one:

/^452-4\.2\.2 (The email account that you tried to reach is over quota.*)/ 552 
5.2.2 ${1}

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Workaround: Mails to gmail bouncing

[Ralf Hildebrandt]

* Wietse Venema :
> Ralf Hildebrandt:
> > Jun 19 09:52:43 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
> > to=, 
> > relay=gmail-smtp-in.l.google.COM[173.194.76.26]:25, delay=4.8, 
> > delays=3.3/0.04/0.62/0.84, dsn=5.5.0, status=bounced (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))
> 
> Perhaps they messed up their SMTP command pipelining implementation.
> 
> Workaround:
> 
> /etc/postfix/main.cf:
>smtp_delivery_status_filter = pcre:/etc/postfix/smtp_dsn_filter
> 
> /etc/postfix/smtp_dsn_filter:
> /^5(\.5\.0 Protocol error: .+ in reply to DATA command.+)/ 4$1
> 
> This way some deliveries will be delayed instead of bounced.

I applied this at mail.python.org

> We could use debug_peer_list=google.com to make a recording (with
> debug_peer_level=1).

I applied this at mail.python.org

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails to gmail bouncing

[Ralf Hildebrandt]

* Viktor Dukhovni :

> The correct reply to "DATA" is "354" not "250".  Something is awfully
> out of sync if Gmail is returning "250" in response to "DATA".
> 
> That's presumably a response for one of the recipients, so Gmail
> sent one more response than Postfix expects, or Gmail received
> one more command than Postfix expected to send.

First entry for gmail was:

Jun 19 09:52:42 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, 
relay=gmail-smtp-in.l.google.COM[173.194.76.26]:25, delay=4.8, 
delays=3.3/0.04/0.62/0.84, dsn=5.2.2, status=bounced (host 
gmail-smtp-in.l.google.COM[173.194.76.26] said: 552 5.2.2 The email account 
that you tried to reach is over quota. Please direct (in reply to RCPT TO 
command))
Jun 19 09:52:42 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: host 
gmail-smtp-in.l.google.COM[173.194.76.26] said: 452-4.2.2 the recipient to 452 
4.2.2 https://support.google.com/mail/?p=OverQuotaTemp w9si551343wmd.47 - gsmtp 
(in reply to RCPT TO command)
Jun 19 09:52:42 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, 
relay=gmail-smtp-in.l.google.COM[173.194.76.26]:25, delay=4.8, 
delays=3.3/0.04/0.62/0.84, dsn=5.5.0, status=bounced (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))
... lots of protocol errors ...
Jun 19 09:52:43 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, relay=gmail-smtp-in.l.google.COM[173.194.76.26]:25, 
delay=4.8, delays=3.3/0.04/0.62/0.84, dsn=5.5.0, status=bounced (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))
Jun 19 09:52:44 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, 
relay=alt1.gmail-smtp-in.l.google.COM[108.177.14.26]:25, delay=6.7, 
delays=3.3/0.04/2.9/0.44, dsn=2.0.0, status=sent (250 2.0.0 OK 1560930764 
q30si13988623lfb.86 - gsmtp)

so the first one causes an error (during the RCPT TO: stage) which then causes 
the rest to get out
of sync in the DATA stage - except for the last one (which goes to another 
server!)

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails to gmail bouncing

[Ralf Hildebrandt]

* 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. :-(

Probably getting old :)
 
> The correct reply to "DATA" is "354" not "250".  Something is awfully
> out of sync if Gmail is returning "250" in response to "DATA".

Yep. See the other logs from mail.python.org -- maybe this heavily
depends on connection caching or pipelining?
 
> That's presumably a response for one of the recipients, so Gmail
> sent one more response than Postfix expects, or Gmail received
> one more command than Postfix expected to send.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mails to gmail bouncing

[Ralf Hildebrandt]

>  "250 2.0.0 OK 1560930762 l7si9891184wrx.266 - gsmtp"
> 
> is acceptable, while
> 
>  "250 2.1.5 OK w9si551343wmd.47 - gsmtp"
> 
> is a protocol error?

I fired up ye olde grep on mail.python.org and found some incidients
there as well:

# zegrep -c "status=bounced \(Protocol error: host gmail.* 250 2\.1\.5" 
/var/log/mail.log*
/var/log/mail.log:2
/var/log/mail.log.1:6
/var/log/mail.log.2.gz:8
/var/log/mail.log.3.gz:3
/var/log/mail.log.4.gz:9
/var/log/mail.log.5.gz:10
/var/log/mail.log.6.gz:34
/var/log/mail.log.7.gz:21
/var/log/mail.log.8.gz:26
/var/log/mail.log.9.gz:8
/var/log/mail.log.10.gz:3
/var/log/mail.log.11.gz:5
/var/log/mail.log.12.gz:4
/var/log/mail.log.13.gz:5
/var/log/mail.log.14.gz:9
/var/log/mail.log.15.gz:12
/var/log/mail.log.16.gz:8
/var/log/mail.log.17.gz:6
/var/log/mail.log.18.gz:23
/var/log/mail.log.19.gz:17
/var/log/mail.log.20.gz:8
/var/log/mail.log.21.gz:9
/var/log/mail.log.22.gz:5
/var/log/mail.log.23.gz:0
/var/log/mail.log.24.gz:0
/var/log/mail.log.25.gz:5
/var/log/mail.log.26.gz:4
/var/log/mail.log.27.gz:19
/var/log/mail.log.28.gz:7

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Mails to gmail bouncing

[Ralf Hildebrandt]

I have a strange problem with mails to GMAIL.
A user sent out mails to 90 recipients, half of which are @gmail.com,
and those mostly bounced:

Jun 19 09:52:43 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, 
relay=gmail-smtp-in.l.google.COM[173.194.76.26]:25, delay=4.8, 
delays=3.3/0.04/0.62/0.84, dsn=5.5.0, status=bounced (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))
Jun 19 09:52:43 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, 
relay=gmail-smtp-in.l.google.COM[173.194.76.26]:25, delay=4.8, 
delays=3.3/0.04/0.62/0.84, dsn=5.5.0, status=bounced (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))

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)

Other recipients were @yahoo.com, and some even hosted on google
(uniroma1.it):

Jun 19 09:52:42 mail-cvk postfix/smtp[32079]: 45THH93PXyz1Z4Kq: 
to=, relay=ASPMX.L.GOOGLE.COM[173.194.76.27]:25, 
delay=4.7, delays=3.3/0.44/0.42/0.58, dsn=2.0.0, status=sent (250 2.0.0 OK 
1560930762 l7si9891184wrx.266 - gsmtp)
Jun 19 09:52:44 mail-cvk postfix/smtp[32063]: 45THH93PXyz1Z4Kq: 
to=, 
relay=alt1.gmail-smtp-in.l.google.COM[108.177.14.26]:25, delay=6.7, 
delays=3.3/0.04/2.9/0.44, dsn=2.0.0, status=sent (250 2.0.0 OK 1560930764 
q30si13988623lfb.86 - gsmtp)

so the answer 

 "250 2.0.0 OK 1560930762 l7si9891184wrx.266 - gsmtp"

is acceptable, while

 "250 2.1.5 OK w9si551343wmd.47 - gsmtp"

is a protocol error?

https://tools.ietf.org/html/rfc3463
says about the extended code 2.1.5:

2.XXX.XXX   Success
X.1.5   Destination address valid


-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfix benchmark: bug or performance regression ?

[Ralf Hildebrandt]

* Viktor Dukhovni :
> > On Mar 28, 2019, at 12:03 PM, Wietse Venema  wrote:
> > 
> > And thank you for your thorough investigation that helped to narrow
> > down the root cause: under high traffic conditions, LMTP connections
> > are cached but never reused, therefore those idle cached connections
> > are exhausting server resources.
> 
> Yes, thanks.  I was similarly impressed by the OP's detailed report.
> 
> For the record, in case anyone has not read the entire thread, the issue
> is only with LMTP over unix-domain sockets.  LMTP over TCP is not affected.

Ah, excellent. I was already afraid my setup would occasionally suffer
from this effect.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Monitoring amount of smtpd processes

[Ralf Hildebrandt]

> max_idle was the option I was looking for. Thank you.
> 
> I always grepped for something like timeout/daemon/time and I never
> found max_idle. :-)

Lowered here as well...

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Monitoring amount of smtpd processes

[Ralf Hildebrandt]

> It could also be very great to have Postfix like this, showing some
> informations about the connection:
> 
> smtpd [unused/virgin]
> or
> smtpd [, , , ]
> 
> Could be great for analysis and to get a quick overview about what's
> going on on busy servers.

That's a nice idea on systems where this kind of change is possible!

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Could you please explain a warning message

[Ralf Hildebrandt]

* Allen Coates :
> Yesterday I saw the following warning message in my logs:-
> 
> 2018-10-06T14:11:19+01:00 geronimo postfix/postscreen[8194]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 151 ms

Oct  2 02:01:40 mail-cbf postfix/postscreen[23257]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 343 ms
Oct  2 02:03:16 mail-cbf postfix/postscreen[23257]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 155 ms
Oct  3 18:34:07 mail-cbf postfix/postscreen[23257]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 137 ms
Oct  8 11:21:19 mail-cbf postfix/postscreen[65199]: warning: psc_cache_update: 
btree:/var/lib/postfix/postscreen_cache update average delay is 112 ms

Quoting from http://postfix.1071664.n5.nabble.com/psc-cache-update-td10059.html

"It is a bit sluggish. The warning threshold is 100ms. It should not 
take this long to insert one key/pair into the database. Perhaps your 
system's disk is very busy, or you're on a VM slice, or your clock is 
not stable. If this happens frequently you need to find out why."

and

"If this happens often, this means that postscreen cannot handle 
more than 10 SMTP connections per second, or that your system clock 
is jumping (as in: running inside a VM). 

I see the warning once a day on my lightly-loaded server with a 
single 15kRPM disk under an ancient CPU; the timing suggests that 
this happens while some cron job is doing house cleaning. 

I added this check because someone insisted on running postscreen 
on top of an SQL database, and complained that postscreen performance 
was erratic. After I added the warning he stopped complaining."

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postscreen vs. BDAT

[Ralf Hildebrandt]

> It is also possible that the Exim version in question is out of date,
> I recall seeing various bug reports on the Exim-users list about the
> CHUNKING support in Exim, even some security issues.  Don't know whether
> the same symptoms are to be expected from a fully-patched version.

According to the headers smtpgw03.nextwerk.de is running Exim 4.90_1
-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postscreen vs. BDAT

[Ralf Hildebrandt]

* Wietse Venema :
> Ralf Hildebrandt:
> > Today a fellow postmaster (using Exim) called me, they were having problems 
> > sending
> > mail to charite.de. In my log I found:
> > 
> > Sep  3 00:31:18 mail-cbf postfix/postscreen[34943]: CONNECT from 
> > [31.7.179.105]:38256 to [193.175.73.208]:25
> > Sep  3 00:31:24 mail-cbf postfix/tlsproxy[39995]: CONNECT from 
> > [31.7.179.105]:38256
> > Sep  3 00:31:24 mail-cbf postfix/tlsproxy[39995]: Anonymous TLS connection 
> > established from [31.7.179.105]:38256: TLSv1.2 with cipher 
> > ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> > Sep  3 00:31:24 mail-cbf postfix/postscreen[34943]: NOQUEUE: reject: RCPT 
> > from [31.7.179.105]:38256: 450 4.3.2 Service currently unavailable; 
> > from=, to=, proto=ESMTP, 
> > helo=
> > Sep  3 00:31:24 mail-cbf postfix/postscreen[34943]: COMMAND PIPELINING from 
> > [31.7.179.105]:38256 after BDAT: Received: from [213.182.136.75] 
> > (helo=NWH-EX13.nwcloud.loc)\r\n\tby smtpgw03.nextwerk.de with esmtpsa (
> > 
> > After I disabled chunking, mail would flow again.
> > Is this an Exim issue or a flaw in the newly introduced BDAT feature?
> 
> The client is at fault. Postscreen DOES NOT announce PIPELNING support.

Thanks!

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Postscreen vs. BDAT

[Ralf Hildebrandt]

Today a fellow postmaster (using Exim) called me, they were having problems 
sending
mail to charite.de. In my log I found:

Sep  3 00:31:18 mail-cbf postfix/postscreen[34943]: CONNECT from 
[31.7.179.105]:38256 to [193.175.73.208]:25
Sep  3 00:31:24 mail-cbf postfix/tlsproxy[39995]: CONNECT from 
[31.7.179.105]:38256
Sep  3 00:31:24 mail-cbf postfix/tlsproxy[39995]: Anonymous TLS connection 
established from [31.7.179.105]:38256: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Sep  3 00:31:24 mail-cbf postfix/postscreen[34943]: NOQUEUE: reject: RCPT from 
[31.7.179.105]:38256: 450 4.3.2 Service currently unavailable; 
from=, to=, proto=ESMTP, 
helo=
Sep  3 00:31:24 mail-cbf postfix/postscreen[34943]: COMMAND PIPELINING from 
[31.7.179.105]:38256 after BDAT: Received: from [213.182.136.75] 
(helo=NWH-EX13.nwcloud.loc)\r\n\tby smtpgw03.nextwerk.de with esmtpsa (

After I disabled chunking, mail would flow again.
Is this an Exim issue or a flaw in the newly introduced BDAT feature?

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: [OT] Postfwd question

[Ralf Hildebrandt]

* Alex JOST :

> Sat = 6
> Sun = 0
> 
> Maybe postwfd has issues dealing with a range of 6-0. Have you tried 
> specifying both weekdays separately?

Nope, I should try that. 
-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

[OT] Postfwd question

[Ralf Hildebrandt]

I know, I know, it's offtopic since it'S not entirely postfix per se,
but I am at my wit's end here.

I'm trying to implement a (I think) simple ratelimiting feature:

* during our business hours 400 Mails per sender from internat host
* otherwise 100

Some of my limits work, others don't trigger at all:

id=mass_mailing_exceptions
   &
   sender==file:/etc/postfix/mass_mailing_absolute_exceptions
   action=dunno
# these are exceptions for high volume senders. Working OK!

# Arbeitszeit
id=mass_mailing_business_hours
   days=Mon-Fri
   time=09:00:00-17:00:00
   &
  action=rcpt(sender/400/43200/450 4.7.1 Recipient limit exceeded)
# Monday to friday, 9 to 5, working as it should

id=mass_mailing_feierabend
   time=17:00:01-23:59:59
   time=00:00:00-08:59:59
   days=Mon-Fri
   &
   action=rcpt(sender/100/43200/450 4.7.1 Recipient limit exceeded)
# This is also working, but I feel stupid using these two definitions
# for the periods before and after work!!  

# sonst
id=mass_mailing_wochenende
   time=00:00:00-23:59:59
   days=Sat-Sun
   &
   action=rcpt(sender/100/43200/450 4.7.1 Recipient limit exceeded)

# Alas, this is not triggering at all. Dunno why!


-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: PATCH: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Viktor Dukhovni :

> Ralf, please try just this patch against the stock 20180618 snapshot,
> and check as many of the below as you can:
> 
>   * The crashes are gone
>   * DANE is still used when expected
>   * TLS connection re-use happens under sustained load
> 
> We might want to log some sort of connection identifier
> with re-used connections, that would make it possible
> reliably find the original session to check that it
> was authenticated as expected.  This is only useful
> with TLS, so we could perhaps ask the TLS library for
> "channel binding" at session creation, and log it
> (on both ends) with the client logging it again on
> *connection* re-use.  (TLS session resumption is
> a separate matter and would produce a separate
> channel fingerprint on each connection).

I was a bit out of the loop. Currently I'm using 20180624 and the
problems seem to be gone.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: What is postfix telling me to do?

[Ralf Hildebrandt]

* James B. Byrne :

> I am configuring a new Postfix-3.3.0 service to act as one of our
> public MX providers. 

>  Out: 250 2.1.0 Ok
>  In:  RCPT TO:
>  Out: 250 2.1.5 Ok
>  In:  DATA
>  Out: 354 End data with .
>  Out: 451 4.3.0 Error: queue file write error
>  In:  QUIT
>  Out: 221 2.0.0 Bye
> 
> 
> Note that 'In:  RCPT TO:' refers to a
> non-existent mailbox address.

You MX must reject mails for non-existing recipients. Meaning, you
need a list of valid recipients or perform LDAP queries or
call-forwards.

> Mailq displays this:
> 
> 002F8E7E3  1063 Mon Jun 25 22:13:17  double-bou...@mx32.hll.ca
> (delivery temporarily suspended: Server certificate not verified)
>  postmas...@mx32.hll.ca

Check your logs. Probably some TLS/SSL issue (nexthop must use TLS,
but can't)



> The double-bounce address is that used by Postfix for sender
> verification probes.  Why are they still in the queue?  Are they not
> supposed to be discarded?

Yes, but only after they failed PERMANENTLY. "delivery temporarily suspended: 
Server certificate not verified"
indicates a temporary failure.

> To which server does the message '(delivery temporarily suspended:
> Server certificate not verified)' apply?

check 002F8E7E3 in your log. Probably the machine being MX for
mx32.hll.ca unless you're using transport maps

Re: PATCH: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Wietse Venema :
> Ralf Hildebrandt:
> > * Ralf Hildebrandt :
> > 
> > > Error inducing change was introduced between postfix-3.4-20180603 and
> > > postfix-3.4-20180605-nonprod
> > 
> > I also tried postfix-3.4-20180603-nonprod which seems to be working
> > ok! So I guess it must have been between postfix-3.4-20180603-nonprod
> > and postfix-3.4-20180605-nonprod
> 
> Does this reproduce with "posttls-finger -X "?

posttls-finger from the source directory run from /var/spool/postfix gives me:

root@mail:/var/spool/postfix# 
/usr/src/postfix-3.4-20180605-nonprod/bin/posttls-finger -X gmail.com
posttls-finger: Connected to 
gmail-smtp-in.l.google.com[2a00:1450:4013:c03::1a]:25
posttls-finger: < 220 mx.google.com ESMTP j7-v6si170503eda.357 - gsmtp
posttls-finger: > EHLO mail.python.org
posttls-finger: < 250-mx.google.com at your service, [2a03:b0c0:2:d0::71:1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-CHUNKING
posttls-finger: < 250 SMTPUTF8
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: gmail-smtp-in.l.google.com[2a00:1450:4013:c03::1a]:25: 
subject_CN=gmail-smtp-in.l.google.com, issuer_CN=Google Internet Authority 
G3,fingerprint=0C:EE:E6:2E:90:68:56:5A:88:BF:C7:81:B7:D1:A1:3C:EB:2C:B0:30,pkey_fingerprint=64:95:0D:F5:04:A2:FF:66:00:4E:06:AE:F6:37:B5:CF:7F:AE:20:99
posttls-finger: Untrusted TLS connection established to 
gmail-smtp-in.l.google.com[2a00:1450:4013:c03::1a]:25: TLSv1.2 with cipher 
ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
posttls-finger: > EHLO mail.python.org
posttls-finger: < 250-mx.google.com at your service, [2a03:b0c0:2:d0::71:1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-CHUNKING
posttls-finger: < 250 SMTPUTF8
posttls-finger: > QUIT
posttls-finger: warning: lost connection while sending QUIT command

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: PATCH: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Ralf Hildebrandt :

> Error inducing change was introduced between postfix-3.4-20180603 and
> postfix-3.4-20180605-nonprod

I also tried postfix-3.4-20180603-nonprod which seems to be working
ok! So I guess it must have been between postfix-3.4-20180603-nonprod
and postfix-3.4-20180605-nonprod

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: PATCH: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Ralf Hildebrandt :
> > Also released as postfix-3.4-20180618.
> 
> postfix-3.4-20180618. Is crashing for me:
> 
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket: 
> malformed response
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure -- 
> see a previous warning/fatal/panic logfile record for the problem description
> Jun 19 09:39:11 mail postfix/master[6142]: warning: process 
> /usr/lib/postfix/smtp pid 12341 killed by signal 11
> 
> No matter what the setting for smtp_tls_connection_reuse is.
> 
> smtpd -D yields:
> 
> Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
> 0x7f0ee8b8995c in __libc_waitpid (pid=25675, 
> stat_loc=stat_loc@entry=0x7ffd22ba62a0, options=options@entry=0)
> at ../sysdeps/unix/sysv/linux/waitpid.c:31
> (gdb) Continuing.
>   
> Program received signal SIGSEGV, Segmentation fault.
> tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
> "tcp", 
> hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
> 1146int iscname = strcasecmp(hostrr->rname,
> hostrr->qname);

Error inducing change was introduced between postfix-3.4-20180603 and
postfix-3.4-20180605-nonprod

Re: PATCH: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Ralf Hildebrandt :
> > Also released as postfix-3.4-20180618.
> 
> postfix-3.4-20180618. Is crashing for me:
> 
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket: 
> malformed response
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure -- 
> see a previous warning/fatal/panic logfile record for the problem description
> Jun 19 09:39:11 mail postfix/master[6142]: warning: process 
> /usr/lib/postfix/smtp pid 12341 killed by signal 11
> 
> No matter what the setting for smtp_tls_connection_reuse is.
> 
> smtpd -D yields:

Typo, of course I debugged smtp, not smtpd!!!

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: PATCH: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

> Also released as postfix-3.4-20180618.

postfix-3.4-20180618. Is crashing for me:

Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket: 
malformed response
Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure -- 
see a previous warning/fatal/panic logfile record for the problem description
Jun 19 09:39:11 mail postfix/master[6142]: warning: process 
/usr/lib/postfix/smtp pid 12341 killed by signal 11

No matter what the setting for smtp_tls_connection_reuse is.

smtpd -D yields:

Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
0x7f0ee8b8995c in __libc_waitpid (pid=25675, 
stat_loc=stat_loc@entry=0x7ffd22ba62a0, options=options@entry=0)
at ../sysdeps/unix/sysv/linux/waitpid.c:31
(gdb) Continuing.

Program received signal SIGSEGV, Segmentation fault.
tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
"tcp", 
hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
1146int iscname = strcasecmp(hostrr->rname,
hostrr->qname);
(gdb) #0  tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72 "tcp", 
hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
#1  0x558114402add in dane_init (iter=0x558114882378, 
tls=0x55811487e9a0)
at smtp_tls_policy.c:828
#2  policy_create (unused_key=,context=0x558114882378) at 
smtp_tls_policy.c:558
#3  0x7f0ee95307ec in ctable_locate (cache=0x55811487ea80, 
key=0x55811487f900 "gmail.com::25:") at ctable.c:163
#4  0x55811440318a in smtp_tls_policy_cache_query (
why=why@entry=0x558114899bd0, tls=tls@entry=0x5581148823c0, 
iter=iter@entry=0x558114882378) at smtp_tls_policy.c:675
#5  0x5581143fa1e2 in smtp_reuse_session (domain_best_pref=5, 
addr_list=0x7ffd22ba5cc0, state=0x558114882340) at smtp_connect.c:675
#6  smtp_connect_inet (state=0x558114882340, nexthop=, 
def_service=0x55811484ee80 "smtp") at smtp_connect.c:920
#7  0x5581143fb280 in smtp_connect (state=0x558114882340)
at smtp_connect.c:1172
#8  0x5581143f8f3d in deliver_message (request=0x55811487bcd0, 
service=0x7ffd22ba7f8e "smtp") at smtp.c:1040
#9  smtp_service (client_stream=0x558114899890, 
service=0x7ffd22ba7f8e "smtp", argv=) at smtp.c:1072
#10 0x7f0ee9dc478a in single_server_wakeup (fd=fd@entry=17, 
attr=attr@entry=0x0) at single_server.c:304
#11 0x7f0ee9dc49cf in single_server_accept_local (
unused_event=, context=)
at single_server.c:350
#12 0x7f0ee9536b01 in event_loop (delay=) at 
events.c:1186
#13 0x7f0ee9dc5847 in single_server_main (argc=, 
argv=, service=0x5581143f8e65 )
at single_server.c:817
#14 0x5581143f9857 in main (argc=5, argv=0x7ffd22ba6688) at smtp.c:1385
(gdb) 

Re: available: multiple deliveries per TLS-encrypted connection

[Ralf Hildebrandt]

* Wietse Venema :
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. 

Testing here.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfix-3.3.0_1 Can't assign requested address

[Ralf Hildebrandt]

> 84A19B389  1256 Wed Jun 13 16:03:45  byrn...@harte-lyne.ca
> (delivery temporarily suspended: connect to
> inet07.hamilton.harte-lyne.ca[216.185.71.27]:25: Can't assign
> requested address)

...

> smtp_bind_address = 127.0.31.1

That's why. I think. 

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Strange errors in mail.warn log

[Ralf Hildebrandt]

* Mario :

> Mar 18 17:21:25 jessie postfix/proxymap[873]: warning: connect to mysql
> server localhost: Can't connect to local MySQL server through socket
> '/var/run/mysqld/mysqld.sock' (2 "No such file or directory")

a) is the mysql server running?
b) does /var/run/mysqld/mysqld.sock exist?
c) if b) = yes, is your proxymap servince running chrooted? (check master.cf, 
column "chroot")

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfix using all CPU after nightly mail submission

[Ralf Hildebrandt]

> > Jan 15 00:42:42 mailrelay postfix/qmgr[5601]: 8EF0980973: 
> > from=<...@oconee.k12.sc.us>, size=2408, nrcpt=1 (queue 
> > active)^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
> > Jan 15 09:31:40 mailrelay opendkim[668]: OpenDKIM Filter v2.11.0 starting 
> > (args: -x /etc/opendkim.conf)
> 
> What you see as "^@" is how ASCII NUL (the zero byte) is displayed
> by "more", "less", "vi", ...   It appears that the log file has either
> lots of NULs written to it, or perhaps has a "hole" as a result of
> truncation of the log file while it was still being written by the
> syslog daemon.  Perhaps incorrect log rotation...
> 
> As for high CPU, that's a bit hard to explain without further
> information, which is difficult to obtain with a truncated log.
> Postfix does not normally bring systems to their knees, its
> resource limits are specifically designed to avoid that.

I've seen similar issues. Machines executing one job - which either
goes hogging the CPU or using all memory, then either the OOM killer
goes mad or the whole machine panics, leaving the filesystem in an
inconsistent state. Often leaving zeros in the log.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: OpenDKIM on backup MX

[Ralf Hildebrandt]

* Davide Marchi :
> Hello friends,
> On Debian Jessie I would like to enable OpenDKIM on my two Postfix 
> servers.

For signing when sending out mails?
 
> My question is how to behave with the secondary backup server.
> Enable it as on the first and then I copy the key from first to 
> secondary?
> And how I will write DNS txt record that must take the two servers 
> information?

The DNS records merely specify the key material for the SENDER DOMAIN,
servers do not matter.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Postfix doesn't respect 250-SIZE value

[Ralf Hildebrandt]

> Here is my configuration: https://pastebin.com/EKHvEveC

postconf -n
would be more appropriate, I think

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Using a date in a bcc map

[Ralf Hildebrandt]

* @lbutlr :
> [This message bounced because the words "c h a n g e" and "a d d r e s s" 
> were on the same line.]
> 
> I currently have recipient_bcc.pcre:
> 
> if !/backup.*@/
> /^([^+_]*).*@(.*)/   backup+${1}.${2}@localdomain.tld
> endif
> 
> I would like to change 
> this to add a date field 
> to the backup address. 

Try creating the recipient_bcc.pcre using a script, and let the scipt
insert the date.

Nice idea!

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: LDAP related "postconf: warning" with most recent build

[Ralf Hildebrandt]

* Wietse Venema <postfix-users@postfix.org>:
> Ralf Hildebrandt:
> > % postconf -h queue_directory
> >  
> > gives me a lot of LDAP related warnings:
> > 
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > query_filter=(proxyAddresses=smtp:%s)
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > start_tls=yes
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > bind_pw=xxx
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > version=3
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > bind_dn=yyy
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > server_host=10.28.0.31?  10.28.0.32
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > result_attribute=mail
> > postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
> > search_base=dc=laborberlin,dc=intern
> > 
> > mail_version = 3.3-20170730
> 
> Does not reproduce when I create a file with those entries, and use
> it as alias_maps.

Odd:

3.3-20170722 no warnings
3.3-20170728 warnings
3.3-20170729 warnings
3.3-20170730 warnings 

# sh src/postconf/extract_cfg.sh
src/postconf/extract_cfg.sh: line 74: m4: command not found

I installed m4, rebuilt, and the warnings are gone.

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

LDAP related "postconf: warning" with most recent build

[Ralf Hildebrandt]

% postconf -h queue_directory
 
gives me a lot of LDAP related warnings:

postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
query_filter=(proxyAddresses=smtp:%s)
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
start_tls=yes
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
bind_pw=xxx
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
version=3
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
bind_dn=yyy
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
server_host=10.28.0.31?  10.28.0.32
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
result_attribute=mail
postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused parameter: 
search_base=dc=laborberlin,dc=intern

mail_version = 3.3-20170730

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: LDAP: "unused parameter: start_tls=yes"?

[Ralf Hildebrandt]

* Ralf Hildebrandt <r...@sys4.de>:
> postconf complains:
> /usr/sbin/postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused 
> parameter: start_tls=yes
> 
> according to http://www.postfix.org/ldap_table.5.html

postfix-3.3-20170716 is complaining,
postfix-3.3-20170611 is not complaining.

I suspect 

20170617

Cleanup: the postconf command warns about unknown parameter
names in a database configuration file, specified as an
absolute pathname (for example, ldap:/path/to/file). This
code was mostly written in January 2017, and it still is a
partial implementation.  Files: postconf/postconf_dbms.c,
postconf/Makefile.in, postconf/test66.ref.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: smtp_pix_workaround_threshold_time not working correctly?

[Ralf Hildebrandt]

* Ralf Hildebrandt <r...@sys4.de>:
> In my log I found this:
> 
> Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
> 
> According to 
> http://www.electric-spoon.com/doc/postfix/html/postconf.5.html#smtp_pix_workaround_maps
> 
> "By default, the workaround is turned off for mail that is queued for
> less than 500 seconds. In other words, the workaround is normally
> turned off for the first delivery attempt."
> 
> % fgrep 3xDK0Z6RBRz1Z1wy /var/log/mail.log
> 
> Jul 21 07:22:54 mail-cvk postfix/smtpd[5374]: 3xDK0Z6RBRz1Z1wy: 
> client=s-mx14-ht01.charite.de[10.32.37.105]
> ...
> Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
> Jul 21 07:23:10 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: 
> to=<empfaen...@unimed.de>, relay=mail.unimed.de[62.154.176.144]:25, delay=16, 
> delays=15/0/0.06/1.2, dsn=2.0.0, status=sent (250 Ok: queued as B51D41068C5)
> 
> Jul 21 07:23:10 mail-cvk postfix/qmgr[7149]: 3xDK0Z6RBRz1Z1wy: removed
> 
> That's 16s, why were the PIX workarounds triggered anyway?
> 
> Another:
> Jul 21 08:02:48 mail-cvk postfix/smtpd[10518]: 3xDKtc5hRMz1Z2wL: 
> client=s-mx14-ht01.charite.de[10.32.37.105]
> ...
> Jul 21 08:02:52 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: enabling PIX 
> workarounds: disable_esmtp delay_dotcrlf for imh.rsys2.net[12.130.135.43]:25
> Jul 21 08:02:53 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: 
> to=<flightupd...@your.lufthansa-group.com>, 
> relay=imh.rsys2.net[12.130.135.43]:25, delay=6.5, delays=5/0/0.55/0.93, 
> dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 549AF1219F4)
> Jul 21 08:02:53 mail-cvk postfix/qmgr[7149]: 3xDKtc5hRMz1Z2wL: removed
> 
> That's 6s. 
> 
> Is the "PIX state" cached?
> 
> # postconf -n|fgrep pix
> smtp_pix_workarounds = delay_dotcrlf

Changed this just that moment, was set to the default before.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

LDAP: "unused parameter: start_tls=yes"?

[Ralf Hildebrandt]

postconf complains:
/usr/sbin/postconf: warning: ldap:/etc/postfix/laborberlin.com.cf: unused 
parameter: start_tls=yes

according to http://www.postfix.org/ldap_table.5.html

STARTTLS can be turned on with the start_tls parameter:
   start_tls = yes
Both forms require LDAP protocol version 3, which has to be set explicitly with:
   version = 3

I'm using:

=== snip ===
server_host = 10.28.0.31
  10.28.0.32
search_base = dc=laborberlin,dc=intern
version = 3

bind_dn = CN=somecn 
bind_pw = secret

query_filter = (proxyAddresses=smtp:%s)
result_attribute = mail

start_tls = yes
=== snip ===

smtp_pix_workaround_threshold_time not working correctly?

[Ralf Hildebrandt]

In my log I found this:

Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25

According to 
http://www.electric-spoon.com/doc/postfix/html/postconf.5.html#smtp_pix_workaround_maps

"By default, the workaround is turned off for mail that is queued for
less than 500 seconds. In other words, the workaround is normally
turned off for the first delivery attempt."

% fgrep 3xDK0Z6RBRz1Z1wy /var/log/mail.log

Jul 21 07:22:54 mail-cvk postfix/smtpd[5374]: 3xDK0Z6RBRz1Z1wy: 
client=s-mx14-ht01.charite.de[10.32.37.105]
...
Jul 21 07:23:09 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: enabling PIX 
workarounds: disable_esmtp delay_dotcrlf for mail.unimed.de[62.154.176.144]:25
Jul 21 07:23:10 mail-cvk postfix/smtp[7329]: 3xDK0Z6RBRz1Z1wy: 
to=, relay=mail.unimed.de[62.154.176.144]:25, delay=16, 
delays=15/0/0.06/1.2, dsn=2.0.0, status=sent (250 Ok: queued as B51D41068C5)

Jul 21 07:23:10 mail-cvk postfix/qmgr[7149]: 3xDK0Z6RBRz1Z1wy: removed

That's 16s, why were the PIX workarounds triggered anyway?

Another:
Jul 21 08:02:48 mail-cvk postfix/smtpd[10518]: 3xDKtc5hRMz1Z2wL: 
client=s-mx14-ht01.charite.de[10.32.37.105]
...
Jul 21 08:02:52 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: enabling PIX 
workarounds: disable_esmtp delay_dotcrlf for imh.rsys2.net[12.130.135.43]:25
Jul 21 08:02:53 mail-cvk postfix/smtp[8678]: 3xDKtc5hRMz1Z2wL: 
to=, 
relay=imh.rsys2.net[12.130.135.43]:25, delay=6.5, delays=5/0/0.55/0.93, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 549AF1219F4)
Jul 21 08:02:53 mail-cvk postfix/qmgr[7149]: 3xDKtc5hRMz1Z2wL: removed

That's 6s. 

Is the "PIX state" cached?

# postconf -n|fgrep pix
smtp_pix_workarounds = delay_dotcrlf

# postconf -d mail_version
mail_version = 3.2-20170122

Re: postfix uses A record for MX less domains

[Ralf Hildebrandt]

* Mario Theodoridis :
> Hi everyone,
> 
> i'm having a curious issue with our postfix instance.
> 
> It seems it is sending emails to a domain's A record when no MX is found.
> 
> Is that standard?

Yes.

> If so, can i disable this somewhere?

No.

> connect to bikinibottom.com[208.73.211.70]:25: Connection refused
> to=, relay=none, delay=407, 
> delays=407/0.01/0.15/0, dsn=4.4.1, status=deferred (connect to 
> bikinibottom.com[208.73.211.70]:25: Connection refused)

transport_maps:

bikinibottom.com error:This domain does not accept mail

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: how to remove string "[MASSMAIL]" from the subject ?

[Ralf Hildebrandt]

* Ralf Hildebrandt <r...@sys4.de>:
> * Zalezny Niezalezny <zalezny.niezale...@gmail.com>:
> > As I see here header_checks can do it. There is only one problem. This rule
> > searching for a subject with string [MASSMAIL] and replacing complete
> > subject line with word "test".
> > 
> > /^Subject:.*[MASSMAIL].*/ REPLACE Subject: test
> 
> /^Subject:(.*)[MASSMAIL](.*)/ REPLACE Subject: $1$2

Sorry:

/^Subject:(.*)\[MASSMAIL\](.*)/ REPLACE Subject: $1$2

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: how to remove string "[MASSMAIL]" from the subject ?

[Ralf Hildebrandt]

* Zalezny Niezalezny :
> As I see here header_checks can do it. There is only one problem. This rule
> searching for a subject with string [MASSMAIL] and replacing complete
> subject line with word "test".
> 
> /^Subject:.*[MASSMAIL].*/ REPLACE Subject: test

/^Subject:(.*)[MASSMAIL](.*)/ REPLACE Subject: $1$2

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: How do I move messages from a sender to the HOLD queue?

[Ralf Hildebrandt]

* Sean Son :
> Hello all
> 
> We have over a thousand messages from a certain user that are stuck in our
> mail queue. Is there a way to move those messages to the HOLD queue for
> now? I want to move all messages from that specific sender, to the HOLD
> queue.

There's a script for that
https://www.arschkrebs.de/postfix/scripts/delete-from-mailq

In it's current form it DELETES mails from the queue, simply
replace:

postsuper -d -

with:

postsuper -h -

Re: Postfix 20 years ago

[Ralf Hildebrandt]

* Wietse Venema :
> Last month it was 20 years ago that I started writing Postfix code.
> After coming to IBM research in November 1996, I spent most of
> December and January making notes on paper. I knew that writing a
> mail system was more work than any of my prior projects.

I think I used postfix back in '98 (can't remember exactly) to replace
our HP-UX sendmail installations which were being abused by the bad
guys on the internet. Same thing that happened to Matthias Andree.

Thank you, thanks to IBM and now Google!

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Stopping spam.

[Ralf Hildebrandt]

* Mark Van Crombrugge :

> At this point I receive the above e-mail.
> 
> In the e-mail details below, I can find that the message is sent by 
> ironp...@ucr.ac.cr but even adding this e-mail address to the Postfix 
> blacklist has no effect.

Why not block the machine litio.ucr.ac.cr [163.178.174.20] instead? 

> Received: from litio.ucr.ac.cr (litio.ucr.ac.cr [163.178.174.20]) by 
> relay.vliz.be with ESMTP id 4HXbovzmQeqq83KP (version=TLSv1.2 cipher=RC4-SHA 
> bits=128 veri

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Mail delivery problems to outlook.com controlled domains

[Ralf Hildebrandt]

* Jack Raats :
> Hi everyone,
> 
>  
> 
> Please help me!!!
> 
>  
> 
> Since last tuesday my mailservers cann’t deliver email to an outlook.com 
> controlled domain. Before tuesday everything was ok.
> 
> Accoording to microsoft my postfix server doesn’t comply with the several 
> rfc’s describing how to send email.

Care to share the rejection message?

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Ubuntu 16.04lts & ssl unknown states

[Ralf Hildebrandt]

* Florian Piekert :

> Nov  3 08:50:30 blueberry postfix/tlsproxy[8057]: SSL_accept:unknown state

I checked my logs and couldn't find any log entries like the one above.

Hm, I am not using smtp(d)_tls_loglevel=2, but 1.

> smtp_tls_loglevel = 2
> smtpd_tls_loglevel = 2

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Blacklisting googlegroups

[Ralf Hildebrandt]

* Nikolaos Milas :
> On 24/10/2016 5:15 μμ, Fazzina, Angelo wrote:
> 
> > Can't you use REGEX to write a rule to catch them, and then decide what you 
> > want to do with those emails ?
> 
> Would the following be valid?
> 
> smtpd_recipient_restrictions =
>  ...
>  check_sender_access hash:/etc/postfix/blacklisted_senders
>  header_checks pcre:/etc/postfix/blacklisted_maillists
>  ...

No.

header_checks cannot be listed in smtpd_recipient_restrictions

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Moved Postfix to new server; Gmail now silently dropping messages sent from it

[Ralf Hildebrandt]

* Alex Hall :
> I just sent a test message to my work address. The log is below. Following
> that, I'll post postconf -n. Obviously, I've changed the server name to
> just 'server' and our domain to 'domain.com'. After I send this, I'm going
> to enable debug-level logging and see what that tells me, if anything. I'm
> hoping something will jump out from the below outputs, though.
> 
> Sep 21 09:23:06 server postfix/pickup[3473]: 0869E60D29: uid=0 from=
> Sep 21 09:23:06 server24 postfix/cleanup[3501]: 0869E60D29: 
> message-id=<20160921132306.0869e60...@server.domain.com>
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: 
> from=, size=320, nrcpt=1 (queue active)
> Sep 21 09:23:06 server postfix/local[3503]: 0869E60D29: 
> to=, relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, 
> status=sent
> (delivered to command: procmail -a "$EXTENSION")
> Sep 21 09:23:06 server postfix/qmgr[2705]: 0869E60D29: removed

The mail was delivered locally.
Wasn't your issue with gmail?

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: postscreen contantly deferring mail

[Ralf Hildebrandt]

* Wietse Venema :

> > What's odd here, is that the host always makes two parallel TLS
> > connections (you must have some "late" tests enabled to get all
> > the way to STARTTLS), with the first connection logging tempfailed
> > recipients and logging "PASS NEW", and soon after the second seems
> > to just disconnect without logging either.  Don't know what if
> > anything that second connection does to the cached state.
> 
> First the client passes all tests in the session from
> [106.10.151.33]:58305, and postscreen caches that result.
> 
> However, the other session ends without passing deep protocol
> tests, and when that session ends, postscreen caches only the tests
> that were passed in that session, i.e. no deep protocol tests.
> 
> I'll see if it is possible to handle this without keeping too much
> state in postscreen for too much time.

Thanks

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: postscreen contantly deferring mail

[Ralf Hildebrandt]

The complete log for 106.10.151.33:

> Jul 23 03:58:49 mail-cbf postfix/postscreen[36326]: CONNECT from 
> [106.10.151.33]:58305 to [193.175.73.208]:25
> Jul 23 03:58:50 mail-cbf postfix/tlsproxy[56082]: CONNECT from 
> [106.10.151.33]:58305
> Jul 23 03:58:51 mail-cbf postfix/tlsproxy[56082]: Anonymous TLS connection 
> established from [106.10.151.33]:58305: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> Jul 23 03:58:52 mail-cbf postfix/postscreen[36326]: CONNECT from 
> [106.10.151.33]:47500 to [193.175.73.208]:25
> Jul 23 03:58:52 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT 
> from [106.10.151.33]:58305: 450 4.3.2 Service currently unavailable; 
> from=, to=, 
> proto=ESMTP, helo=
> Jul 23 03:58:53 mail-cbf postfix/tlsproxy[56082]: CONNECT from 
> [106.10.151.33]:47500
> Jul 23 03:58:53 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT 
> from [106.10.151.33]:58305: 450 4.3.2 Service currently unavailable; 
> from=, to=, proto=ESMTP, 
> helo=
> Jul 23 03:58:53 mail-cbf postfix/postscreen[36326]: PASS NEW 
> [106.10.151.33]:58305
> Jul 23 03:58:53 mail-cbf postfix/postscreen[36326]: DISCONNECT 
> [106.10.151.33]:58305
> Jul 23 03:58:53 mail-cbf postfix/tlsproxy[56082]: DISCONNECT 
> [106.10.151.33]:58305
> Jul 23 03:58:54 mail-cbf postfix/tlsproxy[56082]: Anonymous TLS connection 
> established from [106.10.151.33]:47500: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> Jul 23 03:58:54 mail-cbf postfix/postscreen[36326]: DISCONNECT 
> [106.10.151.33]:47500
> Jul 23 03:58:54 mail-cbf postfix/tlsproxy[56082]: DISCONNECT 
> [106.10.151.33]:47500
> Jul 23 07:59:55 mail-cbf postfix/postscreen[36326]: CONNECT from 
> [106.10.151.33]:42935 to [193.175.73.208]:25
> Jul 23 07:59:55 mail-cbf postfix/tlsproxy[30940]: CONNECT from 
> [106.10.151.33]:42935
> Jul 23 07:59:56 mail-cbf postfix/tlsproxy[30940]: Anonymous TLS connection 
> established from [106.10.151.33]:42935: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> Jul 23 07:59:57 mail-cbf postfix/postscreen[36326]: CONNECT from 
> [106.10.151.33]:58359 to [193.175.73.208]:25
> Jul 23 07:59:57 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT 
> from [106.10.151.33]:42935: 450 4.3.2 Service currently unavailable; 
> from=, to=, 
> proto=ESMTP, helo=
> Jul 23 07:59:58 mail-cbf postfix/tlsproxy[30940]: CONNECT from 
> [106.10.151.33]:58359
> Jul 23 07:59:58 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT 
> from [106.10.151.33]:42935: 450 4.3.2 Service currently unavailable; 
> from=, to=, proto=ESMTP, 
> helo=
> Jul 23 07:59:59 mail-cbf postfix/tlsproxy[30940]: Anonymous TLS connection 
> established from [106.10.151.33]:58359: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> Jul 23 07:59:59 mail-cbf postfix/postscreen[36326]: PASS NEW 
> [106.10.151.33]:42935
> Jul 23 07:59:59 mail-cbf postfix/postscreen[36326]: DISCONNECT 
> [106.10.151.33]:42935
> Jul 23 07:59:59 mail-cbf postfix/tlsproxy[30940]: DISCONNECT 
> [106.10.151.33]:42935
> Jul 23 08:00:00 mail-cbf postfix/postscreen[36326]: DISCONNECT 
> [106.10.151.33]:58359
> Jul 23 08:00:00 mail-cbf postfix/tlsproxy[30940]: DISCONNECT 
> [106.10.151.33]:58359
> Jul 23 12:00:41 mail-cbf postfix/postscreen[36326]: CONNECT from 
> [106.10.151.33]:60516 to [193.175.73.208]:25
> Jul 23 12:00:42 mail-cbf postfix/tlsproxy[11310]: CONNECT from 
> [106.10.151.33]:60516
> Jul 23 12:00:43 mail-cbf postfix/tlsproxy[11310]: Anonymous TLS connection 
> established from [106.10.151.33]:60516: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> Jul 23 12:00:43 mail-cbf postfix/postscreen[36326]: CONNECT from 
> [106.10.151.33]:58359 to [193.175.73.208]:25
> Jul 23 12:00:43 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT 
> from [106.10.151.33]:60516: 450 4.3.2 Service currently unavailable; 
> from=, to=, 
> proto=ESMTP, helo=
> Jul 23 12:00:44 mail-cbf postfix/tlsproxy[11310]: CONNECT from 
> [106.10.151.33]:58359
> Jul 23 12:00:44 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT 
> from [106.10.151.33]:60516: 450 4.3.2 Service currently unavailable; 
> from=, to=, proto=ESMTP, 
> helo=
> Jul 23 12:00:45 mail-cbf postfix/postscreen[36326]: PASS NEW 
> [106.10.151.33]:60516
> Jul 23 12:00:45 mail-cbf postfix/postscreen[36326]: DISCONNECT 
> [106.10.151.33]:60516
> Jul 23 12:00:45 mail-cbf postfix/tlsproxy[11310]: DISCONNECT 
> [106.10.151.33]:60516
> Jul 23 12:00:45 mail-cbf postfix/tlsproxy[11310]: Anonymous TLS connection 
> established from [106.10.151.33]:58359: TLSv1.2 with cipher 
> ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
> Jul 23 12:00:46 mail-cbf 

postscreen contantly deferring mail

[Ralf Hildebrandt]

>From my log:

Jul 23 03:58:52 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:58305: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=
Jul 23 03:58:53 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:58305: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=

Jul 23 07:59:57 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:42935: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=
Jul 23 07:59:58 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:42935: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=

Jul 23 12:00:43 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:60516: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=
Jul 23 12:00:44 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:60516: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=

Jul 23 16:02:54 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:55805: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=
Jul 23 16:02:55 mail-cbf postfix/postscreen[36326]: NOQUEUE: reject: RCPT from 
[106.10.151.33]:55805: 450 4.3.2 Service currently
unavailable; from=, to=, 
proto=ESMTP, helo=

Why would postscreen repeatedly TEMPFAIL these delivery attempts?

They come from the same IP (106.10.151.33), go to the same two
recipients and are sent from the same sender.

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

* Matthew McGehrin :
> Hello.
> 
> Your assuming that port 25 needs to be open on the local side to send 
> mail. this is not the case. There are two possibilities here.
> 
> 1. A dirty IP was assigned to your server, and that the previous owner 
> had a spam issue.

Give the shortages of ipv4 addresses, this is often the case

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

* li...@lazygranch.com :

> This is probably more of a freebsd question, but it seems to me that Postfix 
> should be hogging (bound) to the mail ports, so if something is sending 
> email, it has to be using Postfix.

No. Sending can be done by other processes as well, since it doesn't
require binding to port 25, but connecting to port 25.
 
> I ‎suppose modifying IPFW to log all mail port activity is also a good idea.

Yes. Ports 25, 143, 110 and the encyrpted equivalents.
 
-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: Spamrl.com RBL problem

[Ralf Hildebrandt]

* Matthew McGehrin :
> Hello.
> 
> I would check your local system to see if you have any rogue perl 
> processes running. These are generally the cause of being blacklisted 
> for a dictionary attack, which implies that a script is running on your 
> local server.
> 
> Generally, you can spot them by the amount of CPU time, and they try to 
> mask the process id.

One could also sniff the traffic (using "iptraf" which generates nice
statistical reports)
-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
   
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein