Re: Can send but not receive

[Tom Browder]

On Mon, Aug 28, 2017 at 08:51 Viktor Dukhovni 
wrote:

>
> For further help, follow up with configuration details as requested by
> others.


The best advice for this dummy (me) was to check the firewall. I still had
a block on port 25 left from an aborted attempt to install Webmin a few
months ago which I forgot about.  I unblocked it and that solved the
current problem.

Thanks for all the advice, I am now getting outgoing mail and I'll probably
be asking for more help later.

Best regards,

-Tom

Re: Lists and spam prevention / use of Reply-To:

[Noel Jones]

On 8/28/2017 3:18 PM, Benny Pedersen wrote:
> Ralph Seichter skrev den 2017-08-28 22:05:
>> usually score with deep negative values in SpamAssassin. You're
>> barking
>> up the wrong tree here. ;-)
> 
> and Reply-To: is safe to remove in smtp_header_checks

Assuming your users neither use Reply-To: nor find it useful.  Some
of my users do.

> 
> since its not default dkim signed
> 
> its not safe to remove in header_checks, if remotes sign it in dkim,
> this could be tracked as spam attempt ?

Reply-To: is a valid header used for valid purposes, occasionally
abused by spammers.  It's doubtful the presence of this header,
signed or not, is much of a spam indicator.   Maybe if the reply-to
address is a also a freemail provider.



  -- Noel Jones

Re: Lists and spam prevention / use of Reply-To:

[Benny Pedersen]

Ralph Seichter skrev den 2017-08-28 22:05:

usually score with deep negative values in SpamAssassin. You're barking
up the wrong tree here. ;-)


and Reply-To: is safe to remove in smtp_header_checks

since its not default dkim signed

its not safe to remove in header_checks, if remotes sign it in dkim, 
this could be tracked as spam attempt ?

Re: Lists and spam prevention / use of Reply-To:

[Ralph Seichter]

On 28.08.17 17:42, Rick van Rein wrote:

> I've been studying SPF, DKIM, DMARC and a bit of ARC. And I've been
> wondering if a list [including this one] could be more friendly by
> using Reply-To: to hold the message sender.

The Postfix mailing list is "friendly" already. It does not break DKIM
since it does neither mess with From nor add junk to Subject or the
message bodies. Besides, all messages on this list contain the correct
List-FOO headers. As for spam, messages on the Postfix mailing list
usually score with deep negative values in SpamAssassin. You're barking
up the wrong tree here. ;-)

-Ralph

Re: Lists and spam prevention / use of Reply-To:

[Benny Pedersen]

Rick van Rein skrev den 2017-08-28 19:09:

Interestingly,

This list is a modest exception -- DKIM should pass through it 
perfectly,

mostly because it does not change the Subject: From: To: or body.

But the question was about soundness of the general Reply-To: idea 
anyway.


i noted that it's possible to get dmarc fail on postfix maillist

its spf none, dkim none, dmarc fail, in my tests, arc is not tested or 
planned to be in use


i have configured opendmarc to not reject dmarc fails here for postfix 
maillist since i like to stay on the list


thanks for testing it works

Re: Lists and spam prevention / use of Reply-To:

[Rick van Rein]

Interestingly,

This list is a modest exception -- DKIM should pass through it perfectly,
mostly because it does not change the Subject: From: To: or body.

But the question was about soundness of the general Reply-To: idea anyway.

-Rick

Re: showing an recipient that doesn't receive the mail

[Darek M.]

An MTA only looks at the envelope To for routing.  You can put anything 
you want in the message To header, so you could rewrite it any way you 
need to.



On 8/28/2017 12:04 PM, Nils wrote:

Hi,

    when composing an email, can I assign the header value "To" in a 
way that it is shown by the email client but ignored by postfix?


    I've created a php-cronjob for a customer, that fetches mails from 
an imap box (mta is postfix), recomposes them and forwards them to a 
list of recipients. Mostly like a mailing list would do. Now the 
customer doesn't want the final recipients to see their own addresses 
in the to-field. Instead he wants the from- and the to-field of the 
mail to seem unchanged. How can I do that without looping?


Is this even possible without touching the postfix configuration? If 
not, how would I configure postfix to make this possible?


Kind regards, Nils

Re: showing an recipient that doesn't receive the mail

[Noel Jones]

