Re: Postfix 3.0 also introduces inline:

[Wietse Venema]

Postfix User:
> Okay, I suppose I don't pay as close attention to release announcements as I
> should. I noticed this is another post recently:
> 
> Postfix 3.0 also introduces inline: tables whose keys and values are stored
> inside main.cf
> 
> I did not see any documentation on the Postfix site for that. Am I just
> blind, or is it documented somewhere there?

Look for the "-m" option in the postconf(1) manpage.

Wietse

Postfix ignoring check_recipient_access

[Neil Smith]

Postfix seems to be ignoring the smtpd_recipient_restrictions = 
check_recipient_access instruction.

I've got a Postfix + Dovecot + Amavis setup and all works fine. I use address 
extensions for the virtual users, so I can "turn off" addresses that have been 
included on spammers' lists.

When an email is "To" one of the turned off addresses, the header_checks 
detects the message and deletes it. 

When an email is only RCPT TO one of the turned off addresses, the 
smtpd_recipient_restrictions = check_recipient_access instruction _should_ (I 
think) tell Postfix to reject the message. But the messages still end up in my 
inbox.

What am I missing here? How do I get check_recipient_access to reject the 
addresses specified in the recipient_checks table?

(Postfix 2.11.0 running on Ubuntu 14.04.3 LTS)

Thanks,

Neil.


Logs and config follows:



/var/log/mail.log (This email should be rejected, but is instead accepted)
-

Nov  8 17:48:07 pserver postfix/smtpd[15446]: connect from mail-
db3on0074.outbound.protection.outlook.com[157.55.234.74]

  
Nov  8 17:48:08 pserver postfix/smtpd[15446]: 0FC981C4: client=mail-
db3on0074.outbound.protection.outlook.com[157.55.234.74]

  
Nov  8 17:48:08 pserver postfix/cleanup[15451]: 0FC981C4: message-
id=<2020849.HWx7EOcjLU@desktop> 


Nov  8 17:48:08 pserver postfix/qmgr[2638]: 0FC981C4: 
from=, size=17198, nrcpt=1 (queue active)  

  
Nov  8 17:48:08 pserver postfix/smtpd[15446]: disconnect from mail-
db3on0074.outbound.protection.outlook.com[157.55.234.74]

   
Nov  8 17:48:10 pserver postfix/smtpd[15456]: connect from 
localhost[127.0.0.1]

   
Nov  8 17:48:10 pserver postfix/smtpd[15456]: 286381DC: 
client=localhost[127.0.0.1] 

  
Nov  8 17:48:10 pserver postfix/cleanup[15451]: 286381DC: message-
id=<2020849.HWx7EOcjLU@desktop> 


Nov  8 17:48:10 pserver postfix/qmgr[2638]: 286381DC: 
from=, size=17633, nrcpt=1 (queue active)  

  
Nov  8 17:48:10 pserver postfix/smtpd[15456]: disconnect from 
localhost[127.0.0.1]


Nov  8 17:48:10 pserver amavis[12838]: (12838-14) Passed CLEAN 
{RelayedInbound}, [157.55.234.74]:56949 [137.108.238.2]  
-> , Queue-ID: 0FC981C4, Message-ID: 
<2020849.HWx7EOcjLU@desktop>, mail_id: I_IbbLvsH2OU, Hits: -1.902, size: 
17184, queued_as: 286381DC, 2017 ms 

  
Nov  8 17:48:10 pserver postfix/smtp[15452]: 0FC981C4: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.2, 
delays=0.16/0.01/0/2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:
[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 286381DC)   



Nov  8 17:48:10 pserver postfix/qmgr[2638]: 0FC981C4: removed   


  
Nov  8 17:48:10 pserver postfix/pipe[15457]: 286381DC: 
to=, relay=dovecot, delay=0.22, delays=0.04/0/0/0.18, 
dsn=2.0.0, status=sent (delivered via dovecot service)  
 
Nov  8 17:48:10 pserver 

Re: Postfix ignoring check_recipient_access

[Koko Wijatmoko]

On Tue, 17 Nov 2015 12:44:12 +
Neil Smith  wrote:

> Postfix seems to be ignoring the smtpd_recipient_restrictions = 
> check_recipient_access instruction.
> 
did you ran postmap for the hash table?
what inside your /etc/postfix/recipient_checks?

Re: rejecting email from specific domains

[Bill Cole]

On 17 Nov 2015, at 10:19, Viktor Dukhovni wrote:


On Tue, Nov 17, 2015 at 10:08:47AM -0500, Bill Cole wrote:


I never investigated if there production users of xyz.  


There are absolutely positively multiple production users of .xyz 
domains.
All evidence I have of this is blatant unequivocal spam and SMTP 
behaviors

that correlate perfectly to conscious, intentional spamming.


Well, Google's new holding company is supposed to be abc.xyz, but I
don't know when or whether they'll be using that for email.

The TLD is very new, and spammers are often "early adopters" of
new TLDs.  But there are also some legitimate users.  One small
example:

https://frida.xyz/

There'll most likely be more legitimate domains using ".xyz" in
the not too distant future.


Yes, and the proliferation of gTLDs (and ccTLDs pimped out as gTLDs like 
.pw) will provide a huge experiment in natural selection over the next 
few years. I have no idea what ham/spam ratio is needed to let heavily 
abused TLDs escape widespread absolute blocking, but I suppose we may 
see that threshold measured. Based on the history and current 
deliverability issues of biz/info/cc/tv domains, I suspect it will take 
many years of substantial valuable ham flow before a TLD that gets 
abused early on is worth trying to use for general email purposes.

Re: Postfix ignoring check_recipient_access

[Neil Smith]

On Tuesday 17 Nov 2015 15:50:22 Viktor Dukhovni wrote:
> On Tue, Nov 17, 2015 at 03:26:55PM +, Neil Smith wrote:
> 
> > On Tuesday 17 Nov 2015 14:43:50 Viktor Dukhovni wrote:
> > 
> > > > smtpd_recipient_restrictions =
> > > > permit_sasl_authenticated
> > > > permit_mynetworks
> > > >   permit_mx_backup
> > > > check_recipient_access hash:/etc/postfix/recipient_checks
> > > >   reject_unauth_destination
> > > 
> > > Notice that cute little "permit_mx_backup" in the restriction
> > > list before "check_recipient_access"?  :-)
> > 
> > If you don't mind, could you please explain why that's a problem? 
> 
> See:
> 
> http://www.postfix.org/postconf.5.html#permit_mx_backup
> 
> Read the description attentively.  

OK, I think I understand. The permit_mx_backup directive is seeing that the 
message is being delivered to someone on this host, so therefore Postfix 
accepts the message before checking the recipient_access.  


> In general, permit_mx_backup is
> a bad idea, instead configure "relay_domains" explicitly and get
> rid of permit_mx_backup.  Don't forget about "relay_recipient_maps".

Thank you. I'll will go off and investigate making that better.

Neil.

Re: Postfix ignoring check_recipient_access

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 03:26:55PM +, Neil Smith wrote:

> On Tuesday 17 Nov 2015 14:43:50 Viktor Dukhovni wrote:
> 
> > > smtpd_recipient_restrictions =
> > >   permit_sasl_authenticated
> > >   permit_mynetworks
> > >   permit_mx_backup
> > >   check_recipient_access hash:/etc/postfix/recipient_checks
> > >   reject_unauth_destination
> > 
> > Notice that cute little "permit_mx_backup" in the restriction
> > list before "check_recipient_access"?  :-)
> 
> If you don't mind, could you please explain why that's a problem? The 
> recipient checks addresses aren't for any of the mxbackup domains. I don't 
> understand how allowing forwarding of mail for backup.com will mean the 
> acceptance of mail for example.com.

See:

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

Read the description attentively.  In general, permit_mx_backup is
a bad idea, instead configure "relay_domains" explicitly and get
rid of permit_mx_backup.  Don't forget about "relay_recipient_maps".

In any case your setting of

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

is also suboptimal, these really should be addresses, not hostnames.

-- 
Viktor.

Re: Puting the Postfix's queue into RAM disk

[Istvan Prosinger]

The problem is tha there is that one VPS and I wanted 2nd opinions about 
my dirty plan.

Thanks

On 2015-11-15 19:03, Matthew McGehrin wrote:

Is it possible to configure a 2nd VPS instance just for
fallback_relay? That way your primary queue is only for deliveries,
and your 2nd instance can handle the bounces.

I was working for an Online Gaming company and we would deliver 1-2
million messages per day, we had 3 active queues, and 1 delayed queue.

On the active queues we would set the fallback_relay to the delayed
queue, thus ensuring only active mail was being sent first.



Istvan Prosinger wrote:



On 13.11.2015 22:53, Phil Stracchino wrote:

On 11/13/15 14:17, Istvan Prosinger wrote:
I got two options that I know of. Signifficantly shortening the 
queue

lifetime, or (not) losing the queue from the RAM disk.
Just trying to measure which is worse (or to hear something new for 
me)


If you lack disk space for the queue, the server instance isn't up to
the job in the first place.

If you really think that keeping the queue in RAM is a better option
than on disk, despite that you probably have far more disk than RAM,
consider using a tmpfs instead of a RAMdisk, with the size of the 
tmpfs
capped at the size RAMdisk you were plannind.  A RAMdisk will use all 
of

that RAM all of the time, whether needed for queued mail or not.  A
tmpfs will consume only as much RAM at any given time as it needs 
right

then.

Postfix 3.0 also introduces inline:

[Postfix User]

Okay, I suppose I don't pay as close attention to release announcements as I
should. I noticed this is another post recently:

Postfix 3.0 also introduces inline: tables whose keys and values are stored
inside main.cf

I did not see any documentation on the Postfix site for that. Am I just
blind, or is it documented somewhere there?

Thanks!

-- 
Jerry

Re: Postfix ignoring check_recipient_access

