DMARC quarantine results

[li...@lazygranch.com]

These are the failing reports from DMARC set to quarantine. Most
failures are for SPF, which now I gather from the other post is due to
remailing. {Originally I thought the comment was about me using a
remailer.] 

It looks like if you pass DKIM, most ESPs just pass on the message. 

Since nobody I know personally is rejecting my email due to DMARC, does
it make sense just to set the DMARC to reject and watch the bounced
emails? I'm assuming the failures are on listserves. It seems to me
dealing with bounced emails is less work that reading these reports. 

Cloud9 is probably from the postfix listserve. ;-)


---
FROM GOOGLE:
2607:f140:0:1000::d is UC Berkeley
http://www.ip2location.com/2607%3Af140%3A0%3A1000%3A%3Ad

  2607:f140:0:1000::d
  1
  
none
fail
fail

  looks forwarded, downgrade to quarantine with phishing
warning 

  


  MYDOMAIN


  
MYDOMAIN
fail
  
  
MYDOMAIN
fail
  

  

207.46.163.236 is Microsoft
http://www.ip2location.com/207.46.163.236
  
  

  207.46.163.236
  1
  
none
pass
fail
  




  
MYOTHERDOMAIN
pass
  
  
cuesta.edu
none
  
207.46.163.140 is Microsoft
http://www.ip2location.com/207.46.163.140
   
  207.46.163.140
  1
  
none
pass
fail
  

-
FROM HOTMAIL:
168.100.1.7 is Cloud 9
http://www.ip2location.com/168.100.1.7


168.100.1.7
27

none
pass
fail

74.125.82.54 is google
http://www.ip2location.com/74.125.82.54
74.125.82.54
1

none
pass
fail
--

Re: Special method required for Gmail dkim/spf verification

[li...@lazygranch.com]

On Wed, 13 Apr 2016 17:08:57 -0700
li...@lazygranch.com wrote:

> Yesterday's Google report had me passing. Could be related to adding
> the Google term to DNS.
> 

Hold the presses here. It turns out my domain was spoofed in the
report that failed. The IP address used isn't mine. In the passing
report, it was my IP address, which makes sense since my SPF and DKIM
are fine. 

The offending IP address comes back to UC Berkeley. If I ever
get an official answer regarding the event, I will do a follow up.

Needless to say, I think the DMARC quarantine is a good idea. 

SPF option in Postfix 3

[li...@lazygranch.com]

I noticed I was running postfix 3.1.0. Freebsd has rev 3.1.1, so I
figured I would upgrade.

Fist up, I reviewed the page I used as a starting point for setting up
my mail server, namely 
http://blog.iandreev.com/?p=1604
In the configuration for postfix, the SPF option is not selected.

Somewhere in my journey of setting up postfix, I ended up adding this
to the master.cf:

policyd-spf  unix  -   n   n   -   0   spawn
user=nobody argv=/usr/local/bin/policyd-spf


My main.cf has this relative to spf:
-
smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_client_access hash:/usr/local/etc/postfix/rbl_override,
  reject_rbl_client zen.spamhaus.org,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client cbl.abuseat.org,
  reject_rbl_client b.barracudacentral.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  reject_rbl_client rabl.nuclearelephant.com,
  check_policy_service unix:private/policyd-spf,
  permit
smtpd_relay_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination
policyd-spf_time_limit = 3600
#policy_time_limit = 3600
mailbox_size_limit = 0
message_size_limit = 0
virtual_mailbox_limit = 0
---

As far as I can tell, I pass the SPF tests based on the various email
certification services.

So should I select the spf option when I upgrade? I'm hesitant to 
break what doesn't need fixing.

postfix 3.1.1 upgrade from 3.1.0

[li...@lazygranch.com]

During the upgrade from postfix 3.1.0 to 3.1.1, the installation script
issued the following:

--
===> Creating users
Using existing user 'postfix'.

Note: the following files or directories still exist but are
no longer part of Postfix:

 /usr/local/etc/postfix/virtual


Do I still need to do the following when adding new users?
-
postmap /usr/local/etc/postfix/virtual
postmap /usr/local/etc/postfix/vmailbox
---

I did a few test emails and nothing seems broken.

Re: growing size of mail.log file - postfix logs

[li...@lazygranch.com]

On Thu, 2 Mar 2017 08:34:59 +0100
Patrick Ben Koetter  wrote:

> * Poliman - Serwis :
> > Hi everyone. In mail.log file I have many lines like below:
> > Mar  2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: SSL_accept
> > error from house.census.shodan.io[89.248.172.16]: -1 Mar  2
> > 06:53:30 vps342401 postfix/smtps/smtpd[14642]: warning: TLS library
> > problem: error:1408A10B:SSL routines:SSL3_GET_CLIENT_HELLO:wrong
> > version number:s3_srvr.c:966:  
> 
> Postfix refuses to use SSLv3.
> 
> 
> > Mar  2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: lost
> > connection after CONNECT from house.census.shodan.io[89.248.172.16]
> > Mar  2 06:53:30 vps342401 postfix/smtps/smtpd[14642]: disconnect
> > from house.census.shodan.io[89.248.172.16] Mar  2 06:53:30
> > vps342401 postfix/smtps/smtpd[14637]: lost connection after CONNECT
> > from house.census.shodan.io[89.248.172.16]  
> 
> house.census.shodan.io tries to connect your Postfix server and then
> nothing happens. Unless every other host has this problem too, you
> will have to talk to the people who run house.census.shodan.io to
> find out why their client doesn't proceed with a SMTP session.
> Chances are their hosts problem is, it is unable to use any
> other/newer TLS protocol version.
> 
> 
> > and
> > 
> > Mar  2 07:15:01 vps342401 dovecot: pop3-login: Disconnected (no
> > auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1,
> > secured, session= Mar  2 07:20:01 vps342401
> > dovecot: imap-login: Disconnected (disconnected before auth was
> > ready, waited 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1,
> > secured, session=<+TxOa7lJ/AB/AAAB> Mar  2 07:20:01 vps342401
> > dovecot: pop3-login: Disconnected (no auth attempts in 0 secs):
> > user=<>, rip=127.0.0.1, lip=127.0.0.1, secured,
> > session= Mar  2 07:25:01 vps342401 dovecot:
> > imap-login: Disconnected (disconnected before auth was ready,
> > waited 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured,
> > session=  
> 
> Something - a program ? - on your server connects to your dovecot
> service and disconnects. Find out what it is.
> 
>  
> > From two days log file has 18MB. What is wrong?  
> 
> The log size is not necessarily an indicator that something is wrong
> on your machine. On busy machines 18 MB growth is a matter of minutes.
> 
> How recurring are the errors in the LOG? Is it always the same error?
> Is it always the same host having problems with your server?
> 
> p@rick

I block that server from all but port 25. It will password guess until
the cows come home.  I had no idea it was associated with shodan, but
now all the more reason to block it.

#novogara
ipfw table 1 add  89.248.160.0/21
ipfw table 1 add  89.248.169.0/24
ipfw table 1 add  89.248.170.0/23
ipfw table 1 add  89.248.172.0/23
ipfw table 1 add  89.248.174.0/24
ipfw table 1 add  93.174.88.0/21
ipfw table 1 add  94.102.48.0/20

There is a snowshoe type botnet password guesser hosted at Digital
Ocean. Being a customer of them, I complained. I stopped for a few
days, but it back again. They password guess in sequence.

138.68.90.75
139.59.158.92
207.154.221.122

Also the "141" block of the University of Michigan. I have contacted
them to see if they are doing "research", but I get no reply.

ipfw table 3 add 141.211.0.0/16
ipfw table 3 add 141.212.0.0/16
ipfw table 3 add 141.213.0.0/16
ipfw table 3 add 141.214.0.0/16

Mind you, I can block these ports because I'm the only customer of my
server. 

Yes I know fail2ban is the way to go, but my cellphone creates some
chatter that would trigger an aggressive fail2ban.






> 
> 

Re: TLD blocking revisited

[li...@lazygranch.com]

https://topicdesk.com/downloads/tutorials/spamassassin-filter-for-new-tlds-xyz-info-ninja-etc/
I used this, more or less. It wasn't exactly set up for freebsd. The
directory needed is at
/usr/local/etc/mail/spamassassin

PS:
Benny, is that your real email address? I'd like to take this off the
list.

On Tue, 20 Sep 2016 04:12:48 +0200
Benny Pedersen <m...@junc.eu> wrote:

> On 2016-09-20 04:08, li...@lazygranch.com wrote:
> > OK. Would I score it in SpamAssassin? If not, where? Point me in the
> > right direction and I assume Google will be my friend.
> 
> make a tld list in enlist, score that enlist in spamassassin, if need 
> more help mail me

TLD blocking revisited

[li...@lazygranch.com]

The last time TLD blocking came up, the consensus of the hive was not
to block based on TLD. (You may recall .xyz being used by
Alphabet.) However lately I'm getting a ridiculous number of .stream
SPAM coming through. The RBLs are getting about half. 

https://www.spamhaus.org/statistics/tlds/

I have a hard time believing I will ever get legit mail from a .stream
or a .download.

FWIW, many of the .stream pass SPF, which is perhaps why the RBLs are
not being as aggressive. 
Example:
--
SPF record lookup and validation for: recentirn.stream

SPF records are published in DNS as TXT records.

The TXT records found for your domain are:
v=spf1 a mx ip4:104.148.96.0/24 -all 

Checking to see if there is a valid SPF record. 

Found v=spf1 record for recentirn.stream: 
v=spf1 a mx ip4:104.148.96.0/24 -all 

evaluating...
SPF record passed validation test with pySPF (Python SPF library)!
-
SPF record lookup and validation for: qeonar.stream

SPF records are published in DNS as TXT records.

The TXT records found for your domain are:
v=spf1 a mx ip4:107.173.0.0/24 -all 

Checking to see if there is a valid SPF record. 

Found v=spf1 record for qeonar.stream: 
v=spf1 a mx ip4:107.173.0.0/24 -all 

evaluating...
SPF record passed validation test with pySPF (Python SPF library)!
--

Yada yada yada.

Re: Blocking "unknown"

[li...@lazygranch.com]

On Fri, 30 Sep 2016 06:26:35 -0400
Postfix User  wrote:

> Postfix-3.2-20160917 with FreeBSD-11.0 /64 bit
> 
> Lately, I have been finding the following entries in the maillog:
> 
> 13643:Sep 30 02:00:40 scorpio postfix/smtpd[83056]: warning: hostname
> ip-address-pool-xxx.fpt.vn does not resolve to address 118.71.251.67:
> hostname nor servname provided, or not known 13822:Sep 30 02:00:40
> scorpio postfix/smtpd[83056]: connect from unknown[118.71.251.67]
> 13904:Sep 30 02:00:41 scorpio postfix/smtpd[83056]: disconnect from
> unknown[118.71.251.67] helo=1 auth=0/1 quit=1 commands=2/3

This will pull these hackers off your maillog.
bzgrep -e auth=0/1 maillog* | sed 's/.*\[\([^]]*\)\].*/\1/g' >iplist
sort iplist | uniq

I'm going to wait a bit regarding automatically rejecting these
attempts per the method listed in the rest of the thread, but I'd like
to hear a follow up.

FWIW, I took the list of shady IP addresses and made a table for ipfw
for the ones I'm pretty sure I can block. 

Re: Blocking "unknown"

[li...@lazygranch.com]

On Sat, 1 Oct 2016 10:59:02 +0100
Allen Coates <znab...@cidercounty.org.uk> wrote:

> 
> 
> On 01/10/16 10:37, Postfix User wrote:
> > On Fri, 30 Sep 2016 17:08:05 -0700, li...@lazygranch.com stated:
> >
> >> This will pull these hackers off your maillog.
> >> bzgrep -e auth=0/1 maillog* | sed 's/.*\[\([^]]*\)\].*/\1/g'
> >> >iplist sort iplist | uniq
> > Great idea. I modified it slightly since the "sort" was not working
> > correctly here. I make a bash script.
> 
> I use the "tail" command on the logfile, and rebuild periodically, so
> the blacklisted entries die after a few days.
> 
> And I also use "uniq -d" so they are only blacklisted after the second
> "strike".
> 
> > IPLIST="/var/tmp/iplist.txt"
> > MAILLOG="/var/log/maillog"
> >
> > if [[ -e ${IPLIST} ]]; then
> >rm ${IPLIST} &> /dev/null
> > fi
> >
> > bzgrep -e auth=0/1 ${MAILLOG} | sed 's/.*\[\([^]]*\)\].*/\1/g' |
> > sort -V | uniq > ${IPLIST}
> >
> > I think I will add the ability to create a table for IPFW also.
> 
> My entries go in the file postscreen_blacklist.cidr
> 
> 
> Allen C
> 

This is how I convert an ascii list to an IPFW table. Note there is a
command to find which tables are in use, but I can't find it in the man.
Just make sure you don't overwrite a table in use. This example uses
table 1.
--
ipfw table 1 flush
cat fileofips | xargs -n1 echo ipfw table 1 add | bash
-
The use of bash is in the event you have a bug in the fileofips. It
insures whichever ips in the file that can be parsed are fed to the
table. Useful in the event you have a script to generate the IPs and
things go south. 

OT but perhaps useful, if you run nginx and use their "deny" format in a
file, this script will convert it to a table.
--
sed 's/ //g; s/deny//; s/;//; /^#/d' blockips.conf >feedipfw
ipfw table 1 flush
cat feedipfw | xargs -n1 echo ipfw table 1 add | bash
service nginx reload
service nginx restart

Re: TLS details not in header as viewed from email client (claws)

[li...@lazygranch.com]

"smtpd_tls_received_header = yes" is in the postconf. But I appreciate
the heads up on what to look for. So many parameters!

I'm going to set up a different mail client as a double check. The Claws
people say nothing has changed on their end, but who knows. If I just
set up a second imap, there shouldn't be any lost mail issues. 


On Wed, 9 Nov 2016 10:17:04 -0600
Noel Jones <njo...@megan.vbhcs.org> wrote:

> On 11/9/2016 9:32 AM, li...@lazygranch.com wrote:
> > I posted the entire header from claws. That is the receive header
> > since I sent the message from yahoo.
> > 
> 
> There are no Received: headers in what you posted.  That's where the
> TLS information is found. Either your claws is set to hide those
> headers or you've configured postfix header_checks to remove them
> with an IGNORE statement.  Don't do that.
> 
> 
> 
>   -- Noel Jones
> 
> > 
> >   Original Message  
> > From: Noel Jones
> > Sent: Wednesday, November 9, 2016 6:53 AM
> > To: postfix-users@postfix.org
> > Reply To: postfix users
> > Subject: Re: TLS details not in header as viewed from email client
> > (claws)
> > 
> > On 11/9/2016 2:56 AM, li...@lazygranch.com wrote:
> >> I no longer see TLS details in the header. I checked maillog and
> >> TLS is being established.
> >> ---
> >> From maillog:
> >> Nov 8 07:49:44 theranch postfix/smtpd[30627]: Anonymous TLS
> >> connection established from
> >> nm27.bullet.mail.ne1.yahoo.com[98.138.90.90]: TLSv1.2 with cipher
> >> ECDHE-RSA-AES128-GCM-SHA2 56 (128/128 bits)
> >> 
> >>
> >> Header (slightly sanitized to stay off of google)
> >> -
> >> From: some dude <somed...@yahoo.com>
> >> To: "me" <m...@mydomain.com>
> >> Subject: from yahoo
> >> Date: Tue, 8 Nov 2016 07:49:41 + (UTC)
> >> Reply-To: some dude <somed...@yahoo.com>
> >> Return-Path: <somed...@yahoo.com>
> >> X-Original-To: m...@mydomain.com
> >> Delivered-To: m...@mydomain.com
> >> X-Virus-Scanned: amavisd-new at mydomain.com
> >> Authentication-Results: www.mydomain.com (amavisd-new);
> >> dkim=pass (2048-bit key) header.d=yahoo.com
> >> DKIM-Filter: OpenDKIM Filter v2.10.3 www.mydomain.com 6AA43EB20F
> >> Authentication-Results: mydomain.com;
> >> dkim=pass (2048-bit key; unprotected) header.d=yahoo.com
> >> header.i=@yahoo.com header.b=trAlWMaE DKIM-Signature: v=1;
> >> a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
> >> t=1478591383; bh=cRZGv5wOLgNFzbAfI5tLNkRMXYbHl/vWifDflA5eMtw=;
> >> h=Date:From:Reply-To:To:Subject:References:From:Subject;
> >> b=trAlWMaE/s+6aINuk6b6ySW6h1CZF6LiKQOfQgoUg4i8JzjySXbgBkAOuH+GAb55+QQHA6A8sjJeK77UvhVUS+BkAyZMiTAMkt8m9kMe77m31MjzWQ4Ig82CXogOA5+SESyKrwZZAuipFGuIq4APO06SM0hCGBmUJYHNuYytxKpTrW5FT8TFXm89vq2+MspXjd1k75qcQ+fF1kwst3n6X28teuV6o65mInGqL9vkrPrwtOGihdQqcrepyEkRnU7RflFRb1rtC0zS9pVuo1/ZcJjKeldeHsYzDzDpdiOiJNXokcRot/X5yidLYkgI5JkSPbFHe+HgQupWXOxdMxI8iQ==
> >> X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id:
> >> 878361.88180...@omp1007.mail.ne1.yahoo.com X-YMail-OSG:
> >> nEWp4QsVM1nZt5mFz73vbEgYx.Lt3B_GBcEvOTw0Vp0LtD3J99f0OjdWkUcARg5
> >> fQOYXcuRTpVY9z.FPYba81.F6ZWzTg7R9.2qD4awC6TFWAARiWK43ECrmkWodJuHDdL8gxc3OyX5
> >> LAcxtI9b9TGqh0OfPAU1dWmpLs3sALzDSN3bWIvvbmDfRoJfwshV.Z3NlBRXE0BTRlXIEZ9yTMHP
> >> 7hroI1tkmFwOOVOqUs8YFevk0ma39L1OCaZ4tkr2rr0Tv0pkkgrCdXiHJIWrUNNEHrsQsePKlcn7
> >> 3TI.yj5J2Xocsga14Zqbnn6Nkm8QYuTeELAPA5RIb4VUNcptkCZQcyeUF8ikKx9aVKM31kGveMNe
> >> ANNorn_lvKSS9u2P95D2V6dsUcZwujC5ctuWOtFZN1qheWGIOXTfP3HkjaVIq9AYQBFX_EA50W1f
> >> 3.O5tpuiZsim9J7g6CQxJPkQq4HzhmTNxAQ6iKABKju3ukJKUoFtNlC8V5qzon6y5M4AJEH3B1ep
> >> ObjfCt_ERaTcEhRs2wQ_sCyg-
> >>
> >> from yahoo
> >> -
> > 
> > 
> > 
> > Where are the Received: headers? Don't remove them.
> > 
> > 
> > 
> > -- Noel Jones
> > 
> > 
> >>
> >>
> >> # postconf -n (sanitized also)
> >>
> >>
> >> broken_sasl_auth_clients = yes
> >> command_directory = /usr/local/sbin
> >> compatibility_level = 2
> >> content_filter = amavisfeed:[127.0.0.1]:10024
> >> daemon_directory = /usr/local/libexec/postfix
> >> data_directory = /var/db/postfix
> >> debug_peer_level = 2
> >> debugger_command =
> >> PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd
> >> $daemon_directory/$pro

Re: TLS details not in header as viewed from email client (claws)

[li...@lazygranch.com]

The claws group sent me on a wild goose chase. Postfix seems to work
just fine with Seamonkey email. The TLS portion of the header follows.


from nm24-vm3.bullet.mail.ne1.yahoo.com
(nm24-vm3.bullet.mail.ne1.yahoo.com [98.138.91.154]) (using TLSv1.2
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client
certificate requested) by www.inplanesight.org (Postfix) with ESMTPS id
2E255EB20F for <g...@inplanesight.org>; Tue,  8 Nov 2016 07:22:25 +
(UTC)

On Wed, 9 Nov 2016 09:03:12 -0800
"li...@lazygranch.com" <li...@lazygranch.com> wrote:

> "smtpd_tls_received_header = yes" is in the postconf. But I appreciate
> the heads up on what to look for. So many parameters!
> 
> I'm going to set up a different mail client as a double check. The
> Claws people say nothing has changed on their end, but who knows. If
> I just set up a second imap, there shouldn't be any lost mail issues. 
> 
> 
> On Wed, 9 Nov 2016 10:17:04 -0600
> Noel Jones <njo...@megan.vbhcs.org> wrote:
> 
> > On 11/9/2016 9:32 AM, li...@lazygranch.com wrote:  
> > > I posted the entire header from claws. That is the receive header
> > > since I sent the message from yahoo.
> > >   
> > 
> > There are no Received: headers in what you posted.  That's where the
> > TLS information is found. Either your claws is set to hide those
> > headers or you've configured postfix header_checks to remove them
> > with an IGNORE statement.  Don't do that.
> > 
> > 
> > 
> >   -- Noel Jones
> >   
> > > 
> > >   Original Message  
> > > From: Noel Jones
> > > Sent: Wednesday, November 9, 2016 6:53 AM
> > > To: postfix-users@postfix.org
> > > Reply To: postfix users
> > > Subject: Re: TLS details not in header as viewed from email client
> > > (claws)
> > > 
> > > On 11/9/2016 2:56 AM, li...@lazygranch.com wrote:  
> > >> I no longer see TLS details in the header. I checked maillog and
> > >> TLS is being established.
> > >> ---
> > >> From maillog:
> > >> Nov 8 07:49:44 theranch postfix/smtpd[30627]: Anonymous TLS
> > >> connection established from
> > >> nm27.bullet.mail.ne1.yahoo.com[98.138.90.90]: TLSv1.2 with cipher
> > >> ECDHE-RSA-AES128-GCM-SHA2 56 (128/128 bits)
> > >> 
> > >>
> > >> Header (slightly sanitized to stay off of google)
> > >> -
> > >> From: some dude <somed...@yahoo.com>
> > >> To: "me" <m...@mydomain.com>
> > >> Subject: from yahoo
> > >> Date: Tue, 8 Nov 2016 07:49:41 + (UTC)
> > >> Reply-To: some dude <somed...@yahoo.com>
> > >> Return-Path: <somed...@yahoo.com>
> > >> X-Original-To: m...@mydomain.com
> > >> Delivered-To: m...@mydomain.com
> > >> X-Virus-Scanned: amavisd-new at mydomain.com
> > >> Authentication-Results: www.mydomain.com (amavisd-new);
> > >> dkim=pass (2048-bit key) header.d=yahoo.com
> > >> DKIM-Filter: OpenDKIM Filter v2.10.3 www.mydomain.com 6AA43EB20F
> > >> Authentication-Results: mydomain.com;
> > >> dkim=pass (2048-bit key; unprotected) header.d=yahoo.com
> > >> header.i=@yahoo.com header.b=trAlWMaE DKIM-Signature: v=1;
> > >> a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
> > >> t=1478591383; bh=cRZGv5wOLgNFzbAfI5tLNkRMXYbHl/vWifDflA5eMtw=;
> > >> h=Date:From:Reply-To:To:Subject:References:From:Subject;
> > >> b=trAlWMaE/s+6aINuk6b6ySW6h1CZF6LiKQOfQgoUg4i8JzjySXbgBkAOuH+GAb55+QQHA6A8sjJeK77UvhVUS+BkAyZMiTAMkt8m9kMe77m31MjzWQ4Ig82CXogOA5+SESyKrwZZAuipFGuIq4APO06SM0hCGBmUJYHNuYytxKpTrW5FT8TFXm89vq2+MspXjd1k75qcQ+fF1kwst3n6X28teuV6o65mInGqL9vkrPrwtOGihdQqcrepyEkRnU7RflFRb1rtC0zS9pVuo1/ZcJjKeldeHsYzDzDpdiOiJNXokcRot/X5yidLYkgI5JkSPbFHe+HgQupWXOxdMxI8iQ==
> > >> X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id:
> > >> 878361.88180...@omp1007.mail.ne1.yahoo.com X-YMail-OSG:
> > >> nEWp4QsVM1nZt5mFz73vbEgYx.Lt3B_GBcEvOTw0Vp0LtD3J99f0OjdWkUcARg5
> > >> fQOYXcuRTpVY9z.FPYba81.F6ZWzTg7R9.2qD4awC6TFWAARiWK43ECrmkWodJuHDdL8gxc3OyX5
> > >> LAcxtI9b9TGqh0OfPAU1dWmpLs3sALzDSN3bWIvvbmDfRoJfwshV.Z3NlBRXE0BTRlXIEZ9yTMHP
> > >> 7hroI1tkmFwOOVOqUs8YFevk0ma39L1OCaZ4tkr2rr0Tv0pkkgrCdXiHJIWrUNNEHrsQsePKlcn7
> > >> 3TI.yj5J2Xocsga14Zqbnn6Nkm8QYuTeELAPA5RIb4VUNcptkCZQcyeUF8ikKx9aVKM31kGveMNe
> > >> ANNorn_lvKSS9u2P95D2V6dsUcZwujC5ctuWOtFZN1qheWGIOXTfP3HkjaVIq9AYQBFX_EA50W1f
> > 

bits of encryption

[li...@lazygranch.com]

This comes under the notion that if you don't ask, you don't learn.

I did some dovecot2 updates, so naturally I decided to test the mail
system. When I mail a message to myself, this is the TLS notification:
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))

However I do receive mail with higher levels of encryption. For example:
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))