On 8/28/2017 11:04 AM, Nils wrote:
> Hi,
> 
>     when composing an email, can I assign the header value "To" in a
> way that it is shown by the email client but ignored by postfix?
> 
>     I've created a php-cronjob for a customer, that fetches mails
> from an imap box (mta is postfix), recomposes them and forwards them
> to a list of recipients. Mostly like a mailing list would do. Now
> the customer doesn't want the final recipients to see their own
> addresses in the to-field. Instead he wants the from- and the
> to-field of the mail to seem unchanged. How can I do that without
> looping?
> 
> Is this even possible without touching the postfix configuration? If
> not, how would I configure postfix to make this possible?
> 
> Kind regards, Nils


Postfix makes delivery decisions based on the envelope recipients,
never based on the To: or From: headers.  So you can put whatever
you please in the To: header.



  -- Noel Jones

Re: postfix log in mysql

[James Reynolds]

You might want to look into something like the Logstash 
(https://www.elastic.co/products/logstash).  

James

> On Aug 27, 2017, at 9:51 PM, Kev  wrote:
> 
> Hi postfixers,
> 
> We have spam filter servers for our down, 5 of them to be exact. we use
> amavisd, bitdefender & clamav for spam and virus filter. 
> 
> we have a self help portal done in php/mysql for users to manage
> whitelist/blacklist etc, now i want to allow users to check there email
> logs to they can find if any wanted email is blocked,
> 
> so the question is, how can i log postfix to a mysql db where i can write
> an interface for users to search for email and see what did the
> blocking, such as rbl, amavis etc ? 
> 
> ive seen some solutions to use syslog in to mysql but i was thinking
> something much simpler where i will still have logs in place even if
> mysql fails.
> 
> rgds
> 
> 

Re: prioritization in qmgr scheduler

[Viktor Dukhovni]

On Mon, Aug 28, 2017 at 05:53:11PM +0300, Deniss wrote:

> > If the destination domain is yours and the senders are remote
> > untrusted clients, then indeed "default_transport" won't do
> > unless you're a backup MX host (in that case it is possible
> > to allow relaying for the domain via "check_recipient_access",
> > and the default transport will find the right primary MX host).
> 
> I have domain + list of emails in the domain.  with relay domains
> recipient's check stops just after foreign domain name found as destination.
> with check_recipient_access full email list scanned to reject foreign
> domain.  Is this correct ?

Indeed relay_recipient_maps validates relay recipients, but with
the "default" address class you'd have to explicitly implement
recipient checks.

main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_relay_restrictions =
check_recipient_access ${indexed}relay-rcpts

smtpd_recipient_restrictions = 
check_recipient_access ${indexed}valid-rcpts
... anti-spam restrictions ...

relay-rcpts:
example.com   OK

valid-rcpts:
us...@example.com DUNNO
us...@example.com DUNNO
...
us...@example.com DUNNO
example.com   REJECT 5.1.1 Recipient address unknown

This may or may not be worth the effort.

> >> 1. change transport using FILTER via check_sender_access in
> >> smtpd_sender_restrictions - fine until there is no other filter action
> > 
> > This would be wrong for multi-recipient email when some recipients
> > are local, or in any case should not be sent to the same destination.
> 
> not the case for relay box

If the relay box sends *ALL* recipients to the same destination,
except for internally-generated email (bounces, postmaster notices)
which are not subject to content_filters, then you may be able to
get away with a sender-based "FILTER" access(5) table entry.

[ Keep in mind that setting "relayhost" may interfere with bounce
  delivery, if the relayhost is an inbound relay only.  The correct
  way to set an inbound relay is either of:

relay_transport = relay:[nomx.example.com]
relay_transport = relay:mx.example.com
]

> >> IMO it may be useful to allow alter transport in
> >> sender_dependent_relayhost_maps as well in future releases of postfix
> > 
> > No, that would not be a good idea, since transport selection needs to
> > be recipient based.
> 
> what is the difference to default_transport
> /sender_dependent_default_transport_maps ?

The 'default' transport does not preempt explicit transport selection,
either by address class or transport table.

> Why relayhost/sender_dependent_relayhost_maps do not work same way - not
> include transport as well ?

I'm afraid you'll have to figure that out over time.

-- 
Viktor.

showing an recipient that doesn't receive the mail

[Nils]