[Neil Smith]

On Tuesday 17 Nov 2015 09:37:44 Wietse Venema wrote:

> Put check_recipient_access at the BEGINNING of smtpd_recipient_restrictions.

Thank you, that seems to have fixed it. But...


On Tuesday 17 Nov 2015 14:43:50 Viktor Dukhovni wrote:

> > smtpd_recipient_restrictions =
> > permit_sasl_authenticated
> > permit_mynetworks
> >   permit_mx_backup
> > check_recipient_access hash:/etc/postfix/recipient_checks
> >   reject_unauth_destination
> 
> Notice that cute little "permit_mx_backup" in the restriction
> list before "check_recipient_access"?  :-)

If you don't mind, could you please explain why that's a problem? The 
recipient checks addresses aren't for any of the mxbackup domains. I don't 
understand how allowing forwarding of mail for backup.com will mean the 
acceptance of mail for example.com.

Thanks,

Neil.

Re: rejecting email from specific domains

[Bill Cole]

On 17 Nov 2015, at 1:48, yahoogro...@lazygranch.xyz wrote:

FWIW, I keep an xyz tld for test purposes. Point dot com to production 
and dot xyz for test. Yes I know there are ways to do this with a 
subdomain, but dot xyz is really cheap.


While a subdomain (or ad hoc .local with your DNS authoritative, if you 
keep your tests local) is entirely free.




I never investigated if there production users of xyz.  


There are absolutely positively multiple production users of .xyz 
domains. All evidence I have of this is blatant unequivocal spam and 
SMTP behaviors that correlate perfectly to conscious, intentional 
spamming.


That's not to say that it is impossible to use a .xyz domain for 
non-evil purposes but the fact that such domains have been made very 
cheap makes it more likely that spammers will find them useful as 
disposable domains. That already seems to be happening. It is 
unfortunate that some TLDs correlate so strongly to spam, but the fact 
that they do makes it reasonable to treat their use as an indication of 
spam.

Re: rejecting email from specific domains

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 10:08:47AM -0500, Bill Cole wrote:

> >I never investigated if there production users of xyz.  
> 
> There are absolutely positively multiple production users of .xyz domains.
> All evidence I have of this is blatant unequivocal spam and SMTP behaviors
> that correlate perfectly to conscious, intentional spamming.

Well, Google's new holding company is supposed to be abc.xyz, but I
don't know when or whether they'll be using that for email.

The TLD is very new, and spammers are often "early adopters" of
new TLDs.  But there are also some legitimate users.  One small
example:

https://frida.xyz/

There'll most likely be more legitimate domains using ".xyz" in
the not too distant future.

-- 
Viktor.

Re: Postfix ignoring check_recipient_access

[Neil Smith]

On Tuesday 17 Nov 2015 20:50:32 Koko Wijatmoko wrote:
> On Tue, 17 Nov 2015 12:44:12 +
> Neil Smith  wrote:
> 
> > Postfix seems to be ignoring the smtpd_recipient_restrictions = 
> > check_recipient_access instruction.
> > 
> did you ran postmap for the hash table?

Yes, several times, and restarted postfix afterwards.

> what inside your /etc/postfix/recipient_checks?

That was at the bottom of the message:



/etc/postfix/recipient_checks
-

# Reject messages with these recipient addresses
user.bann...@example.com REJECT
user.ban...@example.com REJECT
user.bann...@example.com REJECT
user.bann...@example.com REJECT
person.ban...@example.com REJECT


Testing the map:


root@pserver:/etc/postfix# postmap -q user.va...@example.com 
hash:/etc/postfix/recipient_checks
root@pserver:/etc/postfix# postmap -q user.ban...@example.com 
hash:/etc/postfix/recipient_checks
REJECT

Re: Postfix ignoring check_recipient_access

[Wietse Venema]

Neil Smith:
> When an email is only RCPT TO one of the turned off addresses, the
> smtpd_recipient_restrictions = check_recipient_access instruction
> _should_ (I think) tell Postfix to reject the message. But the
> messages still end up in my inbox.
...
> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks
> permit_mx_backup check_recipient_access hash:/etc/postfix/recipient_checks
> reject_unauth_destination

Put check_recipient_access at the BEGINNING of smtpd_recipient_restrictions.

Wietse

Re: Postfix ignoring check_recipient_access

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 12:44:12PM +, Neil Smith wrote:

> Postfix seems to be ignoring the smtpd_recipient_restrictions = 
> check_recipient_access instruction.

Yes, "seems".  Postfix does not ignore its configuration.  It does
exactly what it is configured to do.  You really should choose a
better problem description.