But in both cases, isn't my certificate the one being used for
encryption? Other than building my cert at 4096 bits, I don't remember
much other than it was a pain to get working.

If you know what ELI5 means, that would be appreciated.

freeBSD update boost-libs and postfix

[li...@lazygranch.com]

Hopefully this isn't a duplicate message. I've been repairing the mail
system.

Just a FYI that if you update
boost-libs 
with pkg under freeBSD, it loads postfix for some reason.
All my .db files were unreadable. I had to postmap and postalias them
to make them readable again. 

I should have said no, but unfortunately indicated yes.
- 


# pkg install boost-libs
Updating FreeBSD repository catalogue...
FreeBSD repository is up-to-date.
All repositories are up-to-date.
The following 5 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
boost-libs: 1.55.0_10 -> 1.55.0_13
icu: 55.1 -> 57.1,1
harfbuzz: 1.3.0 -> 1.3.2

Installed packages to be REINSTALLED:
postfix-3.1.3,1 (options changed)
musicpd-0.19.15_4 (options changed)

Number of packages to be upgraded: 3
Number of packages to be reinstalled: 2

The operation will free 25 MiB.
20 MiB to be downloaded.

Proceed with this action? [y/N]: y
Fetching boost-libs-1.55.0_13.txz: 100%9 MiB   4.7MB/s00:02
Fetching icu-57.1,1.txz: 100%9 MiB   9.3MB/s00:01
Fetching harfbuzz-1.3.2.txz: 100%  258 KiB 264.7kB/s00:01
Fetching postfix-3.1.3,1.txz: 100%1 MiB 772.0kB/s00:02
Fetching musicpd-0.19.15_4.txz: 100%  200 KiB 205.2kB/s00:01
Checking integrity... done (0 conflicting)
[1/5] Upgrading icu from 55.1 to 57.1,1...
[1/5] Extracting icu-57.1,1: 100%
[2/5] Upgrading boost-libs from 1.55.0_10 to 1.55.0_13...
[2/5] Extracting boost-libs-1.55.0_13: 100%
[3/5] Upgrading harfbuzz from 1.3.0 to 1.3.2...
[3/5] Extracting harfbuzz-1.3.2: 100%
[4/5] Reinstalling postfix-3.1.3,1...
===> Creating groups.
Using existing group 'mail'.
Using existing group 'maildrop'.
Using existing group 'postfix'.
===> Creating users
Using existing user 'postfix'.
[4/5] Extracting postfix-3.1.3,1: 100%
You may need to manually remove /usr/local/etc/postfix/main.cf if it is no 
longer needed.
You may need to manually remove /usr/local/etc/postfix/master.cf if it is no 
longer needed.

Note: the following files or directories still exist but are
no longer part of Postfix:

 /usr/local/etc/postfix/virtual

Would you like to activate Postfix in /etc/mail/mailer.conf [n]? n

===
Postfix was *not* activated in /etc/mail/mailer.conf! 

To finish installation run the following commands:

  mv -f /etc/mail/mailer.conf /etc/mail/mailer.conf.old
  install -m 0644 /usr/local/share/postfix/mailer.conf.postfix 
/etc/mail/mailer.conf
===

Re: Open relay

[li...@lazygranch.com]

On Fri, 21 Oct 2016 22:56:45 +0200
Paul van der Vlis  wrote:

> Hello Angelo and others,
> 
> Op 21-10-16 om 22:24 schreef Fazzina, Angelo:
> > So what is SASL using in Postfix ?
> > Is Postfix calling SASL, which calls PAM, which calls LDAP, to
> > check the Password?
> 
> Postfix is calling saslauthd, which calls PAM, which calls unix
> passwords.
> 
> > You must follow the trail of how they got the password if you say
> > you changed it and it does not help.
> 
> I don't think they have a correct username/password combination,
> because the username is wrong.
> 
> Maybe it's possible to log the username/password Postfix get?
> 
> Maybe they are using some kind of trick to let Postfix think the mail
> comes from localhost.
> 
> With regards,
> Paul van der Vlis.
> 
> 
> > -ALF
> > 
> > -Angelo Fazzina
> > Operating Systems Programmer / Analyst 
> > University of Connecticut,  UITS, SSG-Linux/ M
> > 860-486-9075
> > 
> > -Original Message-
> > From: owner-postfix-us...@postfix.org
> > [mailto:owner-postfix-us...@postfix.org] On Behalf Of Paul van der
> > Vlis Sent: Friday, October 21, 2016 4:16 PM To:
> > postfix-users@postfix.org Subject: Open relay
> > 
> > Hello,
> > 
> > I have a big problem, someone is using my mailserver for sending
> > spam. I see it in de logs. I can block the IP but then they use
> > other IP's.
> > 
> > So far I know my server is up-to-date and correct configured. And
> > when I do some open relay tests, everything is OK. Like this ones:
> > http://www.mailradar.com/openrelay/
> > http://mxtoolbox.com/diagnostic.aspx
> > 
> > The name of my mailserver is mail.vandervlis.nl, so far I see the
> > spammers are using port 587. Please feel free to do tests.
> > 
> > What I see in the logs and in the headers of the spam is that they
> > are using authentication. But the username is not correct. On my
> > server I use usernames like "john", and this username lookslike an
> > e-mail address, so with an "@" in it. The part before the @ is a
> > correct username on my server, but when I change the password it
> > does not help. All spam is recognizeble by this authenticated
> > username.
> > 
> > In the headers I see this as the first "received" (I've changed the
> > authenticated sender for privacy):
> > 
> > Received: from [127.0.0.1] (87-92-55-206.bb.dnainternet.fi
> > [87.92.55.206]) (Authenticated sender: p...@puk.nl)
> > by mail.vandervlis.nl (Postfix) with ESMTPSA id 774B23E0285;
> > Fri, 21 Oct 2016 18:57:14 +0200 (CEST)
> > 
> > As would my server sent it to my server...
> > 
> > Does somebody have a clou here?
> > 
> > With regards,
> > Paul van der Vlis.
> > 
> > 
> > Some settings and logs:
> > 
> > smtpd_relay_restrictions =
> >   permit_mynetworks,
> >   permit_sasl_authenticated,
> >   check_sender_access hash:/etc/postfix/whitelist,
> >   reject_invalid_hostname,
> >   reject_non_fqdn_sender,
> >   reject_non_fqdn_recipient,
> >   reject_unknown_sender_domain,
> >   reject_unknown_recipient_domain,
> >   reject_unauth_pipelining,
> >   reject_unauth_destination,
> >   check_policy_service unix:private/shadelist,
> >   reject_rbl_client bl.spamcop.net,
> >   reject_rbl_client zen.spamhaus.org,
> >   reject_rbl_client ix.dnsbl.manitu.net,
> >   permit
> > 
> > smtpd_tls_cert_file = /etc/postfix/tls/*.vandervlis.nl.pem
> > smtpd_use_tls = yes
> > smtpd_sasl_auth_enable = yes
> > smtpd_sasl_exceptions_networks = $mynetworks
> > smtpd_tls_loglevel = 1
> > smtpd_tls_auth_only = yes
> > smtpd_sasl_security_options = noanonymous
> > smtpd_sasl_tls_security_options = noanonymous
> > broken_sasl_auth_clients = yes
> > smtpd_sasl_authenticated_header = yes
> > 
> > Oct 21 16:54:31 sigmund postfix/smtpd[2158]: D34743E027B:
> > client=unknown[94.26.41.188], sasl_method=PLAIN,
> > sasl_username=p...@puk.nl
> > 
> > 
> 
> 
> 

Perhaps I'm being a bit anal here, and given my skill level (or lack
thereof) I should stay of of this, but is this actually an open relay in
the strict sense? Maybe that is a red herring. If they are using 587,
that would be the master.cf file, not main.cf.

submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
 

(Semi OT) RBL shakedown

[li...@lazygranch.com]

If you use the uceprotect RBL, note that they are involved in a
shakedown to solicit money to be removed from their list. Much like
spamrl, I'd suggest not using them since they have an obvious false
positive problem. 

http://www.uceprotect.net/en/rblcheck.php?ipr=107.170.248.198
Their own system shows my domain is not the same as the spammers domain.

Plenty of good RBLs out there. No uses feeding the criminals
(uceprotect) or the incompetent (spamrl).

Re: bits of encryption

[li...@lazygranch.com]

On Fri, 11 Nov 2016 09:54:48 -0500
"Bill Cole" <postfixlists-070...@billmail.scconsult.com> wrote:

> On 11 Nov 2016, at 6:21, li...@lazygranch.com wrote:
> 
> > So is this level of encryption something openssl sets up?  
> 
> Yes and no. The partners in an encrypted session negotiate the
> details of a ciphersuite when the session is established, based on
> both of their configurations. For Postfix, the configuration(s)
> determine how Postfix calls functions in the OpenSSL libraries, while
> other tools (i.e. client software, other mail servers, etc.) may use
> other TLS/SSL implementations that have analogous runtime
> configurability or none at all. Different versions of any one
> implementation like OpenSSL have differing capabilities as well.
> Different programs have different needs and priorities, so typically
> the encryption negotiation parameters are set by an application (e.g.
> Postfix, Apache, a mail client, a web browser, etc.) rather than at
> the shared library (e.g. OpenSSL, GNUTLS, NSS, etc.) level globally
> for a system.
> 
> So, Yes: OpenSSL code does the negotiation of ciphersuites between 
> various ostfix programs and the partners they talk to. Also, No: the 
> configuration of what ciphersuites are preferred and/or allowed is
> done within Postfix, not externally by some part of OpenSSL itself.
> 
> > ‎That is where do I set the parameter?  
> 
> You probably shouldn't, because it is unlikely to be of any value to 
> you. The strength difference between AES128 and AES256 transport 
> encryption is probably only relevant to you if your threat model 
> includes a major nation-state being able to intercept your email in 
> transit today and decrypt it sometime before 2025 as a meaningful
> risk. If that is a significant concern to you, email transport
> encryption would surely be very low on your list of risks and you
> really shouldn't be using email for such things AT ALL.
> 
> With that said... Postfix has multiple settings that define the
> ciphers it supports in the SMTP client (smtp) and server (smtpd) as
> well as the priorities of which ciphers to prefer in a negotiation.
> See Postfix's TLS_README file for the most cohesive documentation of
> those parameters.
> 
> Which you probably shouldn't change, but I repeat myself...
> 
> Two mistakes that people often make (and often bring here) with
> Postfix TLS configuration are:
> 
> 1. Not allowing for the negotiation of theoretically weaker 
> ciphersuites, resulting in fallback to unencrypted transport or
> simple failure when a partner won't do that fallback.
> 
> 2. Crafting carefully thought out cipher lists specifying individual 
> ciphersuites in a specific order, neglecting the fact that the "best" 
> such over-specified cipher list is a moving target even if one
> assumes that all participants are using the latest version of OpenSSL
> as their TLS implementation.
> 
> Exacerbating both of these is the fact that a lot of the searchable 
> how-tos for TLS configuration are narrowly focused on web and
> web-like interactions where the threat model and the practical
> utility of transport encryption are both quite different from SMTP
> transport or initial mail submission. This has meant in some cases
> that an algorithm's weakness which merits discouraging or even
> prohibiting its use on a webserver is ultimately meaningless for a
> MTA because the attack mode is implausible against a MTA or the
> vulnerability is one that is already intrinsic to SMTP.
> 
> The bottom line (if you've made it this far...) is that the settings 
> that involve deep encryption parameters in modern Postfix are best
> left at their default values unless you have very specific uncommon
> security needs, can accept outright insoluble breakage in place of
> imperfect security, and understand every sentence of the TLS_README,
> the relevant bits of postconf(5), and everything Viktor Dukhovni has
> ever written about encryption on this list.

My postfix setup lacks the tls_high_cipherlist parameter, as shown here:
https://blog.tinned-software.net/harden-the-ssl-configuration-of-your-mailserver/

Is the advice on that link reasonable? I see the setup echoed over the
interwebs, but of course bad advice bounces around the internet as well.

Re: Port 587 users question

[li...@lazygranch.com]

On Mon, 28 Nov 2016 09:01:41 -0500
btb <b...@bitrate.net> wrote:

> On 2016.11.27 20.43, li...@lazygranch.com wrote:
> > I should have mentioned the mail system is on a VPS and I'm the only
> > user. And yes, trouble makers are on the Internet.  
> 
> well, this simplifies things quite of bit, of course.
> 
> > What lead me to this was I did bzgrep "max auth" and noticed both
> > smtp and submission was found.  
> 
> i hope you're not offering smtp auth on port 25.

Well I think I am based on this anvil entry. What option of postconf
would show this?

maillog.3.bz2:Nov 28 09:39:37 theranch postfix/anvil[75111]: statistics: max 
auth rate 20/60s for (smtp:41.216.208.250) at Nov 28 09:36:16

Regarding 587 and the firewall, one blocked thus far. Better than
nothing I suppose.
 
security.0.bz2:Nov 28 04:06:55 theranch kernel: ipfw: 565 Deny TCP 
163.172.238.45:45853 107.170.248.198:587 in via vtnet0

hacker or server problem

[li...@lazygranch.com]

Is this a hack or a server problem. IP was listed in abusedb about a
year ago.


Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:36 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:36 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:37 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:37 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:37 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:38 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:38 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:38 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:39 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:39 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:14:40 theranch postfix/smtpd[6094]: connect from 
unknown[87.236.215.11]
Nov 16 09:14:40 theranch postfix/smtpd[6094]: lost connection after AUTH from 
unknown[87.236.215.11]
Nov 16 09:14:40 theranch postfix/smtpd[6094]: disconnect from 
unknown[87.236.215.11] ehlo=1 auth=0/1 commands=1/2
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max connection rate 
70/60s for (smtp:87.236.215.11) at Nov 16 09:14:40
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max connection count 
1 for (smtp:87.236.215.11) at Nov 16 09:13:45
Nov 16 09:18:00 theranch postfix/anvil[6096]: statistics: max cache size 1 at 
Nov 16 09:13:45

Re: hacker or server problem

[li...@lazygranch.com]

On Wed, 16 Nov 2016 11:52:14 +0200
Patrick Chemla <patrick.che...@perfaction.net> wrote:

> Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :
> > Is this a hack or a server problem. IP was listed in abusedb about a
> > year ago.
> >
> > 
> > Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
> > unknown[87.236.215.11] Nov 16 09:14:36 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:36 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:36 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:37 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:37 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:37 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:38 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:38 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:38 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:39 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:39 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:14:40 theranch postfix/smtpd[6094]:
> > connect from unknown[87.236.215.11] Nov 16 09:14:40 theranch
> > postfix/smtpd[6094]: lost connection after AUTH from
> > unknown[87.236.215.11] Nov 16 09:14:40 theranch
> > postfix/smtpd[6094]: disconnect from unknown[87.236.215.11] ehlo=1
> > auth=0/1 commands=1/2 Nov 16 09:18:00 theranch postfix/anvil[6096]:
> > statistics: max connection rate 70/60s for (smtp:87.236.215.11) at
> > Nov 16 09:14:40 Nov 16 09:18:00 theranch postfix/anvil[6096]:
> > statistics: max connection count 1 for (smtp:87.236.215.11) at Nov
> > 16 09:13:45 Nov 16 09:18:00 theranch postfix/anvil[6096]:
> > statistics: max cache size 1 at Nov 16 09:13:45  
> 
> Hi,
> 
> This is a trace of 6 connections tries from IP 87.236.215.11 with bad 
> credential (user/passwd).
> 
> Someone is trying to enter your server emails. Call it a hack.
> 
> Patrick
> 
> www.top-secured.com
> 

Actually way more than 6 attempts. I made a quick and dirty edit to the
firewall and blocked the entire CIDR 87.236.215.0/24

I don't see any usernames/domains in the log file, thus my confusion
about if it is a hack or a whacked out server. Now this is something I
could see setting up fail2ban to block. 

Re: hacker or server problem

[li...@lazygranch.com]

On Wed, 16 Nov 2016 02:26:13 -0800
"li...@lazygranch.com" <li...@lazygranch.com> wrote:

> On Wed, 16 Nov 2016 11:52:14 +0200
> Patrick Chemla <patrick.che...@perfaction.net> wrote:
> 
> > Le 16/11/2016 à 11:45, li...@lazygranch.com a écrit :  
> > > Is this a hack or a server problem. IP was listed in abusedb
> > > about a year ago.
> > >
> > > 
> > > Nov 16 09:14:36 theranch postfix/smtpd[6094]: connect from
> > > unknown[87.236.215.11] Nov 16 09:14:36 theranch
> > > postfix/smtpd[6094]: lost connection after AUTH from
> > > unknown[87.236.215.11] Nov 16 09:14:36 theranch

 
> 
# bzgrep -e 87.236.215.11 maillog | wc -l
 212

Three lines per hack. Make that 70 attempts. The stats line messes up
the line count.
First entry:Nov 16 09:13:45 
Last entry: Nov 16 09:18:00
255 seconds
16.5 attempts a minute

Re: bits of encryption

[li...@lazygranch.com]

On Sat, 12 Nov 2016 15:29:54 -0500
"Bill Cole" <postfixlists-070...@billmail.scconsult.com> wrote:

> On 11 Nov 2016, at 14:31, li...@lazygranch.com wrote:
> 
> > On Fri, 11 Nov 2016 09:54:48 -0500
> > "Bill Cole" <postfixlists-070...@billmail.scconsult.com> wrote:  
> 
> [big snip...]
> 
> >> The bottom line (if you've made it this far...) is that the
> >> settings that involve deep encryption parameters in modern Postfix
> >> are best left at their default values unless you have very
> >> specific uncommon security needs, can accept outright insoluble
> >> breakage in place of imperfect security, and understand every
> >> sentence of the TLS_README, the relevant bits of postconf(5), and
> >> everything Viktor Dukhovni has ever written about encryption on
> >> this list.  
> >
> > My postfix setup lacks the tls_high_cipherlist parameter,  
> 
> Unlikely. It is much more likely that your postfix setup simply uses
> the default value:
> 
>   # postconf tls_high_cipherlist
>   tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
> 
> 
> 
> > as shown here:
> > https://blog.tinned-software.net/harden-the-ssl-configuration-of-your-mailserver/
> >
> > Is the advice on that link reasonable? I see the setup echoed over
> > the interwebs, but of course bad advice bounces around the internet
> > as well.  
> 
> I stand by what I said above, which I THINK answers your question. Is
> it unclear?

# postconf tls_high_cipherlist
tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH
verified

Assuming the default "high" setting is sufficient, why wouldn't I change
this parameter to high rather than medium.

postconf smtpd_tls_mandatory_ciphers
smtpd_tls_mandatory_ciphers = medium

Actually 
smtp_tls_mandatory_protocols = high, !SSLv2, !SSLv3

since I excluded sslv2 and v3 after drown.

Re: bits of encryption

[li...@lazygranch.com]

On Sun, 13 Nov 2016 01:43:17 -0500
"Bill Cole"  wrote:
 
> If the NSA/GCHQ capturing all of your SMTP traffic and saving it for 
> hypothetical future decryption is a realistic and significant
> scenario in your threat model, you should reconsider your use of
> email.
> 

I'm in the USA and getting ready for life post Jan 20, 2017. It is very
likely the NSA will be after my email. 

I'll just try the tips in 
https://blog.tinned-software.net/harden-the-ssl-configuration-of-your-mailserver/

They're just lines in a configure file. Save the old file and you back
to where you were. 

Re: Is my server mail account being attacted?

[li...@lazygranch.com]

On Thu, 20 Oct 2016 17:13:26 -0400
"Bill Cole"  wrote:

> On 20 Oct 2016, at 16:39, Keith Williams wrote:
> 
> > No wait... What?
> >
> > This is no attack. Attack is when you try to break or enforce..
> > This is a probe, and from the probe we can deduce from the reported 
> > disconnect that 1. helo was tried, 2. no auth was attempted and 3, 
> > quit was used.
> >
> > So a test for helo and quit? and no auth.  
> 
> No. The "auth=0/1" in the disconnect line means that Postfix received
> 1 authentication attempt but it failed. This was a "probe" to see if
> a particular user exists and has a particular password.
> 
> > Someone is testing your IP and mail capibility.. perhaps>>  
> 
> Not stipulating that unauthorized "probes" are not also block-worthy, 
> but this is a bit more.
> 
> > On 20/10/2016 22:20, Bill Cole wrote:  
> >> On 18 Oct 2016, at 20:45, Sebastian Nielsen wrote:
> >>  
> >>> Its clear from the log, the attacker isn't even attemping to 
> >>> authenticate (0 attempts). The attacker hasn't propably not even 
> >>> realized he is connecting to a mail server.  
> >>
> >>
> >> No. There's a jumble there, but at least one is a lame "attack" of
> >> a sort. The only *Postfix* messages were:
> >>  
> >>> Oct 19 07:55:27 mail postfix/smtpd[9929]: connect from 
> >>> unknown[216.15.186.126]
> >>> Oct 19 07:55:28 mail postfix/smtpd[9929]: disconnect from 
> >>> unknown[216.15.186.126] helo=1 auth=0/1 quit=1 commands=2/3  
> >>
> >> *THAT* client tried to authenticate and failed. It's a CBL-listed
> >> IP on a chronically abuse-friendly network.
> >>
> >> The rest were all messages from Dovecot components, about failed
> >> SSL connections from a mix of IPs. Impossible to know what the
> >> reasons for those were without tracking down the person running
> >> the computer. 
> >  

Follow up. Different IP, same deal, but I added some error slowing
settings. 

#lines added after hacker attack
smtpd_soft_error_limit = 3
smtpd_error_sleep_time = 10s
smtpd_hard_error_limit = 6
smtpd_client_auth_rate_limit = 20
smtpd_client_connection_count_limit = 5
smtpd_client_connection_rate_limit = 20
smtpd_client_new_tls_session_rate_limit = 20
smtpd_client_recipient_rate_limit = 10
smtpd_recipient_limit = 10


maillog.4.bz2:Nov 19 12:40:43 theranch postfix/submission/smtpd[22648]: 
disconnect from unknown[172.56.38.118] ehlo=2 starttls=1 auth=1 quit=1 
commands=5
maillog.4.bz2:Nov 19 12:40:43 theranch postfix/submission/smtpd[22655]: 
disconnect from unknown[172.56.38.118] ehlo=2 starttls=1 auth=1 quit=1 
commands=5
maillog.4.bz2:Nov 19 12:40:43 theranch postfix/submission/smtpd[22653]: 
disconnect from unknown[172.56.38.118] ehlo=2 starttls=1 auth=1 quit=1 
commands=5
maillog.4.bz2:Nov 19 12:44:59 theranch postfix/anvil[22634]: statistics: max 
connection rate 9/60s for (submission:172.56.38.118) at Nov 19 12:40:23
maillog.4.bz2:Nov 19 12:44:59 theranch postfix/anvil[22634]: statistics: max 
connection count 6 for (submission:172.56.38.118) at Nov 19 12:40:20
maillog.4.bz2:Nov 19 12:44:59 theranch postfix/anvil[22634]: statistics: max 
newtls rate 5/60s for (submission:172.56.38.118) at Nov 19 12:40:20
maillog.4.bz2:Nov 19 12:44:59 theranch postfix/anvil[22634]: statistics: max 
auth rate 5/60s for (submission:172.56.38.118) at Nov 19 12:40:43

Re: Execute linux commands after receive a mail...

[li...@lazygranch.com]

On Thu, 16 Mar 2017 11:29:56 -0500
Noel Jones  wrote:

> On 3/16/2017 11:18 AM, Gilberto Nunes wrote:
> > Hello folks...
> > 
> > I just need execute some command after receive a mail...
> > 
> > I found this site: 
> > 
> > https://www.thecodingmachine.com/triggering-a-php-script-when-your-postfix-server-receives-a-mail/
> > 
> > This can be achieve with shell script as well??  
> 
> The above site is an example of a simple content_filter using a PHP
> script.  The postfix docs contain a similar example using a shell
> script.
> http://www.postfix.org/FILTER_README.html#simple_filter
> 
> 

I had no idea you could receive email on any port. I wonder how many
ISPs allow this.

In any event, would this be THE scheme to use for an IOT application?
That is send an email to turn on/off a sprinker, light, etc. The idea
being postfix et all does all the security, AKA the hard part.

Re: Specify VPN for postfix

[li...@lazygranch.com]

Take a look at your header file when using the VPN to email yourself. I
think what you want happens automatically. 

Received: from [10.8.0.6] (unknown [MYIPADDRESS])

10.8.0.6 is the local IP space created by my VPN. But my IP address
also shows up, so hopefully a guru will chime in as to how this all
works.

One thing to consider is that you may run into an internet provider
(probably public wifi) that blocks the use of a VPN. Somewhat common
with IPSEC. Perhaps less with openvpn. So you wouldn't want to make the
VPN be a mandatory requirement.




On Tue, 1 Aug 2017 12:07:26 +0800
Yubin Ruan  wrote:

> Hi,
> Can anyone tell me how to point postfix to a VPN connection? I have
> setup a VPN listening at background on my Ubuntu and I want to point
> postfix to that listening port whenever postfix try to connect to the
> internet.
> 
> Thanks,
> Yubin

Re: TLS warning

[li...@lazygranch.com]

On Thu, 25 May 2017 03:02:39 -0400
Rick Leir <rl...@leirtech.com> wrote:

> 
> 
> On 2017-05-25 02:31 AM, Philip Paeps wrote:
> > On 2017-05-24 14:54:34 (+0200), Bastian Blank 
> > <bastian+postfix-users=postfix@waldi.eu.org> wrote:
> >> On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com
> >> wrote:
> >>> ‎You shouldn't be accepting sslv3 due to the poodle attack.
> >>> https://en.m.wikipedia.org/wiki/POODLE
> >>
> >> Please explain how exactly SMTP is exploitable using POODLE?
> >
> > There are other good reasons to disable SSLv3.  But POODLE is a 
> > distraction in the context of SMTP.
> In the context of a SASL login to send outgoing email, is it still a 
> distraction?
> 
> How about dovecot, logging in to receive email and clean up my inbox?
> 
> As recommended by lazyG,
> 
> http://disablessl3.com/
> 
> >
> > In general though, when it comes to SMTP, any encryption is better 
> > than none.  And opportunistic encryption is the way to go.  Read
> > RFC 7435:
> >
> > https://tools.ietf.org/html/rfc7435
> Thanks!
> >
> > Philip
> >
> 

This paper is a good read on email security. It goes into the various
means that a man in the middle can reduce security, one of which is
enabled by selecting opportunistic encryption. (Of which in all
practicality you don't have a choice if you want maximum
compatibility. I'm amazed at the lack of encryption in first world
countries like Canada or the UK.)

"Neither Snow Nor Rain Nor MITM . . .
An Empirical Analysis of Email Delivery Security"
https://jhalderm.com/pub/papers/mail-imc15.pdf
Video by one of the authors.
https://www.youtube.com/watch?v=_aogXeTbERs

Given the email issues in recent political campaigns, I'm seeing a
number of articles suggesting setting up DMARC for quarantine. Most
recent:

http://www.prnewswire.com/news-releases/bishop-fox-research-finds-98-of-the-top-million-internet-domains-are-potentially-vulnerable-to-email-spoofing-300461861.html
Specifically "First, companies must safeguard their company's domain by
checking the company's DNS records for SPF and DMARC. Make sure that
the company's domain has a properly configured SPF record and a DMARC
record with a policy of quarantine or reject. Then, use Spoofcheck to
check if the domain is sufficiently protected."
Where 
http://spoofcheck.bishopfox.com/#!/
isn't exactly rocket science. It just reads your DMARC.

PSA University of Michigan research IP space

[li...@lazygranch.com]

http://researchscan288.eecs.umich.edu/
I never could find the research IP space and my email went unanswered.
I just blocked the whole university. Link has the IP space as listed
below:
141.212.121.0/24 
141.212.122.0/24

Re: PSA University of Michigan research IP space

[li...@lazygranch.com]

On Thu, 7 Dec 2017 22:59:46 -0500
Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:

> > On Dec 7, 2017, at 9:14 PM, li...@lazygranch.com wrote:
> > 
> > http://researchscan288.eecs.umich.edu/
> > I never could find the research IP space and my email went
> > unanswered. I just blocked the whole university. Link has the IP
> > space as listed below:
> > 141.212.121.0/24 
> > 141.212.122.0/24  
> 
> Seems rather an overreaction. So a few bots scan your system now and
> then, for socially beneficial research purposes[1].  Does it really
> make sense to block an entire university to try to avoid this?
> 

I'm in agreement with you regarding blocking an entire university, but
I couldn't get a reply regarding the research IP space, nor could I
find the IP space online until today. 

Email, being the means of resetting passwords, gets extra scrutiny by
me. Now that I have the research IP space, I have removed the full
block. 

Interesting commentary:
https://www.hackerfactor.com/blog/index.php?url=archives/775-Scans-and-Attacks.html

The problem is the researchers look like hackers. For web "research",
they may provide an address to contact them in the browser meta data.
Maybe they are researchers, and maybe not. 

I allow a fair number of bots to poke the server, even if they appear
dubious. One claims to research uptime, but if you ping me once a day,
I don't think that is much of a study. I have a gut feeling many of
these research bots are really zombies. The student has graduated and
the account never canceled. I'm sure you've heard the story (perhaps
legend) of the university sysadmin mapping the network and finding some
server tucked away in a closet that they had no idea was there.

policyd-spf tip

[li...@lazygranch.com]

There are many "problem solving pages" on the interwebs that have wrong
information on setting up policyd-spf. The key to make sure you use
consistent names in both main.cf and master.cf. Yeah, I know, I'm
preaching to the choir, but hopefully the next person with a set up
problem finds this message in a search.

In master.cf:
policyunix  -   n   n   -   0   spawn
 user=nobody  argv=/usr/libexec/postfix/policyd-spf 
/etc/policyd-spf/policyd-spf.conf

Note you need to make sure the conf file location is correct.

In main.cf:
smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_rbl_client zen.spamhaus.org,
  check_policy_service unix:private/policy,
  permit

policy_time_limit = 3600

The word "policy" needs to be consistent in all three locations. For
example, this would be wrong:
  check_policy_service unix:private/policyd-spf,

Also wrong would be:
policyd_time_limit = 3600


In postfix, systemctl status postfix should indicate the policyd-spf
daemon was started:

● postfix.service - Postfix Mail Transport
Agent Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled;
vendor preset: disabled) Active: active (running) since Mon 2017-12-25
05:28:11 UTC; 16s ago Process: 7661 ExecStop=/usr/sbin/postfix stop
(code=exited, status=0/SUCCESS) Process: 7681
ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)
Process: 7679 ExecStartPre=/usr/libexec/postfix/chroot-update
(code=exited, status=0/SUCCESS) Process: 7677
ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited,
status=0/SUCCESS) Main PID: 7755 (master)
CGroup: /system.slice/postfix.service
├─7755 /usr/libexec/postfix/master -w ├─7756 pickup -l -t unix -u
├─7757 qmgr -l -t unix -u ├─7758 smtpd -n smtp -t inet -u -o
stress= ├─7759 proxymap -t unix
-u ├─7760 tlsmgr -l -t unix -u
   ├─7761 anvil -l -t unix -u
   ├─7763 trivial-rewrite -n rewrite -t unix -u
   ├─7764 spawn -z -n policy -t unix user=nobody
argv=/usr/libexec/postfix/policyd-spf /etc/policyd-spf/policyd-spf.conf
├─7765 /usr/bin/python /usr/libexec/postfix/policyd-spf 
/etc/policyd-spf/policyd-spf.conf
├─7766 cleanup -z -t unix -u └─7767 virtual -t unix
-

And proof it is working from an email header:
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
client-ip=66.163.187.148; helo=sonic316-22.consmr.mail.ne1.yahoo.com; 
envelope-from=m...@yahoo.com; receiver=m...@mydomain.com
 

accept email if pass SPF or DKIM

[li...@lazygranch.com]

RTFMing, I see that both opendkim and python-policyd-spf have
whitelisting capabilities (especially python-policyd-spf). But for the
most part, my legitimate incoming email passes DKIM or SPF, but often
not both. What I would like to do is accept email that passes either
DKIM or SPF, but the milters are not connected in anyway that I can
see. What I'm trying to avoid is setting up whitelists for each domain
based on which method of identity the sysop decided to implement.

Re: accept email if pass SPF or DKIM

[li...@lazygranch.com]

On Wed, 10 Jan 2018 21:59:26 -0500
"Kevin A. McGrail" <kmcgr...@pccc.com> wrote:

> On 1/10/2018 9:53 PM, li...@lazygranch.com wrote:
> > RTFMing, I see that both opendkim and python-policyd-spf have
> > whitelisting capabilities (especially python-policyd-spf). But for
> > the most part, my legitimate incoming email passes DKIM or SPF, but
> > often not both. What I would like to do is accept email that passes
> > either DKIM or SPF, but the milters are not connected in anyway
> > that I can see. What I'm trying to avoid is setting up whitelists
> > for each domain based on which method of identity the sysop decided
> > to implement.  
> That sounds like a problematic approach to me.
> 
> If an administrator of a domain sets up DNS for SPF records and then 
> fails, it should fail.
> If an administrator of a domain sets up DNS for DKIM records and that 
> fails, it should fail.
> 
> If an email is failing either, the administrator of the sending
> domain fails either, that indicates a problem.  Assuming your system
> isn't breaking DKIM, the sender really should be notified to resolve
> the issue.  Whitelisting would really open you up to problems.
> 
> Regards,
> KAM

I help with a few people I know that set up their own email to pass
SPF and DKIM, but realistically no major corporation is going to give a
sample of fecal matter to my opinion, presuming I could ever find the
person in charge.

Google is of the opinion that all you need is DKIM. Seems to me they
are correct, but we have to work with whatever the sysop wants to
implement. (Google provides SPF for their cloud servers as a means to
get the IP space. I see hacking from that space of course, so the list
comes in handy for blocking.)

Maybe there is a way to check DKIM first, then skip the SPF check. The
number of servers that only do SPF but not DKIM is small. I have one
contact whose email employs neither SPF or DKIM. That is plus.net. In
the spirit of making the world a better place, I will contact them and
see how far I get. 

Re: Request for feedback on SMTPD restrictions

[li...@lazygranch.com]

On Sun, 21 Jan 2018 14:35:42 -0600
Noel Jones  wrote:

> On 1/20/2018 11:56 PM, J Doe wrote:
> > Hi,
> > 
> > I have a basic SMTP server set up with what I believe to be good
> > smtpd_*_ restrictions, but I was wondering if anyone could provide
> > any insight on how to improve them or if I have been redundant in
> > the restrictions.  Even with reading the man pages, I find some of
> > the restrictions tricky.
> > 
> > I am eventually having a submission service (with an -o
> > smtpd_relay_restrictions=permit_sasl_authenticated in master.cf),
> > for this server but right now what follows is just for a SMTP
> > server on port 25.
> > 
> > smtpd_client_restrictions = permit_mynetworks,
> > reject_unauth_pipelining,
> > check_client_access hash:/etc/postfix/client_acl,
> > reject_unknown_client_hostname,
> > permit  
> 
> reject_unknown_client_hostname is likely to reject legit mail.  Use
> with caution.
> 
> Consider instead using reject_unknown_reverse_client_hostname, which
> rejects clients with no PTR record.  This is similar to what many
> large providers do and is fairly low risk.
> 
> The "permit" at the end is unnecessary, but doesn't break anything.
> Same with all the other "permit" in restrictions below.
> 
> > 
> > smtpd_helo_required = yes
> > smtpd_helo_restrictions = permit_mynetworks,
> > reject_unauth_pipelining,
> > reject_invalid_helo_hostname,
> > reject_non_fqdn_helo_hostname,
> > check_helo_access hash:/etc/postfix/helo_acl,
> > reject_unknown_helo_hostname,
> > permit  
> 
> reject_unknown_helo_hostname is likely to reject legit mail.  Use
> with caution.
> 
> 
> 
>   -- Noel Jones
> 
> > 
> > smtpd_sender_restrictions = permit_mynetworks,
> > reject_unauth_pipelining,
> > reject_non_fqdn_sender,
> > check_sender_access hash:/etc/postfix/sender_acl,
> > reject_unknown_sender_domain,
> > permit
> > 
> > smtpd_recipient_restrictions = permit_mynetworks,   
> > permit_auth_destination,
> >   
> > reject  
> >   
> > 
> >  
> > smtpd_relay_restrictions =
> > permit_mynetworks,
> > permit_auth_destination, reject
> > 
> > Thanks,
> > 
> > - J
> >   
> 

Doing some reading on the PTR record, I believe I've have been doing my
MX record incorrectly. The reverse DNS can only point to one domain
name. If you are hosting multiple domains on one server, all MX records
should point to the domain name that has the PTR record. 

For example, suppose the "main" domain of the server is example.com. In
this case, example.com has the PTR record. If you also host
something.com at the same IP address, the MX record for something.com
should point to example.com, not something.com.

https://serverfault.com/questions/158828/ptr-record-rdns-for-multiple-domains-on-a-shared-ip-address

Is my interpretation correct?

As an aside, note the superfluous "permit" shows up in many guides
online, but not all of them. I experimented dropping the extra permit
and things worked, but put them back in anyway out of paranoia. I'm
going to drop them now.

warning: TLS library problem

[li...@lazygranch.com]

postfix/smtpd[14755]: warning: TLS library problem: error:140760FC:SSL
routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:640:

Should I be blocking some encryption method? I thought openssl dropped
support for the hackable protocols.

Re: python-policyd-spf doesn't check mail from my own domain

[li...@lazygranch.com]

On Tue, 30 Jan 2018 10:50:18 +
Dominic Raferd <domi...@timedicer.co.uk> wrote:

> On 30 January 2018 at 10:11, li...@lazygranch.com
> <li...@lazygranch.com> wrote:
> > I've installed the opendmarc milter. I'm not rejecting mail from it
> > at the moment. I've noticed that if I send myself a message, the
> > policyd-spf milter isn't run. That in turn causes mail I send
> > myself to fail in opendmarc. Any ideas?
> >
> > The various email verifiers do show that my email passes spf.
> >
> > It is easy enough just to whitelist your own domains from opendmarc,
> > but that would allow spoofed email to get through.  
> 
> Which version of opendmarc? (opendmarc -V) If you have 1.3.2+ you can
> use opendmarc's own spf instead (SPFSelfValidate True) - not reliable
> for earlier versions though.
> 
> Anyway, in general:
> 
> /etc/opendmarc.conf:
> ...
> IgnoreAuthenticatedClients true
> IgnoreHosts /etc/postfix/opendmarc-ignorehosts.txt
> ...
> 
> /etc/opendkim.conf:
> ...
> InternalHosts /etc/postfix/opendmarc-ignorehosts.txt
> ...
> 
> /etc/postfix/opendmarc-ignorehosts.txt
> # emails from localhost are not authenticated but should be signed by
> opendkim and not tested by opendmarc
> 127.0.0.1
> # similarly any ips from which we accept unauthenticated originating
> emails (e.g. lan, or none)


opendmarc: OpenDMARC Filter v1.3.2
SMFI_VERSION 0x101
libmilter version 1.0.1
Active code options:
WITH_SPF
WITH_SPF2

I suppose it is dumb to check spf if authenticated, but then again dkim
is checked. 

I will work on the bypasses as suggested. I kind of like the
python-policyd-spf since...well...it is working. (Something that works
is something I don't like to change.)

Still I wonder what part of the email food chain determines that spf
wasn't needed. I commented out the local reference in
pythod-policyd-spf, but that didn't change anything.

Lots of spam gets marked as fail in opendmarc. I can't wait to start
"trusting" it. 

Re: python-policyd-spf doesn't check mail from my own domain

[li...@lazygranch.com]

On Wed, 31 Jan 2018 07:43:17 + (UTC)
Dominic Raferd <domi...@timedicer.co.uk> wrote:

> On 31 January 2018 at 03:44, li...@lazygranch.com
> <li...@lazygranch.com> wrote:
> > On Tue, 30 Jan 2018 10:50:18 +
> > Dominic Raferd <domi...@timedicer.co.uk> wrote:
> >  
> >> On 30 January 2018 at 10:11, li...@lazygranch.com
> >> <li...@lazygranch.com> wrote:  
> >> > I've installed the opendmarc milter. I'm not rejecting mail from
> >> > it at the moment. I've noticed that if I send myself a message,
> >> > the policyd-spf milter isn't run. That in turn causes mail I send
> >> > myself to fail in opendmarc. Any ideas?
> >> >
> >> > The various email verifiers do show that my email passes spf.
> >> >
> >> > It is easy enough just to whitelist your own domains from
> >> > opendmarc, but that would allow spoofed email to get through.  
> >>
> >> Which version of opendmarc? (opendmarc -V) If you have 1.3.2+ you
> >> can use opendmarc's own spf instead (SPFSelfValidate True) - not
> >> reliable for earlier versions though.
> >>
> >> Anyway, in general:
> >>
> >> /etc/opendmarc.conf:
> >> ...
> >> IgnoreAuthenticatedClients true
> >> IgnoreHosts /etc/postfix/opendmarc-ignorehosts.txt
> >> ...
> >>
> >> /etc/opendkim.conf:
> >> ...
> >> InternalHosts /etc/postfix/opendmarc-ignorehosts.txt
> >> ...
> >>
> >> /etc/postfix/opendmarc-ignorehosts.txt
> >> # emails from localhost are not authenticated but should be signed
> >> by opendkim and not tested by opendmarc
> >> 127.0.0.1
> >> # similarly any ips from which we accept unauthenticated
> >> originating emails (e.g. lan, or none)  
> >
> >
> > opendmarc: OpenDMARC Filter v1.3.2
> > SMFI_VERSION 0x101
> > libmilter version 1.0.1
> > Active code options:
> > WITH_SPF
> > WITH_SPF2
> >
> > I suppose it is dumb to check spf if authenticated, but then again
> > dkim is checked.
> >
> > I will work on the bypasses as suggested. I kind of like the
> > python-policyd-spf since...well...it is working. (Something that
> > works is something I don't like to change.)
> >
> > Still I wonder what part of the email food chain determines that spf
> > wasn't needed. I commented out the local reference in
> > pythod-policyd-spf, but that didn't change anything.
> >
> > Lots of spam gets marked as fail in opendmarc. I can't wait to start
> > "trusting" it.  
> 
> It shouldn't be a problem to continue using python-policyd-spf. You
> would expect it to give a fail when testing mail from authenticated
> clients. Opendkim needs to run in such cases not to test them but to
> add the dkim header.
> 
> I use opendmarc (obvs) but I have to say I don't see it blocking many
> emails. Looking at my records over a few months: 38000 mails came
> through of which 50 were rejected by opendmarc and 30 quarantined. Of
> those 80, 34 appear to have come via mailing lists (including
> postfix.org) so may just reflect senders using the mailing list but
> with incompatible dmarc settings on their domain. The reality is that
> comparatively few domains are set up with dmarc and with p=reject (or
> p=quarantine). If you see a large number of opendmarc fails (in
> opendmarc log: action!=2) then I fear there is something wrong with
> your setup.
> 
> Here is my entire opendmarc.conf:
> 
> PidFile /var/run/opendmarc/opendmarc.pid
> RejectFailures true
> Syslog true
> UMask 0002
> UserID opendmarc:opendmarc
> PublicSuffixList /usr/share/publicsuffix/public_suffix_list.dat
> IgnoreAuthenticatedClients true
> AuthservID  myauthserv.tld
> AuthservIDWithJobID yes
> IgnoreHosts /etc/postfix/opendmarc-ignorehosts.txt
> Socket inet:8893@localhost
> HistoryFile /var/tmp/opendmarc.log
> RecordAllMessages True
> # ignore any external spf results
> SPFIgnoreResults True
> # use internal spf checker
> SPFSelfValidate True
> 
> and the matching /etc/opendkim.conf:
> 
> Syslog yes
> SyslogSuccess yes
> UMask 0002
> Canonicalization relaxed/relaxed
> OversignHeaders From
> InternalHosts /etc/postfix/opendmarc-ignorehosts.txt
> Domain mydomain1.tld,mydomain2.tld,mydomain3.tld
> KeyFile /etc/mail/dkim.key
> Selector mail
> Statistics /tmp/dkim-stats
> AuthservID myauthserv.tld
> AlwaysAddARHeader yes
> 
> I used postfix-policyd-spf-python until recently and these were my
> settings

python-policyd-spf doesn't check mail from my own domain

[li...@lazygranch.com]

I've installed the opendmarc milter. I'm not rejecting mail from it at
the moment. I've noticed that if I send myself a message, the
policyd-spf milter isn't run. That in turn causes mail I send myself to
fail in opendmarc. Any ideas?

The various email verifiers do show that my email passes spf.

It is easy enough just to whitelist your own domains from opendmarc,
but that would allow spoofed email to get through.

Re: policyd-spf tip

[li...@lazygranch.com]

I figured I would middle post, so skip down a bit.

On Mon, 25 Dec 2017 11:56:02 -0800
Gao <g...@pztop.com> wrote:

> I quickly checked my policyd-spf setting after read your email. I 
> noticed that the policyd-spf in my system is not running as a service.
> 
> I guess you are using debian. I am using CentOS7 and I installed 
> pypolicyd-spf from EPEL. So is there a big advantage to running it as
> a daemon service? How do I enable it as a service? Obviously yum
> install doesn't take care of the service setup.
> 
> Gao

I'm on Centos 7. This is my uname -a.
Linux servername 3.10.0-693.11.1.el7.x86_64 #1 SMP Mon Dec 4 23:52:40
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Looking at ps aux, policyd-spf is not running. In the strict sense,
that means it is not a daemon.
https://en.wikipedia.org/wiki/Daemon_(computing)
However all references to policyd and policyd-spf are as daemons.  

I'm new to Centos. I run opensuse on my desktop and had presently have
my VPS server on FreeBSD. Due to update issues, I decided to abandon
FreeBSD for Centos, since I'm more familiar with Linux than BSD these
days.



> 
> On 2017-12-24 22:02, li...@lazygranch.com wrote:
> > There are many "problem solving pages" on the interwebs that have
> > wrong information on setting up policyd-spf. The key to make sure
> > you use consistent names in both main.cf and master.cf. Yeah, I
> > know, I'm preaching to the choir, but hopefully the next person
> > with a set up problem finds this message in a search.
> > 
> > In master.cf:
> > policyunix  -   n   n   -   0   spawn
> >  user=nobody  argv=/usr/libexec/postfix/policyd-spf
> > /etc/policyd-spf/policyd-spf.conf
> > 
> > Note you need to make sure the conf file location is correct.
> > 
> > In main.cf:
> > smtpd_recipient_restrictions =
> >   permit_sasl_authenticated,
> >   permit_mynetworks,
> >   reject_unauth_destination,
> >   reject_rbl_client zen.spamhaus.org,
> >   check_policy_service unix:private/policy,
> >   permit
> > 
> > policy_time_limit = 3600
> > 
> > The word "policy" needs to be consistent in all three locations. For
> > example, this would be wrong:
> >   check_policy_service unix:private/policyd-spf,
> > 
> > Also wrong would be:
> > policyd_time_limit = 3600
> > 
> > 
> > In postfix, systemctl status postfix should indicate the policyd-spf
> > daemon was started:
> > 
> > ● postfix.service - Postfix Mail Transport
> > Agent Loaded: loaded (/usr/lib/systemd/system/postfix.service;
> > enabled; vendor preset: disabled) Active: active (running) since
> > Mon 2017-12-25 05:28:11 UTC; 16s ago Process: 7661
> > ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)
> > Process: 7681 ExecStart=/usr/sbin/postfix start (code=exited,
> > status=0/SUCCESS) Process: 7679
> > ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited,
> > status=0/SUCCESS) Process: 7677
> > ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited,
> > status=0/SUCCESS) Main PID: 7755 (master)
> > CGroup: /system.slice/postfix.service
> > ├─7755 /usr/libexec/postfix/master -w ├─7756 pickup -l -t unix -u
> > ├─7757 qmgr -l -t unix -u ├─7758 smtpd -n smtp -t inet -u -o
> > stress= ├─7759 proxymap -t unix -u ├─7760 tlsmgr -l -t unix -u
> >├─7761 anvil -l -t unix -u
> >├─7763 trivial-rewrite -n rewrite -t unix -u
> >├─7764 spawn -z -n policy -t unix user=nobody
> > argv=/usr/libexec/postfix/policyd-spf /etc/policyd-spf/policyd-spf.conf
> > ├─7765 /usr/bin/python /usr/libexec/postfix/policyd-spf
> > /etc/policyd-spf/policyd-spf.conf
> > ├─7766 cleanup -z -t unix -u └─7767 virtual -t unix
> > -
> > 
> > And proof it is working from an email header:
> > Received-SPF: Pass (sender SPF authorized) identity=mailfrom;
> > client-ip=66.163.187.148;
> > helo=sonic316-22.consmr.mail.ne1.yahoo.com;
> > envelope-from=m...@yahoo.com; receiver=m...@mydomain.com  

Requesting certificates

[li...@lazygranch.com]

I'm not at the point where I want to verify certs and reject mail,
because the mail must go through! However I would like at least
for postfix to request the cert. (Forgive my terminology here if I am
not phrasing this properly.) Basically I would just eyeball the header
and look at the cert request on a case by case basis.

Here is a part of an email header from an email that I sent myself
(sanitized to stay off google)

Received: from mydomain.com (unknown [myipaddress])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by www.example.com (Postfix) with ESMTPSA id 1604469A2A
 for ; Fri, 22 Dec 2017 09:01:13 + (UTC)
---

From master.cf, with the emphasis on the last line:
--
submission inet n   -   n   -   -   smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_recipient_restrictions=
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_tls_ask_ccert=yes
---

From main.cf (sanitized):

# TLS
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_key_file = /etc/letsencrypt/live/mydomain.com/privkey.pem
smtpd_tls_cert_file = /etc/letsencrypt/live/mydomain.com/fullchain.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
#next line experimental
smtpd_tls_ask_ccert = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
--

My reasoning here being since I have a real (enough) cert from a CA rather than 
a self-signed one, I should be able to let the recipient's MTA sniff my cert.

I suppose if this is dumb I'm going to find out. ;-) 

Re: Requesting certificates

[li...@lazygranch.com]

On Fri, 22 Dec 2017 09:52:13 +
Dominic Raferd <domi...@timedicer.co.uk> wrote:

> On 22 December 2017 at 09:38, li...@lazygranch.com
> <li...@lazygranch.com> wrote:
> 
> > ​...
> > From main.cf (sanitized):
> > 
> > # TLS
> > smtpd_use_tls = yes
> > ​​
> > smtpd_tls_security_level = may
> > smtpd_tls_auth_only = yes
> > smtpd_tls_key_file = /etc/letsencrypt/live/mydomain.com/privkey.pem
> > smtpd_tls_cert_file
> > = /etc/letsencrypt/live/mydomain.com/fullchain.pem
> > smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes
> > #next line experimental
> > ​​
> > smtpd_tls_ask_ccert = yes
> > smtpd_tls_session_cache_timeout = 3600s
> > tls_random_source = dev:/dev/urandom  
> 
> 
> BTW, smtpd_use_tls = yes is deprecated for Postfix 2.3+: ​
> ​
> smtpd_tls_security_level = may achieves the same thing.

Thanks. I just commented out the line and everything works the same. 
I have 
compatibility_level = 2
in the main.cf. 

Re: report from google relate to failed dkim

[li...@lazygranch.com]

On Wed, 27 Dec 2017 09:37:24 +
Dominic Raferd  wrote:

> On 27 December 2017 at 07:22, Poliman - Serwis 
> wrote:
> > I configured yesterday spf, dkim, dmarc for example.com. Today I
> > got report in xml on my mailbox. Attached. One from addresses has
> > dkim failed - marked in orange...  
> 
> This is a DMARC report from Gmail and so a more appropriate place to
> ask about it is the opendmarc mailing list
> http://www.trusteddomain.org/mailman/listinfo/opendmarc-users. The
> google link within the report that you attached gives a bit more
> information. The report says that Gmail received one email purporting
> to be from your domain, it passed the spf test and failed the dkim
> test. If you are confident that this was a legitimate email (it came
> from or via 200.150.100.50, unless you obfuscated this), then either
> there is a problem with your dkim setup or this email bypassed it
> entirely.
> 
> DMARC reports from mail providers are very useful in checking for
> problems with spf/dkim/dmarc before one moves to p=reject. Consider
> using one of the services that receive and collate these reports for
> you, it makes them easier to understand.

I decided not to set up DMARC on my new server since the logs are
pretty overwhelming. What service would you suggest? 

BTW the OP should use this to verify the setup:
http://dkimvalidator.com/

There are a bunch of similar services, but I like the output on this
one.

I had some spammer try to spoof my email address and got a bounced
message because my they used my email address in the return. That was
a SPF rejection, but still nice to see the system working.
 

Re: Request for feedback on SMTPD restrictions

[li...@lazygranch.com]

Replies in the middle of the email for clarity.
On Mon, 22 Jan 2018 17:18:42 -0500
"Bill Cole" <postfixlists-070...@billmail.scconsult.com> wrote:

> On 21 Jan 2018, at 20:44 (-0500), li...@lazygranch.com wrote:
> 
> > The reverse DNS can only point to one domain
> > name.  
> 
> Not so. Multiple PTR records for one address may violate some
> people's expectations, but it's not wrong if the address doesn't
> really have a public name that is more "real" than the others.
> 

OK, on Digital Ocean, you only get one reverse DNS per "droplet". 

So if I do a reverse DNS lookup on some IP addresses, I will get
multiple domains?
> > If you are hosting multiple domains on one server,  
> 
> Niggle: not one server, one IP address. A server can have many IP 
> addresses and there's a long history of people asking here how to
> make Postfix use specific IPs for specific domains, for essentially
> cosmetic reasons. The multi-instance support mostly ended that FAQ.

Yeah, I screwed up. 
> 
> > all MX records
> > should point to the domain name that has the PTR record.  
> 
> That really makes no difference. It is arguably good practice to have
> a PTR reversing every A record but simplicity is arguably more
> important, so having just one A and one PTR for each name/IP pair is
> fine, even if that IP is handling mail for many domains.
> 

And in practice, doing it wrong doesn't seem to stop the email from
going out.

As it turns out, between the two Digital Ocean droplets I'm running
(the one I'm on now and the new one I'm setting up), none have the
reverse DNS set up properly. Reading the postfix documentation, all
that is required is a reverse DNS point to something. There doesn't
have to be a match. 

"reject_unknown_reverse_client_hostname
Reject the request when the client IP address has no address->name
mapping."

I put in a few "features" from this website:
http://en.linuxreviews.org/HOWTO_Stop_spam_using_Postfix
This link is similar, though he suggests fail2ban. I find the anvil
code works good enough. 
http://centosfaq.org/centos/sasl-attacks-and-spam/

Comments appreciated. I generally just trawl this list and makes
changes as people suggest. Or not change anything as Viktor always
suggests. ;-)

# SASL
smtpd_sasl_type = dovecot
broken_sasl_auth_clients = yes
smtpd_helo_required = yes
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions = 
  permit_sasl_authenticated, 
  permit_mynetworks, 
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_non_fqdn_recipient,
  reject_rbl_client rhsbl.scientificspam.net,
  reject_rbl_client bl.spamcop.net,
  reject_rbl_client cbl.abuseat.org,
  reject_rbl_client b.barracudacentral.org,
  reject_rbl_client ix.dnsbl.manitu.net,
  reject_rbl_client rabl.nuclearelephant.com,
  reject_rbl_client zen.spamhaus.org,
  check_policy_service unix:private/policy
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources
smtpd_sender_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_address,
  check_sender_access hash:/etc/postfix/spamsources
smtpd_relay_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_policy_service unix:private/policy
#lines added after hacker attack
smtpd_error_sleep_time = 2s
smtpd_soft_error_limit = 3
smtpd_hard_error_limit = 6
smtpd_client_connection_rate_limit = 3
smtpd_client_auth_rate_limit = 20
smtpd_client_connection_count_limit = 3
smtpd_client_new_tls_session_rate_limit = 3
smtpd_client_recipient_rate_limit = 3
smtpd_recipient_limit = 14

Spammer rejected, but resends every 10 minutes. Any way to prevent this

[li...@lazygranch.com]

I'm getting hit every 10 minutes from this spammer. As you can see I am
rejecting the message. I wonder if the offending email server doesn't
know the message is being rejected? 

Mar 13 23:28:58 centos-1gb-sfo1-01 postfix/smtpd[22153]: NOQUEUE:
reject: RCPT from unknown[113.247.6.67]: 450 4.7.1 Client host
rejected: cannot find your reverse hostname, [113.247.6.67];
from=<sale...@tradepro.net> to=<li...@lazygranch.com> proto=ESMTP
helo=

Re: Spammer rejected, but resends every 10 minutes. Any way to prevent this

[li...@lazygranch.com]

On Tue, 13 Mar 2018 23:35:01 -0400
"Bill Cole" <postfixlists-070...@billmail.scconsult.com> wrote:

> On 13 Mar 2018, at 22:51 (-0400), li...@lazygranch.com wrote:
> 
> > I'm getting hit every 10 minutes from this spammer. As you can see
> > I am
> > rejecting the message. I wonder if the offending email server
> > doesn't know the message is being rejected?  
> 
> It's not being rejected, it's being deferred.
> 
> > Mar 13 23:28:58 centos-1gb-sfo1-01 postfix/smtpd[22153]: NOQUEUE:
> > reject: RCPT from unknown[113.247.6.67]: 450 4.7.1 Client host
> > rejected: cannot find your reverse hostname, [113.247.6.67];
> > from=<sale...@tradepro.net> to=<li...@lazygranch.com> proto=ESMTP
> > helo=  
> 
> A '450' response code is explicitly telling the client to try again 
> later.
> 
> If you are using reject_unknown_reverse_client_hostname, it is mostly 
> safe to set unknown_client_reject_code to '550' instead of the
> default '450' but if you are using reject_unknown_client_hostname
> (which is unsafe for most sites) you should not.
> 
> OR: if you don't get any legitimate mail from Hunan, Chongqing, or
> Hong Kong you can probably safely block 113.240.0.0/12 from talking
> at all to your SMTP port (or just the /13 to limit it to Hunan.)
> 

I knew it had to be something stupid I was doing since the spammers
behaved when blocked by the RBLs. I am using
reject_unknown_reverse_client_hostname, 
so I set the code to 550 as you indicated and will see how that works.

It also now occurs to me that the MX Tools website can be use to see
what annoying IP or host can be blocked by a particular RBL. I've
obviously used the MX Tools blacklist checker for my own domains and IP,
but not for other servers. The offending IP is on eight blocking lists.

Thanks all.

Re: clamav as a milter

[li...@lazygranch.com]

On Mon, 26 Mar 2018 18:35:19 -0400
Scott Kitterman  wrote:

> On Monday, March 26, 2018 10:27:57 PM André Rodier wrote:
> > Hello all,
> > 
> > Does anyone suffered performance loss when using clamav as a milter
> > for postfix?
> > 
> > I would like to scan archives and emails with attachments. Is there
> > any other way to do than using a milter?
> > 
> > Thanks for your advices.  
> 
> I use http://thewalter.net/stef/software/clamsmtp/ - it hasn't been
> updated in a long time, but it does what it needs to do.
> 
> Scott K

I stopped using clamav when I set up my new server due to amavisd-new
stalling once in a while on my former freeBSD server. Is this one
bulletproof?

repeated relay attempts

[li...@lazygranch.com]

Just checking if I have things set up correctly. I'm returning a 554
code (rejected relay) yet the attempts keep coming. 

Postfix avil is throttling the user, so I assume this isn't a problem.

As an FYI, checking MXTOOL blacklist on the offending IP, only
blocklist.de has them flagged at the moment.

A snippet of postfix log with my domain altered to stay off google:
--
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26199]: connect from 
hwsrv-230330.hostwindsdns.com[104.168.137.238]
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26199]: NOQUEUE: reject: RCPT 
from hwsrv-230330.hostwindsdns.com[104.168.137.238]: 554 5.7.1 
<1029mandadi...@gmail.com>: Relay access denied; from= 
to=<1029mandadi...@gmail.com> proto=ESMTP helo=
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26199]: lost connection after 
RCPT from hwsrv-230330.hostwindsdns.com[104.168.137.238]
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26199]: disconnect from 
hwsrv-230330.hostwindsdns.com[104.168.137.238] ehlo=1 mail=1 rcpt=0/1 
commands=2/3
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26188]: connect from 
hwsrv-230330.hostwindsdns.com[104.168.137.238]
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26188]: NOQUEUE: reject: RCPT 
from hwsrv-230330.hostwindsdns.com[104.168.137.238]: 554 5.7.1 
<1029mandadi...@gmail.com>: Relay access denied; from= 
to=<1029mandadi...@gmail.com> proto=ESMTP helo=
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26188]: lost connection after 
RCPT from hwsrv-230330.hostwindsdns.com[104.168.137.238]
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26188]: disconnect from 
hwsrv-230330.hostwindsdns.com[104.168.137.238] ehlo=1 mail=1 rcpt=0/1 
commands=2/3
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26199]: connect from 
hwsrv-230330.hostwindsdns.com[104.168.137.238]
Mar 17 23:00:32 centos-1gb-sfo1-01 postfix/smtpd[26199]: warning: Connection 
rate limit exceeded: 4 from hwsrv-230330.hostwindsdns.com[104.168.137.238] for 
service smtp

Re: manitu.net RBL, opinions? Re: postwhite? (why not?)

[li...@lazygranch.com]

On Tue, 06 Mar 2018 06:26:49 +
MRob  wrote:

> On 2018-03-05 18:05, Bill Cole wrote:
> >> Would you mind sharing which RBLs you recommend to use in
> >> postscreen?  
> > 
> > postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.2*2
> > zen.spamhaus.org=127.0.0.3*2 zen.spamhaus.org=127.0.0.4*2
> > zen.spamhaus.org=127.0.0.10*2 zen.spamhaus.org=127.0.0.11*2
> > psbl.surriel.com=127.0.0.2*1 ix.dnsbl.manitu.net=127.0.0.2*1  
> 
> I just learned of manitu.net RBL is it helpful? Bill you don't use 
> things like barracuda.net, spamcop, whatever that monkey one is, 
> mailspike. Is manitu a good replacement for all those?

Just a FYI, my experience is manitu periodically blocks hostgator email.
I had to remove it from my list. 

If you want to check your logs to see if you receive email from
hostgator, all my email from hostgator has come from websitewelcome.com,
but here is the official documentation:
http://support.hostgator.com/articles/what-are-private-name-servers

FWIW, I use barracuda.net.

concurrency rate limit

[li...@lazygranch.com]

I'm wondering if I have my rate limiting set up correctly. Note I have
that perl script that sniffs out dynamic IP addresses, so I am not sure
how this user is even getting concurrent connections.

From the main.cf:
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources
smtpd_sender_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_address,
  check_sender_access hash:/etc/postfix/spamsources
smtpd_relay_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_policy_service unix:private/policy
#lines added after hacker attack
smtpd_error_sleep_time = 2s
smtpd_soft_error_limit = 3
smtpd_hard_error_limit = 6
smtpd_client_connection_rate_limit = 3
smtpd_client_auth_rate_limit = 20
smtpd_client_connection_count_limit = 3
smtpd_client_new_tls_session_rate_limit = 3
smtpd_client_recipient_rate_limit = 40
smtpd_recipient_limit = 20


From the maillog:
Jan 10 08:39:32 mydomain postfix/smtpd[29789]: connect from 
unknown[121.238.5.110]
Jan 10 08:39:32 mydomain postfix/smtpd[29789]: warning: Connection concurrency 
limit exceeded: 4 from unknown[121.238.5.110] for service smtp
Jan 10 08:39:32 mydomain postfix/smtpd[29789]: disconnect from 
unknown[121.238.5.110] commands=0/0
Jan 10 08:39:32 mydomain postfix/smtpd[29783]: warning: hostname 
110.5.238.121.broad.nt.js.dynamic.163data.com.cn does not resolve to address 
121.238.5.110: Name or service not known
Jan 10 08:39:32 mydomain postfix/smtpd[29783]: connect from 
unknown[121.238.5.110]
Jan 10 08:39:32 mydomain postfix/smtpd[29783]: warning: Connection concurrency 
limit exceeded: 4 from unknown[121.238.5.110] for service smtp
Jan 10 08:39:32 mydomain postfix/smtpd[29783]: disconnect from 
unknown[121.238.5.110] commands=0/0
Jan 10 08:39:32 mydomain postfix/smtpd[29786]: lost connection after AUTH from 
unknown[121.238.5.110]
Jan 10 08:39:32 mydomain postfix/smtpd[29786]: disconnect from 
unknown[121.238.5.110] ehlo=1 auth=0/1 commands=1/2
Jan 10 08:39:32 mydomain postfix/smtpd[29790]: warning: hostname 
110.5.238.121.broad.nt.js.dynamic.163data.com.cn does not resolve to address 
121.238.5.110: Name or service not known
Jan 10 08:39:32 mydomain postfix/smtpd[29790]: connect from 
unknown[121.238.5.110]
Jan 10 08:39:32 mydomain postfix/smtpd[29790]: warning: Connection rate limit 
exceeded: 10 from unknown[121.238.5.110] for service smtp
Jan 10 08:39:32 mydomain postfix/smtpd[29790]: disconnect from 
unknown[121.238.5.110] commands=0/0
Jan 10 08:39:32 mydomain postfix/smtpd[29785]: warning: hostname 
110.5.238.121.broad.nt.js.dynamic.163data.com.cn does not resolve to address 
121.238.5.110: Name or service not known
Jan 10 08:39:32 mydomain postfix/smtpd[29785]: connect from 
unknown[121.238.5.110]
Jan 10 08:39:32 mydomain postfix/smtpd[29785]: warning: Connection rate limit 
exceeded: 11 from unknown[121.238.5.110] for service smtp

Re: Stopping acceptence from unowned networks address as from my domains

[li...@lazygranch.com]

On Thu, 7 Feb 2019 05:24:08 +0100
Francesc Peñalvez  wrote:

> I asked  the same and Vietse Venema answer this:
> 
> Postfix 3.0 and later:
> 
> /etc/postfix/main.cf:
>   smtpd_sender_restrictions =
>   permit_mynetworks
>   permit_sasl_authenticated
>   check_sender_access inline:{
>   { example.com = REJECT local sender from unauthorized 
> client }
>   { other.example = REJECT local sender from unauthorized 
> client }
>   }
> 
> Instead of example.com and other.example, specify your email domains.
> 
> Note: this breaks email from remote mail forwarders or from remote
> distribution lists that don't reset the sender address.
> 
> 
> this worked perfectly for me
> 
> *
> Este mensaje y todos los archivos adjuntos son confidenciales y de
> uso exclusivo por parte de su/sus destinatario/s. Si usted ha
> recibido este mensaje por error, le agradecemos que lo notifique
> inmediatamente al remitente y destruya el mensaje. Queda prohibida
> cualquier modificación, edición, uso o divulgación no autorizados. El
> Emisor no se hace responsable de este mensaje si ha sido modificado,
> distorsionado, falsificado, infectado por un virus o editado o
> difundido sin autorización.
> 
> 
> ***
> This message and any attachments are confidential and intended for
> the named addressee(s) only. If you have received this message in
> error, please notify immediately the sender, then delete the message.
> Any unauthorized modification, edition, use or dissemination is
> prohibited. The sender shall not be liable for this message if it has
> been modified, altered, falsified, infected by a virus or even edited
> or disseminated without authorization.
> ***
> 
> El 07/02/2019 a las 2:44, Ruben Safir escribió:
> > I got this email, which I thought I set up postfix to block
> >  
> > >From ru...@mrbrklyn.com  Wed Feb  6 06:26:12 2019  
> > Return-Path: 
> > X-Original-To: ru...@mrbrklyn.com
> > Delivered-To: ru...@mrbrklyn.com
> > Received: from mail.isentia.asia (mail.mediabanc.ws
> > [203.223.144.88]) by mrbrklyn.com (Postfix) with ESMTP id
> > BE463161132 for ; Wed,  6 Feb 2019 06:25:50
> > -0500 (EST) Received: from fixed-187-189-92-126.totalplay.net
> > (187.189.92.126) by mail.mediabanc.ws (10.61.3.33) with Microsoft
> > SMTP Server id 8.1.240.5; Wed,
> >  6 Feb 2019 15:36:09 +0800
> > From: BSM 
> > To: ru...@mrbrklyn.com
> > Subject: Directorio Empresarial Mexicano 2019
> > Date: Wed, 6 Feb 2019 01:40:06 -0600
> > Message-ID: <20190206014006.8f2d6192f98f7...@mrbrklyn.com>
> > MIME-Version: 1.0
> > Content-Type: text/html; charset="iso-8859-1"
> > Content-Transfer-Encoding: quoted-printable
> > X-UID: 55347
> > Status: RO
> > Content-Length: 36872
> > Lines: 561
> >
> > This is addressed as me in the From line and came from outside my
> > local network
> >
> > I want domain being accepted From my domain only is it comes from
> > within the local network
> >  
> 

I'm having trouble finding check_sender_access AND inline. Is inline
some way of not using hash? For example, I have:

  check_sender_access hash:/etc/postfix/sender_checks,

Maybe I'm using this wrong. I have this set up to whitelist addresses.
That is my sender_checks looks like

goodper...@ok.com OK

I'm not using this to reject anything.

Re: How to block mail coming from a domain

[li...@lazygranch.com]

On Thu, 26 Sep 2019 10:46:27 +0200
Enrico Morelli  wrote:

> On Thu, 26 Sep 2019 10:42:46 +0200
> Enrico Morelli  wrote:
> 
> > On Thu, 26 Sep 2019 16:37:14 +0800
> > Wesley Peng  wrote:
> > 
> > > on 2019/9/26 16:34, Enrico Morelli wrote:  
> > > > I tried to put .monster or *.monster in sender_access but
> > > > doesn't work. Is there a way to block *.monster mails?
> > > 
> > > Can you setup spamassassin for domain blacklist?
> > > 
> > > regards.  
> > 
> > How can do that?
> > 
> 
> In /etc/spamassassin/local.cf I putted:
> 
> blacklist_from *.monster
> 
> Is it correct?
> 

I have been doing the following. 

In the main.cf, note the spamsources:

smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources
smtpd_sender_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_address,
  check_sender_access hash:/etc/postfix/spamsources

I have a file called spamsources. The basis pattern is a tld, 500, and
a friendly message:

--
stream 500 your message
download 500 your message
top 500 your message
xyz 500 your message
---

You need to postmap the file to make spamsources.db

These goofy tlds are cheap to buy, hence a spam source.
http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Block email based on reply field

[li...@lazygranch.com]

I have a spammer who uses all sorts of "from" addresses but the same
"reply" address. Any way to block this spammer in Postfix. 

Re: Centos 7 turn on pypolicyd-spf

[li...@lazygranch.com]

FWIW, this is what I have in my master.cf. I am on centos 7.

policyunix  -   n   n   -   0   spawn
 user=nobody
 argv=/usr/libexec/postfix/policyd-spf 
/etc/python-policyd-spf/policyd-spf.conf

Re: Block email based on reply field

[li...@lazygranch.com]

On Wed, 11 Dec 2019 21:56:48 -0500
Viktor Dukhovni  wrote:

> > On Dec 11, 2019, at 9:38 PM, li...@lazygranch.com wrote:
> > 
> > I have a spammer who uses all sorts of "from" addresses but the same
> > "reply" address. Any way to block this spammer in Postfix.  
> 
>   main.cf:
>   pcre = pcre:${config_directory}/
>   header_checks = ${pcre}header-checks.pcre
>   # Set empty, or keep existing non-default value
>   nested_header_checks =
>   mime_header_checks =
> 
>   header-checks.pcre:
> if /^Reply-To:/
> # Adjust to exactly match the observed header
> # Includes rule id in reject message
> /[:\s<]spammer@example\.net[>\s]/ REJECT 5.7.1 Access
> denied R0001 /^/  DUNNO no more
> Reply-To rules endif
> 

Well I tried this with no luck. Here are my comments:
1) I don't understand this line:
pcre = pcre:${config_directory}/
Doing a search I can't find this line used. However I think my pcre is
working anyway. Within my main.cf, I have the line:

header_checks = pcre:/etc/postfix/header_checks.pcre


2) I RTFM postfix section on header_checks and did a few tests to see
if they are working. The first one I did was put a long sequence of
letters and numbers similar to a password to be detected in the
subject line. Inside header_checks.pcre, I added this line:
/^Subject: moDjbQje7duHkYI0TNc/ REJECT

Sending an email with that sequence to my server did bounce the
message. Incidentally I am doing these tests from a yahoo email account
rather than my own domain.

3) I found no way to spoof the reply-to field from yahoo email. But as
a test, I decided to block my yahoo email from my own email server.
Here is the line in header_checks.pcre:

if /^From:/
/[:\s<]me@yahoo\.com[>\s]/ REJECT 1.1.1
endif

This did bounce the message.

4) Here is the entry to reject the reply-to:

if /^Reply-To:/
/[:\s<]damnspammer\.org[>\s]/ REJECT
endif

That was a shortened version from Viktor's suggestion. Howver I had
also used:

if /^Reply-To:/
# Adjust to exactly match the observed header
# Includes rule id in reject message
/[:\s<]reply@mysecuritycamera\.org[>\s]/   REJECT 5.7.1 Access
denied R0001
/^/DUNNO no more Reply-To rules
endif

Excuse the word wrap due to the Claws. Note that every time I changed
the header_checks.pcre file I did a 
systemctl reload postfix
systemctl restart postfix

Having no way to send the spoofed Reply-To line, I waited for spam to
arrive. And of course I wasn't disappointed. 

I will supply the sanitized versions of the maillog and the received
email header from Claws. (Sanitized due to google. No use having my
real domain in the message.)

From Claws email header:

-
Return-Path: 
X-Original-To: m...@mydomain.com
Delivered-To: m...@mydomain.com
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
client-ip=1.2.3.4; helo=trump.damnspammer.org; 
envelope-from=bou...@trump.damnspammer.org; receiver=m...@mydomain.com 
DMARC-Filter: OpenDMARC Filter v1.3.2 www.mydomain.com 5C82C6F591
Authentication-Results: mydomain.com; dmarc=none (p=none dis=none) 
header.from=dog.cat.jp
Authentication-Results: mydomain.com; spf=pass 
smtp.mailfrom=bou...@trump.damnspammer.org
DKIM-Filter: OpenDKIM Filter v2.11.0 www.mydomain.com 5C82C6F591
Received: from trump.damnspammer.org (ec.compute.amazonaws.com [1.2.3.4])
 by www.mydomain.com (Postfix) with ESMTP id 5C82C6F591
 for ; Tue, 17 Dec 2019 22:35:52 + (UTC)
MIME-Version: 1.0
From: "oxygen flow" to your begonia  !
Subject: "oxygen flow" fruits for better garden performance
Reply-To: re...@damnspammer.org
To: m...@mydomain.com
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"


From /var/log/maillog:

--
Dec 17 22:35:51 mydomain postfix/smtpd[28909]: connect from 
ec.compute.amazonaws.com[1.2.3.4]
Dec 17 22:35:53 mydomain policyd-spf[28914]: spfcheck: pyspf result: "['Pass', 
'sender SPF authorized', 'helo']"
Dec 17 22:35:53 mydomain policyd-spf[28914]: Pass; identity=helo; 
client-ip=1.2.3.4; helo=trump.damnspammer.org; 
envelope-from=bou...@trump.damnspammer.org; receiver=m...@mydomain.com
Dec 17 22:35:53 mydomain policyd-spf[28914]: spfcheck: pyspf result: "['Pass', 
'sender SPF authorized', 'mailfrom']"
Dec 17 22:35:53 mydomain policyd-spf[28914]: Pass; identity=mailfrom; 
client-ip=1.2.3.4; helo=trump.damnspammer.org; 
envelope-from=bou...@trump.damnspammer.org; receiver=m...@mydomain.com
Dec 17 22:35:53 mydomain postfix/smtpd[28909]: 5C82C6F591: 
client=ec.compute.amazonaws.com[1.2.3.4]
Dec 17 22:35:53 mydomain postfix/cleanup[28915]: 5C82C6F591: message-id=<>
Dec 17 22:35:53 mydomain opendkim[1272]: 5C82C6F591: ec.compute.amazonaws.com 
[1.2.3.4] not internal
Dec 17 22

Re: Block email based on reply field

[li...@lazygranch.com]

On Wed, 18 Dec 2019 13:10:50 -0500
Viktor Dukhovni  wrote:

> [ I'm on the list, there's no need to Cc: me directly]
> 
> On Wed, Dec 18, 2019 at 01:36:17AM -0800, li...@lazygranch.com wrote:
> 
> > Viktor Dukhovni  wrote:
> > 
> > >   header-checks.pcre:
> > > if /^Reply-To:/
> > > # Adjust to exactly match the observed header
> > > # Includes rule id in reject message
> > > /[:\s<]spammer@example\.net[>\s]/ REJECT 5.7.1 Access
> > > denied R0001 /^/  DUNNO no
> > > more Reply-To rules endif
> 
> Note the "Adjust to exactly match ..."
> 
> > 1) I don't understand this line:
> > pcre = pcre:${config_directory}/
> 
> This is just defines a convenient shorthand.  You can then use
> ${pcre} instead of "pcre:${config_directory}/" each time you specify
> a PCRE table.
> 
> > header_checks = pcre:/etc/postfix/header_checks.pcre
> 
> This uses the expansion rather than the shorthand.
> 
> > 4) Here is the entry to reject the reply-to:
> > 
> > if /^Reply-To:/
> > /[:\s<]damnspammer\.org[>\s]/ REJECT
> > endif
> 
> This has no localpart, so won't match the Reply-To:
> 
> > That was a shortened version from Viktor's suggestion. Howver I had
> > also used:
> > 
> > if /^Reply-To:/
> > # Adjust to exactly match the observed header
> > # Includes rule id in reject message
> > /[:\s<]reply@mysecuritycamera\.org[>\s]/   REJECT 5.7.1 Access
> > denied R0001 /^/DUNNO no more
> > Reply-To rules endif
> 
> See below.
> 
> > Received: from trump.damnspammer.org (ec.compute.amazonaws.com
> > [1.2.3.4]) by www.mydomain.com (Postfix) with ESMTP id 5C82C6F591
> >  for ; Tue, 17 Dec 2019 22:35:52 + (UTC)
> > Subject: "oxygen flow" fruits for better garden performance
> > Reply-To: re...@damnspammer.org
> > To: m...@mydomain.com
> 
> In the above "Reply-To" the address has no surrounding "<>" and is
> not followed by anything.  Therefore, the PCRE match needs to be made
> a bit more flexible, allowing for the domain part to not have
> anything after it at all:
> 
> if /^Reply-To:/
> /[:\s<]reply@mysecuritycamera\.org([>\s]|$)/REJECT 5.7.1
> Access denied R0001 /^/
> DUNNO no more Reply-To rules endif
> 
> To test (this uses the "bash" <(...) inline file syntax):
> 
> $ postmap -q 'Reply-To: re...@mysecuritycamera.org' pcre:<(
>   printf 'if /^Reply-To:/\n%s %s\n/^/ %s\n%s\n' \
> '/[:\s<]reply@mysecuritycamera\.org([>\s]|$)/' \
> 'REJECT 5.7.1 Access denied R0001' \
> 'DUNNO no more Reply-To rules' \
> 'endif'
> )
> 

Well that was weird. Having a lot of faith in your code, I assumed the
cut and paste from email was putting in an invisible character. I kept
getting complaints about an unknow option. I just ended up typing the 4
lines myself. Seems to me you search for the ":" twice, so I need to
study PCRE some more. I got the white space search and end of line
check.

Given the invisible character issue via cut and paste, I
wrote a very small script and just fed the test string right to postfix.
(postmap -q "string" file)

I think is should just discard rather than reject, though reject is
more polite.

Thanks again. Now to wait for the spammer to er um offer me
pills to supercharge my begonia. It won't be a long wait.

gmail reverse host issue

[li...@lazygranch.com]

Some gmail gets through, some doesn't. Is there a time limit on the DNS
check? A google search finds several timers, but nothing specific to
DNS.

Log:

Feb 17 06:18:10 mydomain postfix/smtpd[2619]: connect from 
unknown[209.85.219.177]
Feb 17 06:18:10 mydomain postfix/smtpd[2619]: Anonymous TLS connection 
established from unknown[209.85.219.177]: TLSv1.2 with cipher 
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Feb 17 06:18:10 mydomain postfix/smtpd[2619]: NOQUEUE: reject: RCPT from 
unknown[209.85.219.177]: 550 5.7.1 Client host rejected: cannot find your 
reverse hostname, [209.85.219.177]; from= 
to= proto=ESMTP helo=
Feb 17 06:18:10 mydomain postfix/smtpd[2619]: disconnect from 
unknown[209.85.219.177] ehlo=2 starttls=1 mail=1 rcpt=0/1 bdat=0/1 quit=1 
commands=5/7

Clearly the server is legit.
https://bgp.he.net/ip/209.85.219.177
AS15169 IRR Valid 209.85.128.0/17 Google LLC
 

repeated connect and disconnect

[li...@lazygranch.com]

Is there something I should be doing to mitigate this problem?

Oct  8 02:11:42 myserver postfix/smtpd[11630]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:43 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:43 myserver postfix/smtpd[11632]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:43 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:44 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:45 myserver postfix/smtpd[11632]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:45 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:45 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:46 myserver postfix/smtpd[11632]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:46 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:46 myserver postfix/smtpd[11630]: lost connection after CONNECT 
from unknown[180.123.163.212]
Oct  8 02:11:46 myserver postfix/smtpd[11630]: disconnect from 
unknown[180.123.163.212] commands=0/0
Oct  8 02:11:46 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:47 myserver postfix/smtpd[11632]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:47 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:47 myserver postfix/smtpd[11630]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:48 myserver postfix/smtpd[11630]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:48 myserver postfix/smtpd[11630]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:48 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:48 myserver postfix/smtpd[11632]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:48 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:50 myserver postfix/smtpd[11630]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:53 myserver postfix/smtpd[11630]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:53 myserver postfix/smtpd[11630]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:54 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:54 myserver postfix/smtpd[11632]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:54 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:54 myserver postfix/smtpd[11630]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:55 myserver postfix/smtpd[11630]: lost connection after EHLO from 
unknown[180.123.163.212]
Oct  8 02:11:55 myserver postfix/smtpd[11630]: disconnect from 
unknown[180.123.163.212] ehlo=1 commands=1
Oct  8 02:11:55 myserver postfix/smtpd[11632]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:55 myserver postfix/smtpd[11632]: warning: Connection rate limit 
exceeded: 11 from unknown[180.123.163.212] for service smtp
Oct  8 02:11:55 myserver postfix/smtpd[11632]: disconnect from 
unknown[180.123.163.212] commands=0/0
Oct  8 02:11:55 myserver postfix/smtpd[11630]: connect from 
unknown[180.123.163.212]
Oct  8 02:11:55 myserver postfix/smtpd[11630]: warning: Connection rate limit 
exceeded: 12 from unknown[180.123.163.212] for service smtp
Oct  8 02:11:55 myserver postfix/smtpd[11630]: disconnect from 
unknown[180.123.163.212] commands=0/0
Oct  8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection rate 
12/60s for (smtp:180.123.163.212) at Oct  8 02:11:55
Oct  8 02:15:15 myserver postfix/anvil[11633]: statistics: max connection count 
2 for (smtp:180.123.163.212) at Oct  8 02:11:43
Oct  8 02:15:15 myserver postfix/anvil[11633]: statistics: max cache size 1 at 
Oct  8 02:11:42

-
postconf mail_version
mail_version = 3.5.7



smtpd_client_auth_rate_limit = 20
smtpd_client_connection_count_limit = 10
smtpd_client_connection_rate_limit = 10
smtpd_client_new_tls_session_rate_limit = 3
smtpd_client_recipient_rate_limit = 40
smtpd_client_restrictions = permit_sasl_authenticated, permit_mynetworks, 
reject_unauth_destination, check_reverse_client_hostname_access 
pcre:/etc/postfix/fqrdns.pcre, reject_unknown_reverse_client_hostname, 
check_client_access hash:/etc/postfix/spamsources
smtpd_error_sleep_time = 2s
smtpd_hard_error_limit = 6
smtpd_helo_required = yes
smtpd_milters = inet:127.0.0.1:8891, inet:127.0.0.1:8893
smtpd_recipient_limit = 20
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, 
reject_unauth_destination, reject_unauth_pipelining, reject_non_fqdn_sender, 
reject_unknown_sender_domain, 

Can a more useful bounce message be provided

[li...@lazygranch.com]

My server bounced a message. Here is the server log (sanitized).
-
Nov 13 02:07:52 myserver postfix/smtpd[27706]: NOQUEUE: reject: RCPT
from sonic302-23.consmr.mail.gq1.yahoo.com[98.137.68.149]: 554 5.7.1
Service unavailable; Client host [98.137.68.149] blocked using
cbl.abuseat.org; Blocked - see
http://www.abuseat.org/lookup.cgi?ip=98.137.68.149;
from= to= proto=ESMTP
helo=
---
Here is what the sender received:


> From: mailer-dae...@yahoo.com
> Date: November 12, 2020 at 6:07:55 PM PST
> To: per...@sbcglobal.net
> Subject: Failure Notice
> 
> Sorry, we were unable to deliver your message to the following address.
> 
> :
> 554: 5.7.1 Service unavailable
> 
> --- Below this line is a copy of the message.
---

So did the Oath server swallow the useful link to abuseat.org? Can this
be improved?

Re: 554 bounce message lacks detail

[li...@lazygranch.com]

On Fri, 9 Jul 2021 08:38:30 +0200
Matus UHLAR - fantomas  wrote:

> On 08.07.21 18:48, li...@lazygranch.com wrote:
> >I rarely bounced email due to RBLs from someone I actually correspond
> >with. However I did bounce a message with the sender receiving this
> >message:
> >
> >Sorry, we were unable to deliver your message to the following
> >address.
> 
> >>From the maillog:
> >
> >Jul  7 16:35:21 example postfix/smtpd[27776]: NOQUEUE: reject: RCPT
> >from
> > sonic301-25.consmr.mail.gq1.yahoo.com[98.137.64.151]: 554 5.7.1
> > Service unavailable; Client host [98.137.64.151] blocked using
> > cbl.abuseat.org; from=
> > to= proto=ESMTP
> > helo=
> 
> This is not a bounce, this is a rejection by your MTA, and sending
> MTA is responsible for creating a bounce in this case.
> 
> Some MTAs are very shitty regarding to bounce creation, not providing
> full messages.
> 
> >Now you can use mxtoolbox to see that indeed 98.137.64.151 is
> >blocked. Same goes for sonic301-25.consmr.mail.gq1.yahoo.com.
> >However the sender doesn't know the FQDN nor the IP address their
> >email server used.
> >
> >Is there some flag I need to set to provide more information
> >regarding the 554 bounce? Preferably let the person know the RBL
> >that caused it.
> 
> you can add info to reject messages by configuring e.g.:
> 
> smtpd_reject_footer_maps=regexp:/etc/postfix/reject_footes_maps
> 
> but nobody will guarantee that the sending MTA will put that info to a
> bounce.
> 
> However, if it helps, please report this info so we know.
> 
> I remember M$IE used to provide own error message if the message from
> server was smaller than 512B (and option "show friendly HTTP error
> messages" was on), making error messages useless.
> 

For completeness (in that I should have included this):
postconf mail_version
mail_version = 3.5.8

OK details here:
http://www.postfix.org/smtpd.8.html:
http://www.postfix.org/postconf.5.html:

However no examples on how to create the regex nor can I find any on
the internet. How about this:

/etc/postfix/main.cf:
smtpd_reject_footer = \c. For assistance, call 800-555-0101.
 Please provide the following information in your problem report:
 time ($localtime), client ($client_address) and server
 ($server_name).

I would do something more like 
 smtpd_reject_footer = \c. In your browser go to
 https://mxtoolbox.com/blacklists.aspx and enter ($server_name)

554 bounce message lacks detail

[li...@lazygranch.com]

I rarely bounced email due to RBLs from someone I actually correspond
with. However I did bounce a message with the sender receiving this
message:

Sorry, we were unable to deliver your message to the following
address.

From the maillog:

Jul  7 16:35:21 example postfix/smtpd[27776]: NOQUEUE: reject: RCPT from 
sonic301-25.consmr.mail.gq1.yahoo.com[98.137.64.151]: 554 5.7.1 Service 
unavailable; Client host [98.137.64.151] blocked using cbl.abuseat.org; 
from= to= proto=ESMTP 
helo=

Now you can use mxtoolbox to see that indeed 98.137.64.151 is blocked.
Same goes for sonic301-25.consmr.mail.gq1.yahoo.com. However the sender
doesn't know the FQDN nor the IP address their email server used. 

Is there some flag I need to set to provide more information regarding
the 554 bounce? Preferably let the person know the RBL that caused it.

Re: Postfix Helo reverse Exception

[li...@lazygranch.com]

On Sat, 20 Mar 2021 21:28:31 -0400
Viktor Dukhovni  wrote:

> On Sat, Mar 20, 2021 at 08:23:20PM -0400, Wietse Venema wrote:
> > David Mehler:
> 
> > > I don't want to blanket disable reject_unknown_helo_hostname is
> > > there a way I can set a helo exception for this one host/sender?
> > 
> > Yes you can.
> > 
> > smtpd_recipient_restrictions =
> > ...
> > reject_unauth_destination
> > check_client_access inline:{example.com=permit}
> > reject_unknown_helo_hostname
> 
> Since the OP has the rule in smtpd_helo_restrictions and also because
> whitelisting by client hostname (dynamically derived from PTR +
> forward lookup) is fragile, the rule I'd recommend would be:
> 
> smtpd_helo_restrictions =
> ...
> check_helo_access inline:{bogus.example=permit}
> reject_unknown_helo_hostname
> 
> This exempts the specific name that would otherwise be rejected,
> but does so for all clients.  One could instead permit any
> HELO name from a particular IP block, where the problem client
> lives:
> 
>   main.cf:
> cidr = cidr:${config_directory}/
> smtpd_helo_restrictions =
> ...
> check_client_access ${cidr}filter-helo.cidr
> 
>   filter-helo.cidr:
> 192.0.2.0/24DUNNO
> 0.0.0.0/0   reject_unknown_helo_hostname
> 
> Or, as Wietse suggested, if this becomes a game of whack-a-mole, just
> forgo the rule that requires PTR records for the HELO name.
> 

This got me wondering about my own configuration. It turns out I use the
other reverse check:

smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources

This stops many a spammer. I forget who posted the info on the fqrdns
but that is very effective as well. 

Here is the prce as a pastebin since it is really large:

fpaste fqrdns.pcre 
Uploading (239.6KiB)...
https://paste.centos.org/view/07737b27

Re: connect then disconnect; backscatter?

[li...@lazygranch.com]

On Sat, 17 Apr 2021 14:35:37 +0200
Benny Pedersen  wrote:

> On 2021-04-17 09:58, li...@lazygranch.com wrote:
> > I am getting a lot of these:
> > 
> > Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from
> > mone183.secundiarourous.com[141.98.10.183]
> > Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from
> > mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1
> > commands=2/3
> 
> https://docs.iredmail.org/enable.smtp.auth.on.port.25.html
> 
> have you enabled sasl on port 25 ?
> 
> dont do this if you have
> 
> its a common mistake
> 
> smtpd_sasl_auth_enable = yes is not ment for being in main.cf
> 
> sorry if i read auth=0/1 incorrect


I do have "smtpd_sasl_auth_enable = yes" and I use port 587. Before I
comment out that line, here is the general area of my main.cf dealing
with sasl. I cut out my rbls but otherwise this is what I use. Any other
problems?
---
unknown_client_reject_code = 550
# SASL
smtpd_sasl_type = dovecot
broken_sasl_auth_clients = yes
smtpd_helo_required = yes
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_recipient_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unauth_pipelining,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_unknown_recipient_domain,
  reject_non_fqdn_recipient,
  check_client_access hash:/etc/postfix/client_checks,
  check_sender_access hash:/etc/postfix/sender_checks,
  reject_rbl_client SOMERBLS,
  check_policy_service unix:private/policy
smtpd_client_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
  reject_unknown_reverse_client_hostname,
  check_client_access hash:/etc/postfix/spamsources
smtpd_sender_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  reject_unknown_address,
  check_sender_access hash:/etc/postfix/spamsources
smtpd_relay_restrictions =
  permit_sasl_authenticated,
  permit_mynetworks,
  reject_unauth_destination,
  check_policy_service unix:private/policy

Re: connect then disconnect; backscatter?

[li...@lazygranch.com]

On Sat, 17 Apr 2021 17:03:51 -0400 (EDT)
Wietse Venema  wrote:

> li...@lazygranch.com:
> > I do have "smtpd_sasl_auth_enable = yes" and I use port 587. Before
> > I comment out that line, here is the general area of my main.cf
> > dealing with sasl. I cut out my rbls but otherwise this is what I
> > use. Any other problems?
> 
> You should enable SASL auth in master.cf NOT main.cf, and ONLY for
> a service that needs SASL auth.
> 
> Otherwise you're turning it on for the server-to-server port (25)
> where it is not doing any good.
> 
>   Wietse
> 

OK now it makes sense to comment out the line in the main.cf. I knew
sasl had to be enabled somewhere. As it turns out I had put all the
lines in master.cf for the submission 587 but neglected to comment out
this line in the main.cf.

I did a reload/restart and the mail still works. I will give that
spammer an hour and see what shows up. The password guesser would hit
the server about every 20 minutes. All my passwords are high entropy 20
characters computer generated.

Thanks to all.

Re: connect then disconnect; backscatter?

[li...@lazygranch.com]

On Sat, 17 Apr 2021 18:25:47 -0400 (EDT)
Wietse Venema  wrote:

> li...@lazygranch.com:
> > > You should enable SASL auth in master.cf NOT main.cf, and ONLY for
> > > a service that needs SASL auth.
> > > 
> > > Otherwise you're turning it on for the server-to-server port (25)
> > > where it is not doing any good.
> > > 
> > >   Wietse
> > > 
> > 
> > OK now it makes sense to comment out the line in the main.cf. I knew
> > sasl had to be enabled somewhere. As it turns out I had put all the
> > lines in master.cf for the submission 587 but neglected to comment
> > out this line in the main.cf.
> > 
> > I did a reload/restart and the mail still works. I will give that
> > spammer an hour and see what shows up. The password guesser would
> > hit the server about every 20 minutes. All my passwords are high
> > entropy 20 characters computer generated.
> 
> Even with SASL turned off you will see that some bots try SASL auth.
> But with SASL turned they can't use this to verify passwords.
> 
>   Wietse

And so it goes. I suppose if this really bugs me I can block the server
in firewalld. I've yet to see it actually deliver mail. Or complain to
the data center.
https://serveroffer.lt

Apr 18 04:11:53 mydomain postfix/smtpd[18308]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 18 04:11:53 mydomain postfix/smtpd[18308]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3
Apr 18 04:44:43 mydomain postfix/smtpd[18400]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 18 04:44:44 mydomain postfix/smtpd[18400]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3
Apr 18 05:17:38 mydomain postfix/smtpd[18467]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 18 05:17:39 mydomain postfix/smtpd[18467]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3
Apr 18 05:50:34 mydomain postfix/smtpd[18524]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 18 05:50:35 mydomain postfix/smtpd[18524]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3
Apr 18 06:23:32 mydomain postfix/smtpd[18626]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 18 06:23:33 mydomain postfix/smtpd[18626]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3
Apr 18 06:56:24 mydomain postfix/smtpd[18715]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 18 06:56:25 mydomain postfix/smtpd[18715]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3

Re: connect then disconnect; backscatter?

[li...@lazygranch.com]

On Sun, 18 Apr 2021 21:29:26 +1200
Nick Tait  wrote:

> On 18/04/21 7:32 pm, li...@lazygranch.com wrote:
> > And so it goes. I suppose if this really bugs me I can block the
> > server in firewalld. I've yet to see it actually deliver mail. Or
> > complain to the data center.
> > https://serveroffer.lt
> 
> Firewalling is definitely the best solution to the problem you're 
> having, because it will keep your mail logs clear of this sort of
> noise. It can feel a bit like whack-a-mole though, and there are
> tools around that help with this (although I don't personally have
> experience with them), such as fail2ban?
> 
> Even if you choose to manage the firewall rules manually, I'd suggest 
> you devise some sort of regime where the rules you add aren't
> permanent. E.g. I set a timestamp in the comment when I create the
> rule, and then after 6 months if there is no current activity from
> that IP address I delete the rule again. There are several reasons
> for doing this:
> 
>  1. It stops the number of firewall rules growing indefinitely. (Each
> rule has a cost in terms of processing.)
>  2. If the IP address gets reassigned to a legitimate user, you aren't
> penalising them indefinitely for someone else's misbehaviour.
> 
> Nick.
> 
> P.S. Although it isn't suitable for use on your submission port (465
> / 587), in case you aren't aware of it already, check out postscreen: 
> http://www.postfix.org/POSTSCREEN_README.html
> 

I need to learn postscreen eventually for other spammers.

The thing with fail2ban or the similar sshguard is I have a huge block
list for the webserver. It has been my experience that these dynamic
blockers that just add a few IPs every few minutes have a huge CPU load
because the OS creates what I assume is a very efficient database of IP
space to block. Creating this database sends my CPU load to 100% and
brings the virtual private server (one CPU) to a halt. Firewalld once
it has this database set up is very efficient regarding CPU. It does
use a fair amount of memory which isn't unexpected given the size of my
IP space I block.

I reviewed the "rich rules" (a firewalld thing) and noted a have a few
IPs on permanent block that I can't remember why so definitely setting
up a reminder scheme is needed.

I find it pretty offensive that Spectrum/Charter has me on 100%
blocking due to the VPS, so I don't take blocking an IP address
lightly. Their customers aren't pleased with the blocking either.
Spectrum/Charter is alone with this brick wall nonsense. The closest
another company comes to this is AT where you need to request to be
whitelisted. It takes a week but they do get around to it.

connect then disconnect; backscatter?

[li...@lazygranch.com]

I am getting a lot of these:

Apr 17 07:27:10 mydomain postfix/smtpd[21897]: connect from 
mone183.secundiarourous.com[141.98.10.183]
Apr 17 07:27:11 mydomain postfix/smtpd[21897]: disconnect from 
mone183.secundiarourous.com[141.98.10.183] ehlo=1 auth=0/1 quit=1 commands=2/3

Googling mone183.secundiarourous.com indicates it is a bad actor for
the most part.

Before I mess with my main.cf, is this a reasonable approach to limit
this server:

https://www.backscatterer.org/?target=usage
Specifically
---
SAFE MODE with Postfix:

Edit /etc/postfix/main.cf:
smtpd_recipient_restrictions =
...
check_sender_access dbm:/etc/postfix/check_backscatterer
...
Create new file: /etc/postfix/check_backscatterer:
<> reject_rbl_client ips.backscatterer.org
postmaster reject_rbl_client ips.backscatterer.org

Execute following commands:
postmap /etc/postfix/check_backscatterer
postfix reload
for changes to take effect.
-

I would replace dbm with hash. 

Can you have more than one check_senser_access line since I have one
for the RBLs.

Re: AUTH rate limit

[li...@lazygranch.com]

On Wed, 3 Nov 2021 17:40:30 +0100
Matus UHLAR - fantomas  wrote:

> >>03.11.21, 10:53 +0100, @lbutlr:
> >>
> >>> postfix/smtps/smtpd[5554] warning: AUTH command rate limit
> >>> exceeded: 4
> >>>
> >>> Where is this limit set? I looked through postconf -d | grep auth
> >>> looking for something but did not find anything.
> 
> >Markus Schönhaber  wrote:-
> >>My guess would be
> >>http://www.postfix.org/postconf.5.html#smtpd_client_auth_rate_limit
> 
> On 03.11.21 16:32, Matthew Richardson wrote:
> >What might be useful would be a setting which rate limits clients
> >based on the number of FAILED AUTH requests made, probably over a
> >long period of time.
> >
> >I don't see one, but may be missing something...
> 
> so far you can use fail2ban 
> 

Just a FYI programs that change the firewall like fail2ban and sshguard
can put a high burdern on the server in the event your firewall blocks
a large amount of IP space AND you are on a very limited CPU. In my
case I am using a VPS with one CPU core. I have found sshguard would
send my CPU usage to 100% when it added and removed IPs to be blocked.
It was fare better just to let Postfix anvil to do the rate limiting.

I do geofencing and block a number of hosting sites. Touching the
firewall can lock out the server for seconds as the firewalld I assume
creates some efficient table of IP space to block. Once the firewall is
established it isn't much of a CPU load but changing the inputs to it
does burden the CPU. 

Most of my experience is with sshguard rather than fail2ban though I
believe the net effect of the programs is the same.

Before I removed sshguard I would find vi unresponsive at times. Using
logs I traced the problem the sshguard and the firewall. This is a case
where the cure was worse than the disease. I never detected real email
being slowed down by this postfix rate limiting. 

Re: method to discard email with body containing gmail address

[li...@lazygranch.com]

Your comments on the regex are useful since I didn't consider email
addresses with delimiters though none of the spam does at the moment.
Note a few of the spammers put their email address in the subject line.
Maybe that should be my first attempt at discarding. I can't think of a
non-spammer doing that.

I read your tips and the postscreen page. Since postscreen doesn't read
the content of the email, I'm not sure what good it will do. I have
blocking lists set up in postfix itself. (Less is more. No additional
program in the chain.) I suppose I could use postscreen just to inpect
the email server (postscreen without blocking mail?) which I think you
mean it will still block funky email servers, but the gmail spam comes
from gmail. It is perfectly legit email other than sometimes the reply
and from don't match. That itself is legit but just odd. 

Here is a sanitized and shortened header. I am baffled why these
spammers include a gmail address in their email since the reply to
field is gmail anyway, but most do. Why google tolerates this crap is
another story. I gave up on emailing their abuse contact since nothing
changed by doing so. 


Return-Path: 
X-Original-To: m...@mydomain.com
Delivered-To: m...@mydomain.com
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
client-ip=209.85.222.46; helo=mail-ua1-f46.google.com; 
envelope-from=infoa0...@gmail.com; receiver=m...@mydomain.com
DMARC-Filter: OpenDMARC Filter v1.4.1 www.mydomain.com 8E2BF69A7B
Authentication-Results: mydomain.com; dmarc=pass (p=none dis=none) 
header.from=gmail.com
Authentication-Results: mydomain.com; spf=pass smtp.mailfrom=gmail.com
DKIM-Filter: OpenDKIM Filter v2.11.0 www.mydomain.com 8E2BF69A7B
Authentication-Results: www.mydomain.com;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com 
header.b="Mb0Z+9VO"
Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46])
 (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
  key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by www.mydomain.com (Postfix) with ESMTPS id 8E2BF69A7B
 for ; Fri,  5 Nov 2021 12:09:13 + (UTC)
Received: by mail-ua1-f46.google.com with SMTP id az37so16607241uab.13
for ; Fri, 05 Nov 2021 05:09:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112;
h=mime-version:reply-to:from:date:message-id:subject:to;

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:reply-to:from:date:message-id
 :subject:to;

X-Gm-Message-State: AOAM532TS3ZNsUStUWlcBN56fBCGvVQTPu8NGAoz576BhScZapblMLfa
 MoJux1YhYW0kmDUg2jh6myKzaL7nRhQuLVO0sHg=
X-Google-Smtp-Source: 
ABdhPJwaGhpcfV5E2//9RLpCPT4+PXBI7XdCN/nLCgf6EYfgW+pcKLMeYoW+3Jk64pzSQ47l56P14h+8d7dMPlXuLE0=
X-Received: by 2002:ab0:5a93:: with SMTP id w19mr63371846uae.58.1636114152575;
 Fri, 05 Nov 2021 05:09:12 -0700 (PDT)
MIME-Version: 1.0
Reply-To: jm84450...@gmail.com
From: Abdulla Shahid 
Date: Fri, 5 Nov 2021 05:08:57 -0700
Message-ID: 


On Sat, 06 Nov 2021 10:54:48 -0500
Rob McGee  wrote:

> On 2021-11-06 06:15, li...@lazygranch.com wrote:
> > Most of my spam contains a gmail address to reply to the spammer. I
> > would like to discard email whose body contains a gmail address.
> > Since discarding mail could get ugly, I would hope someone on the
> > list can eyeball my plan.
> 
> Indeed it is ugly.  You just as well could have asked for a method
> to throw out the baby with the bathwater!
> 
> > I added
> > body_checks = pcre:/etc/postfix/body_checks
> > to main.cf. I made a null body_checks file and ran postmap on it,
> > then
> 
> postmap "compiles" hash: and other indexed map types.  It's not
> needed for a pcre_table(5) map.
> 
> > did a reload & restart. Postfix wouldn't send email if the file was
> > missing.
> > 
> > postconf -d mail_version
> > mail_version = 3.6.2
> > 
> > Trawling the internet I found this regix to match gmail addresses:
> > ^[\w.+\-]+@gmail\.com$
> > 
> > So if body_checks contained
> > /^[\w.+\-]+@gmail\.com$/ DISCARD
> > work.
> 
> Change DISCARD to WARN first, to see what it matches.
> 
> Also, you anchored the expression on both ends, ^ and $, so you're
> only going to match mail with ONLY the gmail address on one line.
> This line with zeixsgw9gufv2isophpdyisr0bgz0...@gmail.com will not
> match.  Neither will this, with the <> enclosing brackets:
> 
> 
> I think once you get the bugs worked out you will give up on this.
> 
> See my postscreen howto for a much more effective means of dealing
> with spam.

method to discard email with body containing gmail address

[li...@lazygranch.com]

Most of my spam contains a gmail address to reply to the spammer. I
would like to discard email whose body contains a gmail address. Since
discarding mail could get ugly, I would hope someone on the list can
eyeball my plan. 

I added 
body_checks = pcre:/etc/postfix/body_checks
to main.cf. I made a null body_checks file and ran postmap on it, then
did a reload & restart. Postfix wouldn't send email if the file was
missing.

postconf -d mail_version
mail_version = 3.6.2

Trawling the internet I found this regix to match gmail addresses:
^[\w.+\-]+@gmail\.com$

So if body_checks contained
/^[\w.+\-]+@gmail\.com$/ DISCARD 
work.

Re: spam emails with "to:" line missing

[li...@lazygranch.com]

On Fri, 15 Apr 2022 11:06:35 +0200
Tinne11  wrote:

> 
> > Am 15.04.2022 um 08:49 schrieb Fourhundred Thecat
> > <400the...@gmx.ch>:
> > 
> > Are there any legitimate cases where "to:" might be missing?
> 
> 
> RFC 5322 says: "The only required header fields are the origination
> date field and the originator address field(s).", i. e. the "Date:"
> and the "From:" header field.
> 
> 
> 
> I have sent this answer without any address in the to header field.

The header doesn't look odd because the mailing list provides a TO
field. I'm fine if you want to send me an email without a TO field. I'd
like to look at the header.

Re: spam emails with "to:" line missing

[li...@lazygranch.com]

On Fri, 15 Apr 2022 11:06:35 +0200
Tinne11  wrote:

> 
> > Am 15.04.2022 um 08:49 schrieb Fourhundred Thecat
> > <400the...@gmx.ch>:
> > 
> > Are there any legitimate cases where "to:" might be missing?
> 
> 
> RFC 5322 says: "The only required header fields are the origination
> date field and the originator address field(s).", i. e. the "Date:"
> and the "From:" header field.
> 
> 
> 
> I have sent this answer without any address in the to header field.

This email had a "TO" to me. 

I just experimented on my own, that is do a message using BCC and then
one with the TO field. I can confirm the message using BCC didn't have
a TO field. This is on my own postfix/dovecot implementation.

I routinely send messages just using BCC if I know that all the
recipients don't have each others email addresses. 

check_client_access

[li...@lazygranch.com]

I'm trying to allow-list (formerly whitelist) a TLD. I have these lines
in my postfix main.cf:

  check_client_access hash:/etc/postfix/client_checks,
  check_sender_access hash:/etc/postfix/sender_checks,
  check_client_access hash:/etc/postfix/rbl_override,

For the rbl_override file is siriusxm.com sufficient? Or do I need
e.siriusxm.com or even r193.e.siriusxm.com?

Maillog message is:
Apr 29 17:20:46 lazygranch postfix/smtpd[10668]: NOQUEUE: reject: RCPT from 
r193.e.siriusxm.com[192.243.230.193]: 554 5.7.1 Service unavailable; Client 
host [192.243.230.193] blocked using zen.spamhaus.org; 
from= to= proto=ESMTP 
helo=

For your entertainment, customer support at SiriusXM is having all
sorts of problems with email bouncing. Like maybe someone there could,
you know, check the log for bounces? They said to use a gmail account.
I assume they don't bounce spam but put it in a spam folder.

Re: check_client_access

[li...@lazygranch.com]

On Sat, 30 Apr 2022 01:11:05 -0400
Viktor Dukhovni  wrote:

> On Sat, Apr 30, 2022 at 10:28:06AM +1000, raf wrote:
> 
> > > .domain.tld
> > >
> > > Matches subdomains of domain.tld, but only when the
> > > string smtpd_access_maps is not listed in the Postfix
> > > parent_domain_matches_subdomains configuration setting.
> > 
> > The .domain.tld notation only covers a single level of
> > subdomain,
> 
> This is false.  With non-regexp access(5) tables, each level of the
> domain hierarchy is tried in turn, all the way up to the TLD.
> 
> If "parent_domain_matches_subdomains" includes "smtpd_access_maps",
> then the parent domain keys are "dotless", otherwise all parent
> domain lookup keys start with a leading ".".
> 

Thanks. I will just use the TLD. At the moment I can't test their login
due to their system maintenance.

I gave siriusxm "bottom of the rung tech support" the "You're the
problem not me" lecture and said just get removed from any blocking
list. At the moment the zen.spamhaus.org blocking is gone. MXTOOLBOX
shows no blocking on the lists they check.

They are suppose to call me with the solution in a few days. It is will
interesting what story they give me. More interesting would be if they
thank me for pointing out the problem. 

zen.spamhaus.org suggestion in postifx main.cf

[li...@lazygranch.com]

Though not currently bouncing my maillog had this message (sanitized
because of Google):

 NOQUEUE: reject: RCPT from avasout-peh-001.plus.net[212.159.14.17]: 554 5.7.1 
Service unavailable; Client host [212.159.14.17] blocked using 
zen.spamhaus.org; Error: open resolver; 
https://www.spamhaus.org/returnc/pub/172.69.133.38; 
from= to= proto=ESMTP 
helo=

Reading the link provided:
https://www.spamhaus.org/returnc/pub/172.69.133.38

Then ultimately reaching:
https://docs.spamhaus.com/datasets/docs/source/40-real-world-usage/PublicMirrors/MTAs/020-Postfix.html#configuration

The suggested set up is:
smtpd_recipient_restrictions =
...
reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
reject_rhsbl_sender dbl.spamhaus.org=127.0.1.[2..99]
reject_rhsbl_helo dbl.spamhaus.org=127.0.1.[2..99]
reject_rhsbl_reverse_client dbl.spamhaus.org=127.0.1.[2..99]
warn_if_reject reject_rbl_client zen.spamhaus.org=127.255.255.[1..255]
...

Looking at warn_if_reject on
https://www.postfix.org/postconf.5.html
this seems like a bad idea since it won't reject the spam.

Googling "zen.spamhaus.org=127.0.0.[2..11]" indicates a change was made
in 2021 and just follow instructions. No real explanation.

I'm always hesitant to do something I don't fully understand (certs
and regex excluded).

Comments? 

Re: zen.spamhaus.org suggestion in postifx main.cf

[li...@lazygranch.com]

On Wed, 4 May 2022 20:47:16 +0200
Arrigo Triulzi  wrote:

> On 4 May 2022, at 20:40, li...@lazygranch.com wrote:
> > 
> > Though not currently bouncing my maillog had this message
> > (sanitized because of Google):
> > 
> > NOQUEUE: reject: RCPT from avasout-peh-001.plus.net[212.159.14.17]:
> > 554 5.7.1 Service unavailable; Client host [212.159.14.17] blocked
> > using zen.spamhaus.org; Error: open resolver;
> > https://www.spamhaus.org/returnc/pub/172.69.133.38;
> > from= to= proto=ESMTP
> > helo=
> 
> This is because your DNS resolution is via
> open DNS such as Google’s 8.8.8.8 or Quad9’s 9.9.9.9 or Cloudflare’s
> 1.1.1.1.
> 
> You can get rid of it, and use Spamhaus just fine, by installing a
> caching resolver such as unbound.
> 
> Cheers,
> 
> Arrigo  

Quad 9 uses a number of DNS servers with different names but I guess
that isn't good enough. I had set up unbound on the VPS used for my VPN
when I set up dnscrypt. I don't recall why I pulled it. I am going to
give systemd resolved a try. I suspect if it is a good replacement for
unbound it would be praised as such. But the install is a low effort so
it is worth a shot.

Thanks to Peter for explaining when the warn_if_reject does.