Hi,

    when composing an email, can I assign the header value "To" in a 
way that it is shown by the email client but ignored by postfix?


    I've created a php-cronjob for a customer, that fetches mails from 
an imap box (mta is postfix), recomposes them and forwards them to a 
list of recipients. Mostly like a mailing list would do. Now the 
customer doesn't want the final recipients to see their own addresses in 
the to-field. Instead he wants the from- and the to-field of the mail to 
seem unchanged. How can I do that without looping?


Is this even possible without touching the postfix configuration? If 
not, how would I configure postfix to make this possible?


Kind regards, Nils

Lists and spam prevention / use of Reply-To:

[Rick van Rein]

Hi,

I've been studying SPF, DKIM, DMARC and a bit of ARC.  And I've been
wondering if a list [including this one] could be more friendly by using
Reply-To: to hold the message sender.

These spam-fighting methods have the greatest difficulty with email
forwarding and lists because:

 - changes to message headers usually invalidate a DKIM message
 - bypass routes usually invalidate SPF settings
 - DMARC requires either to hold _and_ the domain to match the From: header

An indirect MTA cannot produce a DKIM message on the originator's
domain, and DMARC demands that to align with the From: header.

An indirect MTA may alter envelope from to make SPF work, but DMARC
additionally requires the envelope sender to align with the From: header.

A way to send email in line with DMARC might be:

 1. stash the original sender in the Reply-To: header
 2. use a From: header with a list address under the list bounce domain
 3. setup SPF in the list bounce domain
 4. this should pass on DMARC, because SPF passes and DKIM fails


I'd like to learn if this approach is considered sound by the list.


Cheers,

Rick van Rein

Re: prioritization in qmgr scheduler

[Deniss]

On 2017.08.28. 17:36, Viktor Dukhovni wrote:
>>> but only when the destination domain is not a "relay" domain or
>>> similar, that is, only if mail for the destination in questin just
>>> goes whereever the MX records point with no transport overrides
>>> beyond (sender_dependent_default_transport_maps) which selects a
>>> sender dependent *default* transport.
>>
>> I'm using permit_auth_destination and it does not play without
>> relay_domains.
> 
> If the destination domain is yours and the senders are remote
> untrusted clients, then indeed "default_transport" won't do
> unless you're a backup MX host (in that case it is possible
> to allow relaying for the domain via "check_recipient_access",
> and the default transport will find the right primary MX host).

I have domain + list of emails in the domain.
with relay_domains recipient's check stops just after foreign domain
name found as destination.
with check_recipient_access full email list scanned to reject foreign
domain.
Is this correct ?

> 
>> well, looks like I found few solutions:
>>
>> 1. change transport using FILTER via check_sender_access in
>> smtpd_sender_restrictions - fine until there is no other filter action
> 
> This would be wrong for multi-recipient email when some recipients
> are local, or in any case should not be sent to the same destination.

not the case for relay box

> 
>> IMO it may be useful to allow alter transport in
>> sender_dependent_relayhost_maps as well in future releases of postfix
> 
> No, that would not be a good idea, since transport selection needs to
> be recipient based.

what is the difference to default_transport
/sender_dependent_default_transport_maps ?

Why relayhost/sender_dependent_relayhost_maps do not work same way - not
include transport as well ?

Re: antispam gateway rejecting unknown mailbox

[Noel Jones]

On 8/27/2017 6:05 PM, joao reis wrote:
> Hi,
> 
> I have a postfix server with antispam milter and policy daemons
> forwarding messages to various distinct remote servers. It works
> very well, all messages for the configured domains are forwarded
> using smtp / lmtp transport to each server.
> 
> My ideia is keep the minimal configuration for each domain: domain
> settings and the transport maps. Today I have this:
> 
> virtual_mailbox_domains = /etc/postfix/virtual_domains # with the
> valid domains
> transport_maps = hash:/etc/postfix/transport # with the domains and
> destination
> 
> The problem is that when I send a message to an inexistent mailbox
> and existent configured domain, the message is forwarded to
> destination server and then the destination server rejects it.
> 
> Is it possible to reject in rcpt to command in the antispam gateway
> without copying all the mailbox table in to it?
> 
> 
> Thanks in advance.
> 
> João Reis.
> 


The best way to solve this is to copy your user list to the gateway
so it knows the valid recipients, then automate the procedure.