Nov  8 17:48:07 pserver postfix/smtpd[15446]: connect from 
mail-db3on0074.outbound.protection.outlook.com[157.55.234.74]
Nov  8 17:48:08 pserver postfix/smtpd[15446]: 0FC981C4: 
client=mail-db3on0074.outbound.protection.outlook.com[157.55.234.74]
Nov  8 17:48:08 pserver postfix/cleanup[15451]: 0FC981C4: 
message-id=<2020849.HWx7EOcjLU@desktop>
Nov  8 17:48:08 pserver postfix/qmgr[2638]: 0FC981C4: 
from=, size=17198, nrcpt=1 (queue active)
Nov  8 17:48:08 pserver postfix/smtpd[15446]: disconnect from 
mail-db3on0074.outbound.protection.outlook.com[157.55.234.74]
Nov  8 17:48:10 pserver postfix/smtp[15452]: 0FC981C4: 
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=2.2, 
delays=0.16/0.01/0/2, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp: 
[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 286381DC)
Nov  8 17:48:10 pserver postfix/qmgr[2638]: 0FC981C4: removed

> root@pserver:/etc/postfix# postconf -nf
> mydestination = $myhostname localhost.$mydomain localhost
> mydomain = example.org
> myhostname = mail.$mydomain
> mynetworks = 127.0.0.0/8, 192.168.1.0/24
> myorigin = $mydomain
> permit_mx_backup_networks = backup.com backup2.com
> proxy_interfaces = 101.11.22.33
> recipient_delimiter = .
> smtpd_recipient_restrictions =
>   permit_sasl_authenticated
>   permit_mynetworks
>   permit_mx_backup
>   check_recipient_access hash:/etc/postfix/recipient_checks
>   reject_unauth_destination

Notice that cute little "permit_mx_backup" in the restriction
list before "check_recipient_access"?  :-)

> 
> /etc/postfix/recipient_checks
> -
> 
> # Reject messages with these recipient addresses
> user.bann...@example.com REJECT
> user.ban...@example.com REJECT
> user.bann...@example.com REJECT
> user.bann...@example.com REJECT
> person.ban...@example.com REJECT

-- 
Viktor.

Re: Postfix ignoring check_recipient_access

[Koko Wijatmoko]

On Tue, 17 Nov 2015 13:56:01 +
Neil Smith  wrote:

> > did you ran postmap for the hash table?
> 
> Yes, several times, and restarted postfix afterwards.
> 
is the file permission allow postfix to read it?

Re: Postfix ignoring check_recipient_access

[Neil Smith]

On Tuesday 17 Nov 2015 21:04:00 Koko Wijatmoko wrote:
> On Tue, 17 Nov 2015 13:56:01 +
> Neil Smith  wrote:
> 
> > > did you ran postmap for the hash table?
> > 
> > Yes, several times, and restarted postfix afterwards.
> > 
> is the file permission allow postfix to read it?

Yes.

root@pserver:/etc/postfix# ls -lah
total 204K
drwxr-xr-x   3 root root 4.0K Oct  9 09:12 .
drwxr-xr-x 140 root root  12K Nov 17 01:31 ..
-rw-r--r--   1 root root  274 Sep 23  2012 dynamicmaps.cf
-rw-r--r--   1 root root 2.4K Oct  7 17:11 header_checks
-rw-r--r--   1 root root 3.4K Aug 24 11:58 main.cf
-rw-r--r--   1 root root 6.7K Sep 24  2012 master.cf
-rw-r--r--   1 root root  20K Feb  5  2015 postfix-files
-rwxr-xr-x   1 root root 8.7K Feb  5  2015 postfix-script
-rwxr-xr-x   1 root root  28K Feb  5  2015 post-install
-rw-r--r--   1 root root  475 Oct  7 17:25 recipient_checks
-rw-r--r--   1 root root  12K Oct  7 17:25 recipient_checks.db
drwxr-xr-x   2 root root 4.0K Jul 30  2012 sasl
-rw-r--r--   1 root root  640 May 27  2014 valiases
-rw-r--r--   1 root root  12K May 27  2014 valiases.db
-rw-r--r--   1 root root   42 Sep 23  2012 vhosts
-rw-r--r--   1 root root  178 Sep 24  2012 vmaps
-rw-r--r--   1 root root  12K Sep 24  2012 vmaps.db

Re: Postfix 3.0 also introduces inline:

[Christian Kivalo]

On 2015-11-17 12:08, Postfix User wrote:
Okay, I suppose I don't pay as close attention to release announcements 
as I

should. I noticed this is another post recently:

Postfix 3.0 also introduces inline: tables whose keys and values are 
stored

inside main.cf

I did not see any documentation on the Postfix site for that. Am I just
blind, or is it documented somewhere there?


First try: http://www.postfix.org/DATABASE_README.html#types


Thanks!


- christian

Untrusted TLS connection established headache

[Istvan Prosinger]

Hi,

I'm trying to install the signed STARTSSL certificates to Postfix, but 
I'm getting this entry whatever I do:


Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection 
established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)


I'm out of ideas, starting experimenting with certs, and that won't lead 
me to understanding the problem. Here's the TLS config:


[root@knox certs]# postconf -n | grep tls
smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
smtp_tls_CApath = /etc/ssl/certs/
smtp_tls_loglevel = 1
smtp_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_use_tls = yes