If that's not possible, maybe you can use active recipient
verification. Make sure you limit the verification to your own
internal domains.
http://www.postfix.org/ADDRESS_VERIFICATION_README.html



  -- Noel Jones

Re: prioritization in qmgr scheduler

[Viktor Dukhovni]

On Mon, Aug 28, 2017 at 04:46:19PM +0300, Deniss wrote:

> > You could use:
> > 
> > 
> > http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> > 
> > but only when the destination domain is not a "relay" domain or
> > similar, that is, only if mail for the destination in questin just
> > goes whereever the MX records point with no transport overrides
> > beyond (sender_dependent_default_transport_maps) which selects a
> > sender dependent *default* transport.
> 
> I'm using permit_auth_destination and it does not play without
> relay_domains.

If the destination domain is yours and the senders are remote
untrusted clients, then indeed "default_transport" won't do
unless you're a backup MX host (in that case it is possible
to allow relaying for the domain via "check_recipient_access",
and the default transport will find the right primary MX host).

> well, looks like I found few solutions:
> 
> 1. change transport using FILTER via check_sender_access in
> smtpd_sender_restrictions - fine until there is no other filter action

This would be wrong for multi-recipient email when some recipients
are local, or in any case should not be sent to the same destination.

> 2. alter nexthop with sender_dependent_relayhost_maps - require
> additional address on the backend

This has no effect on concurrency limits, but with a different
nexthop you get a new pool of concurrency slots, so if traffic to
that destination is light and the active queue is not full, that
will help avoid queueing behind a other traffic that is sharing a
low-throughput channel.

> As I understand concurrency limits will differ from ones on default
> route in both cases.

Not differ, just be separate.

> IMO it may be useful to allow alter transport in
> sender_dependent_relayhost_maps as well in future releases of postfix

No, that would not be a good idea, since transport selection needs to
be recipient based.

-- 
Viktor.

Re: Can send but not receive

[Viktor Dukhovni]

On Mon, Aug 28, 2017 at 08:06:39AM -0500, Tom Browder wrote:

> There was a temporary problem delivering your message to 
> tbro...@novco1968tbs.com. Gmail will retry for 46 more hours. You'll be 
> notified if the delivery fails permanently.
> 
> Learn more here: https://support.google.com/mail/answer/7720
> 
> The response was:
> 
> The recipient server did not accept our requests to connect. Learn more at 
> https://support.google.com/mail/answer/7720 
> [mail.novco1968tbs.com. 142.54.186.6: generic::failed_precondition: connect 
> error (0): error]

This is a much too long-winded description of the same symptoms you'd
see with "posttls-finger" or "swaks".

$ posttls-finger novco1968tbs.com
posttls-finger: Failed to establish session to novco1968tbs.com via 
mail.novco1968tbs.com: connect to mail.novco1968tbs.com[142.54.186.6]:25: 
Connection refused

[ Google really should do a better job of reporting SMTP delivery
  in a form that won't scare naive users, but still retains sufficient
  technical detail for experts.  I don't think that

  generic::failed_precondition: connect error (0): error

  meets that requirement. ]

You have nothing listening on port 25 on your public IP address.
Perhaps you have the "inet_interfaces = loopback-only" safety net
still enabled.

For further help, follow up with configuration details as requested by others.

-- 
Viktor.

Re: prioritization in qmgr scheduler

[Deniss]

On 2017.08.25. 18:20, Viktor Dukhovni wrote:
> 
> Yes, but ...
> 
>> relay_transport = smtp:backend
> 
> On MX gateway hosts that receive inbound mail, use "relay:..." not
> "smtp:..." for your relay transport, and let outbound mail from
> your system use "smtp".  This reduces contention between inbound
> and outbound traffic, in particular slow outbound mail will not
> delay inbound mail.
> 
>> relay_domains = mydomain.com
>> sender_dependent_relayhost_maps = 
>> inline:{prioritysender.com=smtpfast:backend }
> 
> No, because sender_dependent_relayhost_maps (unsurprisingly) only
> changes the relayhost, not the transport.  If your priority is by
> origin, and not by destination, you may have to use three Postfix
> instances, with low priority traffic shunted to the default slow
> instance, and high priority traffic to the fast instance, with the
> front end instance acting as a switch to separate the two flows.
> 
> Ultimately Postfix transport selection and concurrency limits are
> (correctly) destination based, so to implement sender-dependent
> behaviour you need to split the flow by sender, which can only be
> done by handling off to another MTA (instance) with sender-dependent
> relay settings.
> 
> You could use:
> 
> 
> http://www.postfix.org/postconf.5.html#sender_dependent_default_transport_maps
> 
> but only when the destination domain is not a "relay" domain or
> similar, that is, only if mail for the destination in questin just
> goes whereever the MX records point with no transport overrides
> beyond (sender_dependent_default_transport_maps) which selects a
> sender dependent *default* transport.
> 