BTW, when I do a test with
http://checktls.com/

(try ist...@prosinger.net) - I get all "green"/

Best Regards,
Istvan

socket: malformed response

[Vicki Brown]

I got my SpamAssassin content filter working, using recommendations and script 
code (modified) from http://www.akadia.com/services/postfix_spamassassin.html 
.

Added to master.cf

smtp  inet  n   -   n   -   -   smtpd
-o content_filter=spamchk:dummy

...

spamchk   unix  -   n   n   -   10  pipe
   flags=Rq user=mailman argv=/usr/local/bin/spamchk
   ${sender} ${recipient}


No changes to main.cf.

Tested. Installed. Checked. It was working from approximately 20:15pm yesterday 
until 02:35am today.  

Log sections looked like this when it was working:

Nov 17 02:35:37 g3po postfix/qmgr[70628]: 91D742F5FFD8: 
from=<...@googlegroups.com>, size=7252, nrcpt=1 (queue active)
Nov 17 02:35:37 g3po postfix/smtpd[74671]: disconnect from 
mail-qk0-f185.google.com[209.85.220.185]
Nov 17 02:35:37 g3po spamd[70257]: spamd: connection from 127.0.0.1 
[127.0.0.1]:62946 to port 783, fd 6
Nov 17 02:35:38 g3po spamd[70257]: spamd: setuid to _mailman succeeded
Nov 17 02:35:38 g3po spamd[70257]: spamd: processing message 
<...@googlegroups.com> for _mailman:78
Nov 17 02:35:39 g3po spamd[70257]: spamd: clean message (-0.8/8.0) for 
_mailman:78 in 1.4 seconds, 7184 bytes.
Nov 17 02:35:39 g3po spamd[70257]: spamd: result: . 0 - 
DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS
 
scantime=1.4,size=7184,user=_mailman,uid=78,required_score=8.0,rhost=127.0.0.1,raddr=127.0.0.1,rport=62946,mid=<...googlegroups.com>,autolearn=disabled
Nov 17 02:35:39 g3po postfix/pickup[74405]: DB1842F5FFDB: uid=78 
from=<...@googlegroups.com>
Nov 17 02:35:39 g3po postfix/pipe[74842]: 91D742F5FFD8: to=<...@cfcl.com>, 
relay=spamchk, delay=2.9, delays=0.85/0.01/0/2.1, dsn=2.0.0, status=sent 
(delivered via spamchk service)
Nov 17 02:35:39 g3po postfix/qmgr[70628]: 91D742F5FFD8: removed
Nov 17 02:35:39 g3po postfix/cleanup[74841]: DB1842F5FFDB: 
message-id=...@googlegroups.com>
Nov 17 02:35:39 g3po postfix/qmgr[70628]: DB1842F5FFDB: 
from=<...@googlegroups.com>, size=7712, nrcpt=1 (queue active)
Nov 17 02:35:40 g3po postfix/smtp[74836]: DB1842F5FFDB: to=<...@cfcl.com>, 
relay=192.168.1.212[192.168.1.212]:25, delay=0.29, delays=0.04/0/0.16/0.09, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as C71C93EC722)
Nov 17 02:35:40 g3po postfix/qmgr[70628]: DB1842F5FFDB: removed
Nov 17 02:35:39 g3po spamd[70255]: prefork: child states: II


Then it crashed.

/var/log/mail.log shows

Nov 17 02:38:29 g3po postfix/qmgr[70628]: warning: private/spamchk socket: 
malformed response
Nov 17 02:38:29 g3po postfix/qmgr[70628]: warning: transport spamchk failure -- 
see a previous warning/fatal/panic logfile record for the problem description
Nov 17 02:38:29 g3po postfix/master[69788]: warning: process 
/usr/libexec/postfix/pipe pid 74861 exit status 1
Nov 17 02:38:29 g3po postfix/master[69788]: warning: /usr/libexec/postfix/pipe: 
bad command startup -- throttling


SpamAssassin's spamd is still running.
A test (pushing a simple test message through the spamchk script) works as it 
did last night.

I'm guessing... that the log message indicates that the spamchk script had an 
exit status of 1. But there's no indication of why. Is that a "malformed 
response"?

Once the "malformed response" warning started, that's all I got until I turned 
everything off again this morning.

Is there anything I can do to troubleshoot? 


-- Vicki
  cfcl.com/vlb
  

Re: socket: malformed response

[Wietse Venema]

Vicki Brown:
> Log sections looked like this when it was working:
> 
> Nov 17 02:35:37 g3po postfix/qmgr[70628]: 91D742F5FFD8: 
> from=<...@googlegroups.com>, size=7252, nrcpt=1 (queue active)
...
> 
> Then it crashed.
>
> /var/log/mail.log shows
> 
> Nov 17 02:38:29 g3po postfix/qmgr[70628]: warning: private/spamchk socket: 
> malformed response
> Nov 17 02:38:29 g3po postfix/qmgr[70628]: warning: transport spamchk failure 
> -- see a previous warning/fatal/panic logfile record for the problem 
> description
> Nov 17 02:38:29 g3po postfix/master[69788]: warning: process 
> /usr/libexec/postfix/pipe pid 74861 exit status 1