I'm using permit_auth_destination and it does not play without
relay_domains.

well, looks like I found few solutions:

1. change transport using FILTER via check_sender_access in
smtpd_sender_restrictions - fine until there is no other filter action
2. alter nexthop with sender_dependent_relayhost_maps - require
additional address on the backend

As I understand concurrency limits will differ from ones on default
route in both cases.

IMO it may be useful to allow alter transport in
sender_dependent_relayhost_maps as well in future releases of postfix

Re: Can send but not receive

[/dev/rob0]

On Mon, Aug 28, 2017 at 01:35:12PM +, Tom Browder wrote:
> On Mon, Aug 28, 2017 at 08:22 Ralph Seichter 
>  wrote: ...
> 
> > Please study http://www.postfix.org/DEBUG_README.html for starters.
> 
> I had studied it and have done up through verbose messages with - v 
> but saw nothing. However, I forgot about the peer setting which is 
> probably why the logs are quiet.

You absolutely DO NOT need verbose logging.  Turn that off.

Logs are quiet because nothing is able to connect to you.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Can send but not receive

[/dev/rob0]

On Mon, Aug 28, 2017 at 08:06:39AM -0500, Tom Browder wrote:
> My remote postfix installation can send but not receive, and I'm 
> sure I have a bad setting somewhere.  When sending to the remote 
> server, from my personal gmail account I finally get a response 
> from gmail as shown in the attached file.
snip

> There was a temporary problem delivering your message to 
> tbro...@novco1968tbs.com. Gmail will retry for 46 more hours. 
> You'll be notified if the delivery fails permanently.

Assuming this address (the @domain part) is correct and not munged, 
there's enough information here to figure out what's wrong.

rob0@harrier:~$ dig novco1968tbs.com. mx +short
10 mail.novco1968tbs.com.
rob0@harrier:~$ telnet $(dig +short mail.novco1968tbs.com) 25
Trying 142.54.186.6...
telnet: connect to address 142.54.186.6: No route to host

Looks like a firewall problem, most likely.  You have to have your 
port 25 open if you wish to receive mail exchange from other sites.

> I can put my main.cf, master.cf in a github gist if there is any
> interest.  My mail logs are not interesting at all, at least to me,
> but I am happy to put one or more of them on github, too.

As has been explained by other posters, no, that is not how this 
mailing list works.  In any case, this does not appear to be a 
Postfix issue, yet.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Can send but not receive

[Tom Browder]

On Mon, Aug 28, 2017 at 08:22 Ralph Seichter 
wrote:
...

> Please study http://www.postfix.org/DEBUG_README.html for starters.


I had studied it and have done up through verbose messages with - v but saw
nothing. However, I forgot about the peer setting which is probably why the
logs are quiet.

Thanks, Ralph!

-Tom

Re: Can send but not receive

[Postfix User]

On Mon, 28 Aug 2017 08:06:39 -0500, Tom Browder stated:

>My remote postfix installation can send but not receive, and I'm sure
>I have a bad setting somewhere.  When sending to the remote server,
>from my personal gmail account I finally get a response from gmail as
>shown in the attached file.
>
>I can put my main.cf, master.cf in a github gist if there is any
>interest.  My mail logs are not interesting at all, at least to me,
>but I am happy to put one or more of them on github, too.

To report problems to Postfix, first read this:
http://www.postfix.com/DEBUG_README.html#mail

Specifically:

Command output from:

"postconf -n". Please do not send your main.cf file, or 1000+ lines of
postconf command output.

"postconf -Mf" (Postfix 2.9 or later).

Better, provide output from the postfinger tool. This can be found at
http://ftp.wl0.org/SOURCES/postfinger.

If the problem is SASL related, consider including the output from the
saslfinger tool. This can be found at
http://postfix.state-of-mind.de/patrick.koetter/saslfinger/.

-- 
Jerry

Re: Can send but not receive

[Ralph Seichter]

On 28.08.17 15:06, Tom Browder wrote:

> I can put my main.cf, master.cf in a github gist if there is any
> interest. My mail logs are not interesting at all, at least to me,
> but I am happy to put one or more of them on github, too.

Please study http://www.postfix.org/DEBUG_README.html for starters.
The information might change your mind about logs (and Github). ;-)

-Ralph

Can send but not receive

[Tom Browder]

My remote postfix installation can send but not receive, and I'm sure
I have a bad setting somewhere.  When sending to the remote server,
from my personal gmail account I finally get a response from gmail as
shown in the attached file.

I can put my main.cf, master.cf in a github gist if there is any
interest.  My mail logs are not interesting at all, at least to me,
but I am happy to put one or more of them on github, too.

Thanks.

-Tom
Delivered-To: tom.brow...@gmail.com
Received: by 10.157.24.16 with SMTP id b16csp1826143ote;
Mon, 28 Aug 2017 05:15:35 -0700 (PDT)
X-Received: by 10.202.72.19 with SMTP id v19mr281412oia.305.1503922535716;
Mon, 28 Aug 2017 05:15:35 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1503922535; cv=none;
d=google.com; s=arc-20160816;
b=OSqPD1aVZ2mDojqko611vj38heJupr1CiAvsAMmSfU4j0eai492jphxsKdHignh6pf
 ICAuyh/73OLsj0/XX1SIhX8g91RgMJ2mYuKo96g13QN1WY2PBTG+ljMWyjfdxKdNVpR2
 qYRmr0U2EL0HL2CLQl2Wg/TzZSkGK+ilWzyfNq3iYm00uMYDtm993ywyV0wdZJ/eAGxd
 5tLNKYb03HdsMalCEGNPETpPF0bik3IjhRC0R5kpdulDzzNSVvPQm+GDpURjJw+vY+En
 gaaQWSGQU4HK3Wk26eo9sYWWCzCyFHSbV4uoAz371+Qmrb9jg0UKktrggpDFZw3L2qVT
 Txbg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 
s=arc-20160816;
h=date:message-id:in-reply-to:references:subject:auto-submitted:to
 :from:dkim-signature:arc-authentication-results;
bh=lKo3JKkl6sSnJQIkz/m7jK/tq33bmeh7BPrajw7ZgEU=;
b=oQuNSKrB9naPrUtg7CjYuyzpffTKkkPfLNige7pstrOzxeSPHKSFfHQP9aC+5oqlgU
 DadMO92J9wqXnZzWFNgPrdXKlvKexYdPcfEPERLi8zko9wCkeF0cmtLJDIfGpTe/msD1
 j3sHcRI45xp3L7zI4lFTt8XZCfQsQ4FayBUIB/78Oh+0PSeOi+Ma86lL/Odj356FEteP
 8/u+xgYFMnHGNrx2oPYVjDDqriiD4/mW3TIxkFoJ/iXryTU3W4jYd6whQAB7Tp9EKRM8
 SbuKYra3I+2nYb7+/D3ldtDlk1E74/odLCuoWe5rzRAVmuEeuUfL6QqgrfB3hYJr+EuI
 wiCw==
ARC-Authentication-Results: i=1; mx.google.com;
   dkim=pass header.i=@googlemail.com header.s=20161025 header.b=t3GpC5C8;
   spf=pass (google.com: best guess record for domain of 
postmas...@mail-oi0-x245.google.com designates 2607:f8b0:4003:c06::245 as 
permitted sender) smtp.helo=mail-oi0-x245.google.com;
   dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) 
header.from=googlemail.com
Return-Path: <>
Received: from mail-oi0-x245.google.com (mail-oi0-x245.google.com. 
[2607:f8b0:4003:c06::245])
by mx.google.com with ESMTPS id s138si3362oih.90.2017.08.28.05.15.35
for 
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 28 Aug 2017 05:15:35 -0700 (PDT)
Received-SPF: pass (google.com: best guess record for domain of 
postmas...@mail-oi0-x245.google.com designates 2607:f8b0:4003:c06::245 as 
permitted sender) client-ip=2607:f8b0:4003:c06::245;
Authentication-Results: mx.google.com;
   dkim=pass header.i=@googlemail.com header.s=20161025 header.b=t3GpC5C8;
   spf=pass (google.com: best guess record for domain of 
postmas...@mail-oi0-x245.google.com designates 2607:f8b0:4003:c06::245 as 
permitted sender) smtp.helo=mail-oi0-x245.google.com;
   dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) 