You're still running the same qmgr daemon process, so it has not crashed.

However the pipe daemon that you configured for the spamchk service
is terminating with a fatal error (exit status 1).

The description of the problem was logged by process 74861.

Some Linux distros unhelpfully log different messages to different
files, so you may have to look in more than one place.

Wietse

Re: Untrusted TLS connection established headache

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 08:02:35PM +0100, Istvan Prosinger wrote:

> I'm trying to install the signed STARTSSL certificates to Postfix, but I'm
> getting this entry whatever I do:
> 
> Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection
> established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 with
> cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

These are logs from your local Postfix SMTP client that sends mail
to remote domains.

Well, you can't replace Google's certificates unless you're
administering Google's servers.  Perhaps you mean that you're trying
to install trust-anchor certificates (that is, certificate authority
certificates, not server certificates).

> [root@knox certs]# postconf -n | grep tls
> smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> smtp_tls_CApath = /etc/ssl/certs/
> smtp_tls_loglevel = 1
> smtp_tls_security_level = may

With opportunistic TLS ("may") certificates are never verified,
and so are never "Trusted".

> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
> smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key

Enabling client certificates is generally a bad idea.  Is remote
SMTP server expecting you to use these to authenticate yourself
for mail submission?

> BTW, when I do a test with
> http://checktls.com/
> 
> (try ist...@prosinger.net) - I get all "green"/

That tests your Postfix SMTP server that receives mail from
remote domains.  Don't confuse the two services.

-- 
Viktor.

Re: socket: malformed response

[Bill Cole]

On 17 Nov 2015, at 18:22, Vicki Brown wrote:


Is there anything I can do to troubleshoot?


Enhance that script to log its failures & capture the stderr of what it 
calls rather than just tossing back to Postfix.

Re: Untrusted TLS connection established headache

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 07:14:21PM +, Viktor Dukhovni wrote:

> > smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> > smtp_tls_CApath = /etc/ssl/certs/
> > smtp_tls_loglevel = 1
> > smtp_tls_security_level = may
> 
> With opportunistic TLS ("may") certificates are never verified,
> and so are never "Trusted".
> 
> > smtpd_tls_auth_only = yes
> > smtpd_tls_cert_file = /etc/ssl/certs/prosinger_new_bundle.crt
> > smtpd_tls_key_file = /etc/ssl/certs/prosinger_new.key
> 
> Enabling client certificates is generally a bad idea.  Is remote
> SMTP server expecting you to use these to authenticate yourself
> for mail submission?

Note, that the comment was related to your client logs, not
the configuration above it, those are server certificates.

-- 
Viktor.

Re: Untrusted TLS connection established headache

[Bill Cole]

On 17 Nov 2015, at 14:02, Istvan Prosinger wrote:


Hi,

I'm trying to install the signed STARTSSL certificates to Postfix, but 
I'm getting this entry whatever I do:


Nov 17 18:41:39 knox postfix/smtp[32153]: Untrusted TLS connection 
established to gmail-smtp-in.l.google.com[74.125.133.26]:25: TLSv1.2 
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)


NOTE 1: This is logged by postfix/smtp (the sending client) NOT 
postfix/smtpd (the receiving server) so no Postfix setting that starts 
with 'smtpd' is involved.


NOTE 2: This is *probably* not a problem. It only means that your smtp 
process can't verify the certificates being used by Google. If that's 
really Google  It might be someone hijacking your port 25 
connections to Google. However, if someone is able to do that well 
enough that you are making untrusted TLS connections, you won't fix it 
short of requiring verified TLS encryption all connections, which is not 
a working config for a mail server that talks to the likes of Google.


I'm out of ideas, starting experimenting with certs, and that won't 
lead me to understanding the problem. Here's the TLS config:


[root@knox certs]# postconf -n | grep tls
smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
smtp_tls_CApath = /etc/ssl/certs/


That's likely to be wrong. smtp_tls_CApath needs to be more than just a 
directory where there are some CA certs. Read the docs (man 5 postconf). 
Either unset that parameter, figure out where you have a correctly 
populated CA directory, or create such a directory. If you have the smtp 
service in a chroot jail (see master.cf) the CApath needs to be relative 
to that jail.



smtp_tls_loglevel = 1


Switch that to 2 to see the details of the verification failure. Don't 
leave it at 2 for normal use.


[...]

BTW, when I do a test with
http://checktls.com/


Irrelevant: that checks your smtpd. This is NOT smtpd, it is smtp. Those 
are two completely different programs, both parts of Postfix but 
otherwise not related to each other in any way.


One thing to try to find whether the problem is  due to your system's 
default CA configuration:


 openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

That sets up a SMTP STARTTLS session with one of Google's inbound 
servers. It will show you the certs and verification details. (Type 
'quit' to terminate the SMTP session and exit at the end)