header.from=googlemail.com
Received: by mail-oi0-x245.google.com with SMTP id y193so1301oie.6
for ; Mon, 28 Aug 2017 05:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlemail.com; s=20161025;
h=from:to:auto-submitted:subject:references:in-reply-to:message-id
 :date;
bh=lKo3JKkl6sSnJQIkz/m7jK/tq33bmeh7BPrajw7ZgEU=;
b=t3GpC5C8hgf8BOAMfCEjNxp02vM1SrXjM5DpwmNGH10u342Na9bKN4pvkwcZWL2+sB
 f4C6toPnjavxiOGqUpswuNFOl6O4Puv6JugjFX2MXpfGNUEG+su/xSkzeLeJ4dTAGueD
 J2wQxbhZ2mnW0eBs2YI2JlgEfSM7A2+SgNMP29ud+E+49KJrCzlS7lyGIChsq+A5Nnqr
 bBab5+ETr9ylIxJxzZMWI5+L+ryzT+nNoA1gERGr/TiC+OPHjGXFdQYq0K2+Mh7pnVm0
 V2eY2p5amChyQguTIhX3FBEqgwPYySahylqg0O6Pl/Eu/oyZ6gxDPr8k6atI6pOwdZ4n
 K09w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:auto-submitted:subject:references
 :in-reply-to:message-id:date;
bh=lKo3JKkl6sSnJQIkz/m7jK/tq33bmeh7BPrajw7ZgEU=;
b=Xiro54qzAIC/jMPQZkqC0pH+VKiBMF7nRxZfNperHc3pZljQwhZYqcON5etscRL7RC
 OuIXvpVhVIeD4uAmfVibBTVJIbtPlPBS3aZMFSWbeBVvwILWcuOSWjVqPljf1y9r51bQ
 ioHDUkUe39DIEmnx8k8ZCUbJqTtphxuvuhKTIHyjQ4X3Ef7mDZuPw3osbyeDUIqgE3L0
 GLwSEaqLIBwldHoRYny9q9fZzBsiIKOvDZVFt6K8ZbEiE8dD1klYud0mHuVx/fG4KvB7
 o1D9bv0J/9PAz4h/Pv3IvAy80z38WWUUE58YCk6ZQs4EYb5V5XQ7OjrsBX17JOa8EaAE
 2r7A==
X-Gm-Message-State: AHYfb5gOAVEkOsfAUPHHUmCfp7g/RL1XNDSjPwXahV3paiQAdXnQr0vc
cMu15J7Cyu37gV3Xgaa97Xy+7zOHxuvpBolD4r+N
X-Received: by 10.202.236.199 with SMTP id k190mr368808oih.160.1503922535616;
Mon, 28 Aug 2017 05:15:35 -0700 (PDT)
Content-Type: multipart/report; boundary="001a1137c0ae8144c40557cf4082"; 

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

[Wietse Venema]

A. Schulze:
> 
> wietse:
> 
> > A. Schulze:
> >> postqueue: panic: vbuf_print: output for '%s' exceeds space 0
> >
> 
> this is pfqgrep:
> 
>$mailq = "/usr/sbin/postqueue -p |"; # added 'strace -f' here
>open(MAILQ, $mailq) or die;
>while () {
>  # read from STDIN
>}
> 
> execve("/usr/sbin/postqueue", ["/usr/sbin/postqueue", "-p"], [/* 52  
> vars */]) = 0
> ...
> chdir("/var/spool/postfix") = 0
> rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTORER|SA_RESTART,  
> 0x7f4c8e917910}, {SIG_DFL, [], 0}, 8) = 0
> getuid()= 0
> socket(PF_FILE, SOCK_STREAM, 0) = 4
> fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
> fcntl(4, F_SETFL, O_RDWR)   = 0
> connect(4, {sa_family=AF_FILE, path="public/showq"}, 110) = 0
> poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
> read(4, "queue_name\0active\0queue_id\0003xdsD"..., 4096) = 149
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "Queue ID- --Size-- ---Ar"..., 218) = 218
> poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
> read(4, "queue_name\0active\0queue_id\0003xgg0"..., 4096) = 1453
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "\n3xgg0L0F7Lz4FLj* 30013 Mon "..., 257) = 257
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
> HERE 1234567890123/ at /usr/sbin/pfqgrep line 158,  chunk 1.
> write(1, "\n3xgfY21WScz4FLZ* 32602 Mon "..., 241) = 241
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "\n3xgWSk0qGbz4FKf* 42628 Mon "..., 257) = 257
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "\n3xgh1z1cT1z4FLr* 76609 Mon "..., 184) = -1 EPIPE (Broken pipe)

Would it be possible to provide a copy of file 3xgh1z1cT1z4FLr (off-list
email, please) so that I can examine this in detail? If not, output from
"postcat -oeq 3xgh1z1cT1z4FLr" will do.

Wietse

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

[Wietse Venema]

A. Schulze:
> 
> wietse:
> 
> > A. Schulze:
> >> postqueue: panic: vbuf_print: output for '%s' exceeds space 0

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

Wietse

> 
> this is pfqgrep:
> 
>$mailq = "/usr/sbin/postqueue -p |"; # added 'strace -f' here
>open(MAILQ, $mailq) or die;
>while () {
>  # read from STDIN
>}
> 
> execve("/usr/sbin/postqueue", ["/usr/sbin/postqueue", "-p"], [/* 52  
> vars */]) = 0
> ...
> chdir("/var/spool/postfix") = 0
> rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTORER|SA_RESTART,  
> 0x7f4c8e917910}, {SIG_DFL, [], 0}, 8) = 0
> getuid()= 0
> socket(PF_FILE, SOCK_STREAM, 0) = 4
> fcntl(4, F_GETFL)   = 0x2 (flags O_RDWR)
> fcntl(4, F_SETFL, O_RDWR)   = 0
> connect(4, {sa_family=AF_FILE, path="public/showq"}, 110) = 0
> poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
> read(4, "queue_name\0active\0queue_id\0003xdsD"..., 4096) = 149
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "Queue ID- --Size-- ---Ar"..., 218) = 218
> poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
> read(4, "queue_name\0active\0queue_id\0003xgg0"..., 4096) = 1453
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "\n3xgg0L0F7Lz4FLj* 30013 Mon "..., 257) = 257
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> Quantifier follows nothing in regex; marked by <-- HERE in m/+ <--  
> HERE 1234567890123/ at /usr/sbin/pfqgrep line 158,  chunk 1.
> write(1, "\n3xgfY21WScz4FLZ* 32602 Mon "..., 241) = 241
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "\n3xgWSk0qGbz4FKf* 42628 Mon "..., 257) = 257
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> write(1, "\n3xgh1z1cT1z4FLr* 76609 Mon "..., 184) = -1 EPIPE (Broken pipe)
> --- SIGPIPE (Broken pipe) @ 0 (0) ---
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
> read(4, "queue_name\0active\0queue_id\0003xgKR"..., 4096) = 4096
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
> read(4, "3xdqXK4q4lz4FLK\0time\0001503639089\0"..., 4096) = 4096
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
> stat("/etc/localtime", {st_mode=S_IFREG|0644, 

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

[A. Schulze]

wietse:


A. Schulze:

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




this is pfqgrep:

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

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

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

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

write(1, "\n3xgfY21WScz4FLZ* 32602 Mon "..., 241) = 241
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(1, "\n3xgWSk0qGbz4FKf* 42628 Mon "..., 257) = 257
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(1, "\n3xgh1z1cT1z4FLr* 76609 Mon "..., 184) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
read(4, "queue_name\0active\0queue_id\0003xgKR"..., 4096) = 4096
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
poll([{fd=4, events=POLLIN}], 1, 360) = 1 ([{fd=4, revents=POLLIN}])
read(4, "3xdqXK4q4lz4FLK\0time\0001503639089\0"..., 4096) = 4096
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
write(2, "postqueue: panic: vbuf_print: ou"..., 62postqueue: panic:  
vbuf_print: output for '%s' exceeds space 0

) = 62
sendto(3, "<18>Aug 28 08:09:02 postfix/post"..., 95, MSG_NOSIGNAL,  
NULL, 0) = 95

rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0