If s_client reports "Verify return code: 0 (ok)" near the end of the 
setup, you should be able to get Postfix's smtp program to verify its 
connections as well by getting Postfix to use the same CA collection as 
the openssl tool is using.


If s_client doesn't report "Verify return code: 0 (ok)" then earlier in 
its output it will show the full CA chain and where verification broke.


For example, here's my run of that, with the middle part of the output 
snipped out for clarity:


# openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp
CONNECTED(0003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = 
mx.google.com

verify return:1
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
[...]
0080 - 41 8d c0 f7 38 67 b3 8f-19 3b 31 df 6b da 61 ea   
A...8g...;1.k.a.
0090 - 1c f6 57 5c 9f 75 30 48-a2 4d 27 b7 0e 48 57 12   
..W\.u0H.M'..HW.

00a0 - e8 68 58 90   .hX.

Start Time: 1447818970
Timeout   : 300 (sec)
Verify return code: 0 (ok)
---
250 SMTPUTF8
quit
221 2.0.0 closing connection w124si854343ywe.389 - gsmtp
read:errno=0

Re: socket: malformed response

[Vicki Brown]

When I said "crashed" I was referring to the spamchk script, which, once it 
gave an error, continued to do so for the next 8 hours.

> The description of the problem was logged by process 74861.

Yes, I did note that I saw that. (But it makes no sense to repeat over and 
over; it's a call to sendmail. I'm trying to understand wy sendmail would 
suddenly stp accepting mail at 02:38.)

>Enhance that script to log its failures & capture the stderr of what it calls 
>rather than just tossing back to Postfix.

yeah... :-(

> On Nov 17, 2015, at 16:16, Wietse Venema  wrote:
> 
> Vicki Brown:
>> Log sections looked like this when it was working:
>> 
>> Nov 17 02:35:37 g3po postfix/qmgr[70628]: 91D742F5FFD8: 
>> from=<...@googlegroups.com>, size=7252, nrcpt=1 (queue active)
> ...
>> 
>> Then it crashed.
>> 
>> /var/log/mail.log shows
>> 
>> Nov 17 02:38:29 g3po postfix/qmgr[70628]: warning: private/spamchk socket: 
>> malformed response
>> Nov 17 02:38:29 g3po postfix/qmgr[70628]: warning: transport spamchk failure 
>> -- see a previous warning/fatal/panic logfile record for the problem 
>> description
>> Nov 17 02:38:29 g3po postfix/master[69788]: warning: process 
>> /usr/libexec/postfix/pipe pid 74861 exit status 1
> 
> You're still running the same qmgr daemon process, so it has not crashed.
> 
> However the pipe daemon that you configured for the spamchk service
> is terminating with a fatal error (exit status 1).
> 
> The description of the problem was logged by process 74861.
> 
> Some Linux distros unhelpfully log different messages to different
> files, so you may have to look in more than one place.
> 
>   Wietse
> 

Re: Untrusted TLS connection established headache

[Viktor Dukhovni]

On Tue, Nov 17, 2015 at 10:58:13PM -0500, Bill Cole wrote:

> >[root@knox certs]# postconf -n | grep tls
> >smtp_tls_CAfile = /etc/ssl/certs/startssl-ca-bundle.pem
> >smtp_tls_CApath = /etc/ssl/certs/
> 
> That's likely to be wrong. smtp_tls_CApath needs to be more than just a
> directory where there are some CA certs.

On many a Debian system, /etc/ssl/certs is automatically c_rehash'ed
by the Debian package that manages trusted CAs.  So it could well
be right.  Of course chroot voids the warranty.

> >smtp_tls_loglevel = 1
> 
> Switch that to 2 to see the details of the verification failure. Don't leave
> it at 2 for normal use.

No need.  That'll just make things more confusing.  With "may" the
peer is *never* "Trusted".

> One thing to try to find whether the problem is  due to your system's
> default CA configuration:

There is no problem.

-- 
Viktor.

Re: Static WARN action without an (external) access-map in i.e. restriction_class possible?

[Christian Rohmann]

On 11/16/2015 04:54 PM, Wietse Venema wrote:
> With Postfix 3.0 or later:
> 
>... check_client_access static:{warn text...} ...
> 
> Older Postfix releases require that the lookup result is stored
> outside main.cf.
> 
> (Postfix 3.0 also introduces inline: tables whose keys and values
> are stored inside main.cf).

You seem to be gifted with premonition ;-)


Thanks Wietse.

RE: Disable spooling

[L . P . H . van Belle]

> -Oorspronkelijk bericht-
> Van: pa...@matos-sorge.com [mailto:owner-postfix-us...@postfix.org] Namens
> Paulo Matos
> Verzonden: maandag 16 november 2015 21:14
> Aan: L.P.H. van Belle; postfix users
> Onderwerp: Re: Disable spooling
> 
> 
> 
> On 09/11/15 16:43, L.P.H. van Belle wrote:
> >
> >> -Oorspronkelijk bericht-
> >> Van: njo...@megan.vbhcs.org [mailto:owner-postfix-us...@postfix.org]
> >> Namens Noel Jones
> >> Verzonden: maandag 9 november 2015 16:05
> >> Aan: postfix-users@postfix.org
> >> Onderwerp: Re: Disable spooling
> >>
> >> On 11/9/2015 3:46 AM, Paulo Matos wrote:
> >>> Hi,
> >>>
> >>> I have configured postfix with virtual users and virtual domains so I
> >>> have it configured to serve two domains AAA.com and BBB.com. However,
> >>> the machine hostname
> >>> is centauri (none of the hostname its serving). Reverse DNS is enabled
> >>> to one of the domains. I think that as a result of this setup I am
> >>> getting a good chunk of my emails blocked by google with the following
> >>> message:
> >>>
> >>> 
> >>> Reporting-MTA: dns; centauri
> >>> X-Postfix-Queue-ID: D8B6D22FD3
> >>> X-Postfix-Sender: rfc822; pa...@matos-sorge.com
> >>> Arrival-Date: Thu,  5 Nov 2015 10:40:10 + (GMT)
> >>>
> >>> Final-Recipient: rfc822; x...@yyy.com
> >>> Original-Recipient: rfc822; x...@yyy.com
> >>> Action: failed
> >>> Status: 5.7.1
> >>> Remote-MTA: dns; aspmx.l.google.com
> >>> Diagnostic-Code: smtp; 550-5.7.1
> >>> Our
> >>> system has detected an 550-5.7.1 unusual rate of unsolicited mail
> >>> originating from your IP address. To 550-5.7.1 protect our users
> >>> from spam,
> >>> mail sent from your IP address has been 550-5.7.1 blocked. Please
> >> visit
> >>> 550-5.7.1  https://support.google.com/mail/answer/81126 to review
> >>> our Bulk
> >>> Email 550 5.7.1 Senders Guidelines. ju5si7198479wjc.28 - gsmtp
> >>> --
> >>>
> >>> The problem is most likely that Reporting-MTA doesn't match any of the
> >>> hostnames of the email we are sending from.
> >>
> >> No, the problem is most likely google thinks they are receiving an
> >> unusual rate of unsolicited mail from your IP.
> >>
> >> - First, set your SMTP HELO hostname to match your rDNS hostname with
> >> http://www.postfix.org/postconf.5.html#smtp_helo_name
> >> This probably won't fix the problem with google, but may help with
> >> other sites that don't like a non-FQDN or nonexistent HELO name.
> >>
> >> - configure your network gateway firewall such that client machines
> >> cannot access outgoing port 25 to prevent an infected client machine
> >> on your network from directly sending mail to the internet.
> >>
> >> - configure SPF, DKIM, and DMARC for your domains.  Looks as if you
> >> have SPF setup already.
> >>
> >>
> >>
> >>   -- Noel Jones
> >
> > I suggest the following.
> >
> > (this is obligated by RFCs)
> >
> > Make sure your helo mail-hostname.domain.tld has an A record.
> > Helo hostname must be resolvable.
> >
> > Make sure your hostname.domain.tld has an A and RR (PTR) record.
> > Most server do not block on this because you wil be blokking to many
> servers
> > Lots of hosts give "unknown" back so rejecting on unknown_hostname is
> not good imo.
> >
> > But an easy setting users/mail server managers can do is make sure the
> dns
> > And helo is correct.
> > So i do block on reject_invalid_helo_hostname
> reject_unknown_helo_hostname
> > And report back that the have incorrect server/dns settings.
> 
> How do you report that back?
For this on i use policiy weight, and there you can set you text also
http://www.policyd-weight.org/ 

> 
> >
> > My hostname of my server for example is core.domain.tld  (server
> hostname)
> > In postfix i have mail.domain.tld  (helo hostname)
> > ..  myhostname = mail.domain.tld
> >
> 
> For you to setup myhostname = mail.domain.tld and I guess you setup your
> FQDN to be domain.tld, does mail.domain.tld need to be a MX record?
[L.P.H. van Belle] 
No. The myhostname in postfix is the helo. 
I dont use domain.tld for any mail things thats only for my web server. 
Im thinking in the future where my web and mail server al on different servers, 
so no domain.tld on mail.

realname.domain.tld  thing one gets an A - MX and PTR record. 
mailhelo.domainname.tld  gets only an A record. 


> 
> > And you can set the same hostname in postfix and use that also for your
> server, but i dont recommend that.
> >
> > Then thats done, login at google, use the administrative tools from
> google to check your environment.
> >
> 
> I am new to that. Which tools?
[L.P.H. van Belle] good link to test : 
https://support.google.com/mail/troubleshooter/2920052?hl=en
https://support.google.com/a/answer/140038?hl=en 
https://www.google.com/webmasters/tools 
also handy.
https://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard


> 
> Thanks for your help.
> 
> Paulo Matos
> 
> > Greetz,
> >
> > Louis
> >
> >
> >