[pfx] Re: RFC logs_check

[Allen Coates via Postfix-users]

On 24/07/2024 13:11, Jaroslaw Rafa via Postfix-users wrote:
>> I want "Kill on Sight". 
>>
>> Fastest way to me would be Postfix says it logged a connection from
>> fluffy.cuddly.port.raping.internet-measurement.com calls my script with
>> the IP address and they get stuffed up IPTables.
These particular guys can be killed using two net-block entries on IPv4 (and 
seven on IPv6) - worth putting in manually

Regards

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

[pfx] Re: Documentation Prefix

[Allen Coates via Postfix-users]

On 07/07/2024 16:13, Ralph Seichter via Postfix-users wrote:
> * Allen Coates via Postfix-users:
>
>> I have just been perusing my firewall logs, and notice I have had
>> several "hits" using the documentation prefix (2001:db8::/32) as the
>> source address. [...]
>>
>> I have also had some hits (on my website) from  Teredo addresses.  I
>> am allowing these, because (arguably) we are still transitioning to
>> IPv6.
> "Still transitioning", are we? ;-) RFC 3849 is 20 years (!) old, almost
> to the day, and https://www.rfc-editor.org/rfc/rfc3849.html#section-3 is
> pretty clear:
>
>   This assignment implies that IPv6 network operators should add this
>   address prefix to the list of non-routeable IPv6 address space, and
>   if packet filters are deployed, then this address prefix should be
>   added to packet filters.
>
> Anybody using 2001:db8::/32 to connect over the internet is simply doing
> it wrong, and I don't think that attempts at enabling their erroneous
> efforts is helpful.
>
> -Ralph

I am blocking  2001:db8::/32 (of course);  it's the Teredo prefix which I am 
allowing. 

Having been retired for 15 years, and only running a personal (domestic) 
server, it is difficult to judge how
commonplace these transition protocols still are.

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

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

[pfx] Documentation Prefix

[Allen Coates via Postfix-users]

I have just been perusing my firewall logs, and notice I have had several 
"hits" using the documentation prefix
(2001:db8::/32) as the source address.   Eleven in a fortnight or so.

I have also had some hits (on my website) from  Teredo addresses.  I am 
allowing these, because (arguably) we are still
transitioning to IPv6.

The price of freedom is eternal vigilance.

Allen C


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

[pfx] Re: dnsbl submissions

[Allen Coates via Postfix-users]

On 07/07/2024 05:18, Nick Edwards via Postfix-users wrote:
>
> Main:
> submission_recipient_restrictions =
>         reject_rbl_client cbl.abuseat.org 
> =127.0.0.[2..255]
>         reject_unknown_sender_domain
>         reject_unknown_recipient_domain
>         permit_mynetworks
>         permit_sasl_authenticated
>         reject
>

Did you remember to include a "smtpd_restriction_classes"  directive?  the only 
thing I can think of  :-)

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

[pfx] Re: disable authentication on port 25

[Allen Coates via Postfix-users]

On 24/05/2024 03:15, Peter via Postfix-users wrote:
No you definately should disable auth on port 25 regardless.  It is possible for postscreen to pass a connection to 
smtpd and smtpd can *then* offer auth.


To answer your original question, you can just set   -o smtpd_sasl_auth_enable=no in master.cf but it has to be on the 
smtpd service, not on postscreen.  That said, I recommend not setting smtpd_sasl_auth_enable in main.cf and instead 
explicitly set it on your submission and/or submissions service in master.cf instead.  When it comes to things like 
this it is generally better to default to off and explicitly turn on rather than default to on and explicitly turn off.


Many moons ago I was told to put "smtpd_sasl_auth_enable=no"  in main.cf, blocking the function everywhere, and then put 
"-o smtpd_sasl_auth_enable=yes" in the submission stanza(s) in master.cf, expressly enabling it *just* there.


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

[pfx] Re: Strengthen email system security

[Allen Coates via Postfix-users]

On 23/05/2024 14:45, Bill Cole via Postfix-users wrote:

is rumored to have said:


Don't accept mail from home networks. For example, use "reject_dbl_client
zen.spamhaus.org".  For this you must use your own DNS resolver,
not the DNSresolver from your ISP.


On 23.05.24 07:00, Northwind via Postfix-users wrote:

will this also stop the valid client's SMTP connection? thank you Wietse.


not, unless they are listed in zen.spamhaus.org, which should not happen.


Zen includes the "PBL" component, which consists largely of residential and 
mobile consumer IPs.


The ZEN response codes say which data-set(s) list the IP address; you can qualify the "reject_dbl_client" directive to 
disregard the PBL component.


The other components will remain active, and contribute to the blocking process.

Allen C


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

[pfx] Re: Feature request

[Allen Coates via Postfix-users]

On 20/03/2024 13:17, Viktor Dukhovni via Postfix-users wrote:
> On Wed, Mar 20, 2024 at 01:42:16PM +0100, Ralf Hildebrandt via Postfix-users 
> wrote:
>> Hi!
>>
>> I wonder if this is possible:
>>
>> If a PCRE/regexp style map is triggering, it can be quite hard to
>> find out WHICH pattern actually caused the action.
>>
>> So maybe postmap (when invoked with "-b", "-h" or "-q key") could emit
>> which regular expression (or which line it was in) actually matched.
>>
>> Yes, I could give all my regular expressions patterns a unique RHS or
>> find the regular expressions by divide-et-impera, but I'm being lazy.
> With bash <(command) inline file syntax, make the RHS unique on the fly:
>
> $ keystr=...
> $ remap=/etc/postfix/...
> $ postmap -q "$keystr" pcre:<(perl -pe 's/$/ LINE $./ unless 
> m{^(if|endif|#)?\s}' "$remap")
>
> Better yet, don't be lazy, include a fingerprint string in your RHS
> reject rule values.
Postscreen doesn't have the option of unique RHS fingerprints;  nonetheless, it 
would useful to see which (of several)
ACLs was rejecting an incoming connection.

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

[pfx] Re: SMTP Smuggling, workarounds and fix

[Allen Coates via Postfix-users]

In the past, I have had messages coming in (via port 25) claiming to be 
Helpdesk, Personnel, etc

So I had incorporated into my sender_access file the line:-
cidercounty.org.uk   permit_sasl_authenticated, reject

Do you think something like this would be beneficial WRT the smuggling problem?

Allen C


On 21/12/2023 12:51, Wietse Venema via Postfix-users wrote:
> [A longer and updated version of this text may be found at 
> https://www.postfix.org/smtp-smuggling.html]

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

[pfx] Re: IPv6 and Cloud server CPU

[Allen Coates via Postfix-users]

On 22/11/2023 22:16, DL Neil via Postfix-users wrote:
> Have been offered choice of more-modern Cloud-VPS systems, and two addressing 
> options:
>
> Q1:
> can an email server be run off IPv6 (exclusively) these days, or are IPv4 + 
> v6 alternatives necessary?

Realistically, you still need to provide an IPv4 connection, but there are a 
few IPv6-only websites starting to appear. 
https://loopsofzen.uk/ is one example.

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

[pfx] Re: Filterring out invalidu...@mydomain.com

[Allen Coates via Postfix-users]

On 05/10/2023 04:44, Olivier via Postfix-users wrote:

Hi,

How is it possible to configure Postfix to filter messages of the form:
from invalidu...@mydomain.com to validu...@mydomain.com

I have been receiving quite a lot recently and they are trash.

Best regasrds,

Olivier

From the top of my hash:sender_access file:-

...
### Reject any cidercounty sender not from local network
cidercounty.org.uk    permit_sasl_authenticated, reject Sender is not 
authenticated - Snd-1
...

Anything coming in via port 25 is rejected.

Hope this helps

Allen C







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

[pfx] Re: Postfix: running a script on authentication failure

[Allen Coates via Postfix-users]

On 22/06/2023 16:09, Viktor Dukhovni via Postfix-users wrote:
> So, at least in my case, geofencing is not an option.
Of course not - there is never a universal solution.

In the matter of multi-factor authentication, discussions are increasingly 
quoting a fourth factor:  "WHERE you are". 
(Does the local electricity company REALLY want to accept an administrative 
log-in from Paraguay?)  

It seems reasonable to (at least try to) incorporate this - whenever it is 
practicable.    For me at least, a
country-based ACL, recompiled every week, is (almost) a fit-and-forget solution.

But this is getting off-topic  :-)

Allen C
 


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

[pfx] Re: Postfix: running a script on authentication failure

[Allen Coates via Postfix-users]

On 22/06/2023 12:58, André Rodier via Postfix-users wrote:
>
> What are you using on your side ?
>
> - Do you know any service, that I could use, to get the network to ban from 
> an IP address reputation, something like
> crowdsec, for instance ?
> - Anyone has success with Suricata, Snort, or a tool like this ?
>
> Please, do not suggest third party hosted services, I want to be part of my 
> self-hosting solution.

Just thinking at a tangent...

Is it possible / practical to develop the concept of a "service area" - to 
white-list all the net-blocks where all your
genuine callers originate, and prohibit everywhere else?

For myself, I am able to firewall my Submission/IMAP/SSH ports to allow just 
the one net-block over the Internet, and to
use an ACL on PostScreen to disallow certain countries which are "nuisances".

http://www.ipdeny.com  have net-blocks of whole countries.

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

[pfx] Re: postfix ports questions

[Allen Coates via Postfix-users]

On 14/05/2023 01:09, Tom Reed via Postfix-users wrote:
>> On Sat, May 13, 2023 at 06:51:30PM +0800, Tom Reed via Postfix-users
>> wrote:
>>
>>> Can I setup only port 25 open to the world? If port 465/587 are filtered
>>> by iptables which only permit internal users to connect, does this make
>>> sense to external MTAs (such as google, MS's)?
>> You do not need to expose ports other than 25 to outside sources (you
>> don't have to operate anything on those ports except as needed by your
>> own users).
>>
>> For the blocked ports, your firewall should typically reply with a TCP
>> RST, rather than just drop packets.  This could at least be useful on
>> the "ident" port:
>>
> Hello,
>
> So this iptables should work?
>
> /usr/sbin/iptables -F
> /usr/sbin/iptables -A INPUT -p tcp -s 127.0.0.1 -j ACCEPT
> # my networks as follows
> /usr/sbin/iptables -A INPUT -p tcp -s 20.127.91.0/24 -j ACCEPT
> # reject other ports than 25
> /usr/sbin/iptables -A INPUT -p tcp --dport 993 -j REJECT --reject-with
> tcp-reset
> /usr/sbin/iptables -A INPUT -p tcp --dport 143 -j REJECT --reject-with
> tcp-reset
> /usr/sbin/iptables -A INPUT -p tcp --dport 465 -j REJECT --reject-with
> tcp-reset
> /usr/sbin/iptables -A INPUT -p tcp --dport 587 -j REJECT --reject-with
> tcp-reset
>
FWIW, I would have said accept from the world port 25, with a global reject of 
EVERYTHING else.

It is the "default deny" security stance:  expressly allow ONLY the ports you 
want "them" to see.

Regards

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

[pfx] Re: Deny any sender address with subdomain

[Allen Coates via Postfix-users]

On 28/04/2023 14:59, Gerd Hoerst via Postfix-users wrote:
> Hi !
>
> question 1st : is it a good idea to reject any email which is not sent from a 
> domain  (means sen...@domain.tld) any
> other like sen...@sub.domain.tld or sub.sub.domain.tld is rejected ?

Any ideas on the opposite - i.e. WITHOUT a domain?

I sometimes receive messages from "u...@co.uk"...

(They never get past Postscreen, so the question is academic)

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

[pfx] Re: postscreen question

[Allen Coates via Postfix-users]

The code 450 is the "deep tests"  doing their stuff.

When a a remote host calls for the first time, it sees a temp-fail (code 450).

When the host  calls back, *USING THE SAME IP ADDRESS*,  it will be passed 
through to the mail server.   The host has to
call twice to get through.

With  gmail and the like, they never use the same IP address twice, and the 
connection is stopped every time.

A "proper" grey-list ap  looks at three pieces of data:- hostname, source and 
destination addresses - Postscreen ONLY
looks at the IP address, and is easily fooled by multiple mail servers.

Trust us - Postscreen  doesn't work as a grey-lister.  :-)

Allen C

 
On 29/04/2023 11:43, Ken Peng via Postfix-users wrote:
> Nope. I found that if I enabled protocol test, every provider including 
> gmail/orange/vodafone sending messages to me will get response code 450. 
> After I disabled those protocol test, everything goes fine.
>
> So what's the correct way to deal with postscreen protocol tests?
>
> I mean the following stuff.
>
>>>  postscreen_pipelining_enable = yes
>>>  postscreen_pipelining_action = enforce
>>>  postscreen_non_smtp_command_enable = yes
>>>  postscreen_non_smtp_command_action = enforce
>>>  postscreen_bare_newline_enable = yes
>>>  postscreen_bare_newline_action = enforce
>
> Thanks.
>
>
>> On Sat, 29 Apr 2023, Ken Peng via Postfix-users wrote:
>>
>>> Hello
>>>
>>>  When I enabled postscreen, why even gmail's sender IP was greylisted?
>>>
>> Did you expect or configure to deal with gmail differently?
>>
>>> The log says:
>>>
>>>  Apr 29 15:35:35 mxin postfix/postscreen[59408]: NOQUEUE: reject: RCPT from 
>>> [209.85.160.53]:50219: 450 4.3.2 Service currently unavailable; 
>>> from=, to=, proto=ESMTP, 
>>> helo=
>>>
>>>  And this is my configuration for postscreen:
>>>
>>>  # postscreen
>>>  postscreen_access_list = permit_mynetworks 
>>> cidr:/etc/postfix/postscreen_access.cidr
>>>  postscreen_blacklist_action = drop
>>>  postscreen_greet_action = enforce
>>>  postscreen_dnsbl_threshold = 2
>>>  postscreen_dnsbl_action = enforce
>>>  postscreen_dnsbl_sites = zen.spamhaus.org*2
>>>  postscreen_dnsbl_whitelist_threshold = -2
>>>
>>>  # postscreen protocol test
>>>  postscreen_pipelining_enable = yes
>>>  postscreen_pipelining_action = enforce
>>>  postscreen_non_smtp_command_enable = yes
>>>  postscreen_non_smtp_command_action = enforce
>>>  postscreen_bare_newline_enable = yes
>>>  postscreen_bare_newline_action = enforce
>>>
>> There doesn't seem to be anything specific to gmail, so if you enable 
>> greylisting, it will apply to everyone.
>>
>> Cheers.
>>
>> ___
>> Postfix-users mailing list -- postfix-users@postfix.org
>> To unsubscribe send an email to postfix-users-le...@postfix.org
>>
> --
> https://kenpeng.pages.dev/
> ___
> Postfix-users mailing list -- postfix-users@postfix.org
> To unsubscribe send an email to postfix-users-le...@postfix.org

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

Re: [SOLVED] Re: Submission runs very slowly

[Allen Coates]

On 13/02/2023 22:43, raf wrote:
> And for diceware style passphrases to be meaningful,
> it's important that none of the words are "picked" by a
> human. They must be random. Then, it doesn't matter if
> they are common words or not.
A human can throw in a misspelt or foreign-language word.  Probably optimum if 
(s)he doctors a truly random selection.

Also, don't forget numbers and special characters etc.   I think a human would 
need to add those, too.

It occurs to me that, once "the enemy" gets past dictionary searches,  they 
won't know the actual password length.  They
would have to explore random character sequences of EVERY length - and not just 
that of YOUR password...

Allen C

Re: Replacing initial "Received:" line on submission?

[Allen Coates]

On 11/01/2023 00:04, Benny Pedersen wrote:
> Charles Sprickman skrev den 2023-01-11 00:43:
>
>> Any pointers on what direction to go with this?
>
> start postconf -e "smtpd_sasl_authenticated_header = no" or remove it in 
> main.cf or master.cf overrides, its not
> needed to add your sasl auth user logins to send mails

Setting this to "yes" effectively betrays your log-in identity.

>
> i use roundcube webmail so you only see my ipv6 loopback ip

My workstation connects using a randomised IPv6 address, as per RFC 4941.  So 
by the time you see the address, it has
almost certainly changed.

(The ClawsMail email client declares the workstation's hostname in the 
SMTP/Submission handshake; Thunderbird doesn't)

Hope this helps

Allen C

Re: run script on new connection?

[Allen Coates]

On 27/12/2022 00:15, mats wrote:
> Using DNS is not a way forward for us.
> Maintaining cidr lists a number of times a minute with 10:s of thousands of 
> ip's instead of a simple query for the ip I'm interested in, well not 
> interested in that either
>
Invert the problem:-
Test ONLY for the ip(s) that interest you, and reject it/them, with a default 
pass for everything else.

hope this helps

Allen C

Re: Protect access to submission services

[Allen Coates]

On 14/08/2022 19:51, Matus UHLAR - fantomas wrote:


but which lists?  using spamhaus PBL is not viable because it lists dynamic IP 
address which can be commonly used by clients.



Could you try  "permit_dnswl_client dnswl_domain=d.d.d.d",   with the Spamhaus 
PBL and a selective return code?  Whitelist what you *DO* want and reject 
everything else.


http://www.ipdeny.com provide IP blocklists based on country of origin; you 
could use these to create an ACL, to exclude anyone outside a nominal "service 
area".


I play with country-based ACLs on my domestic system; some countries have a MUCH 
harder time gaining access to port 25 than UK/US.


Just an idea...

Allen C

Re: IPv6 DNSRBLs

[Allen Coates]

On 30/05/2022 06:44, Peter wrote:
We're now starting to see some IPv6 DNSRBLs (eg: bl.ipv6.spameatingmonkey.net).  
It occurs to me that postscreen and postfix should only be sending IPv4 requests 
to IPv4-specific DNSRBLs and IPv6 requests to IPv6-specific lists.


I brooded about this some years ago.

The best I came up with was to create two smtpd_restriction_classes - ipv6tests 
and ipv4tests.


A CIDR based Access Control List ended with the catch-all entries

::/0   ipv6tests
0.0.0.0/0  ipv4tests

Previous entries in the ACL would allow favoured net-blocks to bypass the tests, 
or disallow "bad" net-blocks altogether.


I didn't actually implement this for DNSRBLs, as it wouldn't have worked with 
postscreen where all my DNSRBL tests are performed, but the principle has been 
used successfully elsewhere.


Somewhere on one of my older machines is a script to probe DNSRBLs with the 
RFC5782 test entries, to see which responded to IPv6 & IPv4 probes.


Hope this helps

Allen C

Re: password security

[Allen Coates]

On 25/04/2022 05:26, ミユナ (alice) wrote:
do you know how to stop passwords from being brute-forced for a mailserver? do 
you have any practical guide?


thank you.


You could use an Access Control List to include all your "customers", and 
banning everybody else.


In my case, any submission originating from outside the UK would not be genuine, 
and I could safely block it.  (Not that I need such a restriction)


Just an idea...

Allen C

Re: About smtp_fallback_relay parameter

[Allen Coates]

On 07/04/2022 17:55, Pedro David Marco wrote:

Probably i am misunderstanding Postfix documentation but... What is exactly the 
Postfix criteria about using smtp_fallback_relay 




I also had an issue with this some time ago, which I didn't understand.

At the time I had set the fallback relay as the smart-host of my ISP.

Postfix offered a message to the (correct) direct destination and was 
grey-listed.

Postfix immediately resent the message via the fallback relay.

I felt that this behaviour mimicked some of the larger ISPs which resend 
messages using a different IP address every time, and which never got past the 
grey-list.  I thought that this was "wrong" and - at the time - removed the 
fallback directive.


What I *WANTED* was only to use the fallback if Postfix could not resolve a 
direct IP address.  There are probably issues with this, too; if the address is 
unresolvable for me, it is likely to be unresolvable for my ISP also.


What are the optimum settings for these circumstances?

Thanks

Allen C

Re: How can I build a reliable distribution list?

[Allen Coates]

Given that you also have distribution-ow...@myhost.com as an alias, is there an 
easy way of making it a "closed" list, such that only the list-members can write 
to it?


I am thinking of the committee of a small club (ten addresses at most).

Allen C



On 29/01/2022 14:43, Wietse Venema wrote:

Markus Grunwald:

Hello Wietse,


What I wrote was regardless of whether one uses mailing list
management software.

http://www.postfix.org/aliases.5.html

With Postfix aliases(5), if mail is sent to an alias 'foo', and


That's alias_maps not virtual_alias_maps.

Wietse


there also is an alias 'owner-foo', then the enveloope sender
address
will be set to owner-foo. This behavior already existed in
Sendmail.



That sounds like you've found the solution for my problem... My
distribution list is *very* static. Only every few years something
changes.

So I have to add the members of the distribution list to the
aliases? Say, if my distribution looked like this (virtual_alias):

distribut...@myhost.com  a...@a.com, b...@b.com


What would I have to add to /etc/aliases?

Thank you for the pointer to aliases(5)!

cu
--
Markus Grunwald

Re: Bypass postscreen

[Allen Coates]

On 14/07/2021 23:56, Doug Hardie wrote:

I have both of those set to enforce.  Here is the complete postscreen section 
of main.cf:

#   postscreen spam filtering
postscreen_greet_action = enforce
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites = bl.spamcop.net zen.spamhaus.org b.barracudacentral.org
postscreen_access_list = permit_mynetworks,
 cidr:/usr/local/etc/postfix/access.cidr
#

That seems to work as I see numerous spam being blocked by those dnsbl sites.  
Am I missing something?


postscreen_blacklist_action [now postscreen_denylist_action]  also needs to be 
set to either "enforce" or "drop"  The default is "ignore"...


Allen C

Re: Certificate Postfix.org missing?

[Allen Coates]

On 23/04/2021 07:36, Nicky Thomassen wrote:
> With the risk of going off-topic, I do not see the reason for encrypting
> everything on the internet from a more practical point of view, as it just 
> gives
> overhead: It takes time to set up and maintain, takes processing power on both
> ends, and in the case of Postfix, makes no sense since there is nothing to
> protect.
> 
> Encryption gives (ideally) authenticity, confidentiality and integrity
> https://en.wikipedia.org/wiki/Information_security#Basic_principles
> 
> But there is no need for that on a read-only site like Postfix'. In my 
> opinion,
> anyway.
> 

The certificate ensures AUTHENTICITY.  Users can be sure they are seeing the
GENUINE Postfix site.  You PGP-sign software downloads for the same reason.

Also, I understand that HTTPS downloads are a touch faster...

My vote is in favour of HTTPS.  :-)

Allen C

Re: Couple of questions re: IPBLs & DNSBLs

[Allen Coates]

On 18/03/2021 22:34, Antonio Leding wrote:
> Hello all,
> 
> 
> 1. Where to place IPBL\DNSBL rules
> 
>   * Because the result of a hit against an IPBL\DNSBL is to REJECT, does it 
> make
> sense to place these kind of rules earlier in the SMTPD_RESTRICTIONS eval
> chain (i.e. CLIENT) rather than later (i.e. RECIPIENT) as shown in the
> /Getting selective with SMTP access restriction lists/ section of the
> SMTPD_ACCESS_README document.
> 

Traditionally, processor-intensive tests (such as DNSBL look-ups) are placed
later in the test sequence, so that if a "quick and cheap" test rejects, you
don't have to bother with an "expensive" test.

> 2. Making hits against an IPBL\DNSBL advisory
> 

The Postscreen front-end to Postfix gives DNSBLs a "score", so that less
reliable lists become less important in the accept/reject process.
Spam-assassin (and other add-ons) can also do this.

Quite apart from the above, Postscreen is VERY effective in detecting
compromised PCs sending junk emails.  I commend it to your attention.

Hope this helps

Allen C

Re: Rootless postfix

[Allen Coates]

On 26/02/2021 02:55, Viktor Dukhovni wrote:
> On Thu, Feb 25, 2021 at 11:39:19PM +0000, Allen Coates wrote:
> 
>> It is an *ANCIENT* reference, but the but the O'Reilly book "Building 
>> Internet
>> Firewalls" describes a simple program called smap.
>>
>> It runs without root privileges and ONLY accepts incoming SMTP connections,
>> dropping messages into a queue for processing by another program.
>> (Could this be the MAILDROP queue perhaps?)
>>
>> They say it is only 700 lines of code long, and is part of the TIS FWTK
>> (firewall toolkit)
>>
>> Just a random thought. . .
> 
> Much too random, I'm afraid.  I became a Postfix user/contributor back
> in 2001, because of all the deficiencies of smap, of which I fixed some
> at the time, but it got old fast.
> 
> At this point, nobody should be deploying smap.  Run the Postfix smtpd
> chrooted if you like (and know how to set up chroot jails correctly),
> but even without that, with Postfix you get a more secure and more
> performant MTA than "smap".
> 

Fair Comment!  I had no experience with the program, and it sounded like a good
idea on paper  :-)

Allen C

Re: Rootless postfix

[Allen Coates]

On 25/02/2021 09:43, Emond Papegaaij wrote:
> Hi all,
> 
> We are hardening our services and would like to run postfix as a
> non-root user. All our primary services, including postfix run as
> docker containers. We use postfix as a forwarding agent only: mail is
> delivered from the other services to postfix and then forwarded to
> another MTA. Because postfix runs inside a docker container, we are
> not bound by the default smtp port. It is very easy to map port for
> example 8025 to port 25 via docker. Still, postfix refuses to start as
> non-root. It seems the postfix command has an explicit check to refuse
> to start when not root.
> 
> My question is: is there any way to start the forwarding agent as
> non-root? If not, are there any plans to support this in a future
> release?
> 
> Best regards,
> Emond Papegaaij
> 

It is an *ANCIENT* reference, but the but the O'Reilly book "Building Internet
Firewalls" describes a simple program called smap.

It runs without root privileges and ONLY accepts incoming SMTP connections,
dropping messages into a queue for processing by another program.
(Could this be the MAILDROP queue perhaps?)

They say it is only 700 lines of code long, and is part of the TIS FWTK
(firewall toolkit)

Just a random thought. . .

Allen C

Re: Fwd: Verify Proper method for sender restrictions

[Allen Coates]

On 28/10/2020 15:24, Viktor Dukhovni wrote:
> On Wed, Oct 28, 2020 at 09:05:40AM +0000, Allen Coates wrote:
> 
>> Some time ago (5 years maybe) I discovered that "OK" was not being 
>> universally
>> recognised in every access list;  I cultivated the habit of using the words
>> "ACCEPT" and REJECT" - and have had no problems since.
> That's odd, because in fact Postfix does not support "ACCEPT", but
> smtpd(8) definitely supports "OK" in *ALL* access(5) tables:

If I recall rightly, it was about the time I started using postscreen, and I was
using the file postscreen_access.cidr as a whitelist to bypass the tests in
smtpd_sender_restrictions.

But it was a LONG time ago, and all I can remember is that there was something
about "OK" that didn't give the results I expected.

I will have to have a "play" again...

Allen C

Re: Fwd: Verify Proper method for sender restrictions

[Allen Coates]

On 26/10/2020 20:44, Joey J wrote:
> And within that file have both white & blacklist like so:
> youareok.com    OK
> youarebad.com   REJCT
> 1.2.3.4  550 Block-I dont like you
> 1.5.6.0/24  550 Block I dont like any of you.
> 

Some time ago (5 years maybe) I discovered that "OK" was not being universally
recognised in every access list;  I cultivated the habit of using the words
"ACCEPT" and REJECT" - and have had no problems since.

Allen C

Re: Rejecting messages based on recipient MTA''s IP address

[Allen Coates]

On 01/10/2020 08:01, Ansgar Wiechers wrote:
> On 2020-09-30 Allen Coates wrote:
>>
>> Does the SMTP daemon resolve a destination if there is no MX record?
> 
> Normally Postfix will check for an MX first, and if that is absent check
> for an A record for the domain. This is standard MTA behavior as defined
> in section 5 of RFC 5321.
> 
> <https://tools.ietf.org/html/rfc5321#section-5.1>

and then, presumably, the fall-back relay, if it is defined.

Thanks for clearing up my confusion.

Allen C

Re: Rejecting messages based on recipient MTA''s IP address

[Allen Coates]

On 30/09/2020 15:58, @lbutlr wrote:
> On 29 Sep 2020, at 11:46, J David  wrote:
>> domains that have no email service, i.e., those domains
>> have A records in that range but no MX records at all.

Question at a tangent:-

Does the SMTP daemon resolve a destination if there is no MX record?

Allen C

Re: spam uses my email address as sender in "header from"

[Allen Coates]

It has been suggested in the past that if the "From" header does not contain
both the email address AND the name of its owner (see my address above) then it
may be rejected - or at least flagged as suspect.

Allen C

On 14/09/2020 11:35, Fourhundred Thecat wrote:
> Hello,
> 
> I am receiving spam, where the "header from" is my actual email (ie, the
> email that this spam is delivered to)
> 
> The "envelope from" that I see in postfix logs is some random email.
> 
> What mechanisms are there to reject such messages, which use my email
> address as sender ?
> 
> Can I reject messages that have different envelope from and header from?
> 
> Or what would be the best approach ?
> 
> thanks,

Re: Postfix restrictions

[Allen Coates]

On 07/06/2020 10:51, Nicolas Kovacs wrote:
> Before committing this configuration to my main server, I thought I'd share
> this configuration on the list. Maybe the Postfix gurus among you have the odd
> comment to make.
> 
> My aim is simply to eliminate as much spam as possible (that is, before adding
> SpamAssassin) while keeping false positives to a minimum.
> 
> Any suggestions ?


I protect my mailing-list addresses with a pair of close-coupled ACLs; accept
the list server, then reject the recipient address (with a polite message to
contact me on-list).

>From my main.cf:-
check_client_access cidr:/etc/postfix/listserver_access.cidr
check_recipient_access hash:/etc/postfix/recipient_access

It catches quite a lot of junk, though I do lose an occasional off-list remark.
However, I can whitelist individual senders elsewhere if I wanted. (Or give them
a different address)

Allen C

Re: Dropping email purporting to be from my domain received from the Internet

[Allen Coates]

On 30/05/2020 00:58, Scott A. Wozny wrote:
> In my hypothetical environment, I have an external and an internal relay on
> either sides of a firewall. I want to configure the external system to relay
> both 1) email received from the internal relay to the Internet and 2) email
> received from the Internet to the internal relay (as long as the recipient is 
> on
> my domain). This seems fairly straightforward to accomplish with a combination
> of mynetworks, relay_domains and relayhost or transport_maps configurations.
> 
> 
> Something I would like to drop, though, is email received from the Internet 
> that
> has an address in the MAIL FROM on my domain but ONLY if received from the
> Internet (since it’s a core function of this relay to take identical messages
> relayed from the internal relay bound for Internet mail servers).
> 
> 
> I’ve been going through smtpd_sender_restrictions options look for something
> that fits the bill here, but I can’t seem to find anything that allows me to
> distinguish actions based upon whether or not the sender is not in my_networks
> (making them subject to “stranger rules” which include not sending FROM my 
> domain).
> 
> 
> Is this something that’s relatively straightforward to configure in Postfix or
> do I need a more advanced anti-spam tool to get the configuration flexibility 
> I
> need?
> 

>From my main.cf:-
smtpd_sender_restrictions =  permit_mynetworks, permit_sasl_authenticated,
 reject_non_fqdn_sender,
 reject_unknown_sender_domain
 check_sender_access hash:/etc/postfix/sender_access,
 etc, etc.

Explanation:-
Line 1 will accept all my local machines (Servers and clients)
Lines 2 and 3 will reject rubbish senders;
Line 4  The access file rejects all senders CLAIMING to be from my own domain

and

>From my sender_access file:-
###   Reject any cidercounty sender not from local network
cidercounty.org.uk reject  Sender is not authenticated - s
etc, etc


It works for me, but I'm only a little guy  :-)

Hope this helps

Allen C

Re: Preferred/maintained greylisting options?

[Allen Coates]

On 24/05/2020 23:22, micah anderson wrote:
> We paid for access to spamhaus for a while, but they jacked up the
> prices and now its far too expensive even for their non-profit rate.
> 
> What RBLs do people find to be effective now days? I was looking at
> SpamRats, which I did not know about before, but it looks decent.


The web page https://www.abuseat.org/faq.html  (about half-way down the page)
has an honest - and fairly recent - appraisal of a number of DNSBLs.

The ones I use are listed there.

Allen C

Re: Postfix "IPv6-only" - experience/recommendation question

[Allen Coates]

On 08/05/2020 21:58, Wietse Venema wrote:
> Bob Proulx:
>> How are working and available IPv6 DNSBLs progressing?  That's a
>> critical component which I would love to hear is no longer a missing
>> component.
> 
> zen.spamhaus.org blocks some 15% of IPv6 spam for me. The other 85%
> comes from large providers (outlook.com, gmail.com, etc) that aren't
> blocked with DNSBLs.
> 
>   Wietse
> 

That matches my experience...

Allen C

Re: Postfix "IPv6-only" - experience/recommendation question

[Allen Coates]

On 08/05/2020 17:38, michae...@rocketmail.com wrote:
> Hi all,
> 
> 
> I've a generic question to all more experienced than me postfix users here: 
> Is it nowadays (reasonable) possible to run postfix with IPv6 only? E.g  
> "mail.example.com" and "smtp.example.com" with only ipv6  records in the 
> DNS, no A / ipv4 anymore?
> I am running a domestic server, and 10 percent of inbound emails, and maybe 30
percent of outbound emails still use IPv4.

There was a worry some years ago that IPv6 was not adequately protected by DNS
blacklists, and was thus vulnerable to spam attacks. I have not found this
myself, but am not representative of the world-at-large.

But there seem to be a lot of MX hosts out there which do not accept incoming 
IPv6.

For my server, I have set up a primary MX which is IPv6 only, and a secondary,
which is dual protocol.  Perhaps you could do something similar with your 
situation.


Hope this helps

Allen C

Re: Possible header_check solution?

[Allen Coates]

On 14/04/2020 18:42, Rick King wrote:

> Hello List!
> 
> We have a customer that occasionally receives messages like this...
> 
> Return-Path: 
> From: "Free iPad " 
> To: 
> Subject:Free iPad



> Any suggestions welcome! Thank you!
> 
> 

I am no expert on pattern matching, but could you pick up on the
"mydomain.tld, close-chevron, close-quotes, space, open-chevron" sequence?

Is there any occasion where that would be legitimate?

Allen C

Re: Rejecting emails based on address extension?

[Allen Coates]

On 09/04/2020 00:29, @lbutlr wrote:
> On 08 Apr 2020, at 17:16, Allen Coates  wrote:
>> On 09/04/2020 00:01, @lbutlr wrote:
>>> Given an email address of user+ama...@example.com how can I reject all 
>>> emails to that address that do not come from amazon.com?
>>>
>>> I think I did something like this once but if I did, I didn’t keep notes. :/
>>>
>>>
>>
>> Funny you should mention that - within the last half-hour I have come up with
>> (for header checks file):-
>>
>> if /^From:.*amazon\.co\.uk/  
>> !/\<.*\@.*amazon\.co\.uk\>/  WARN Fake Amazon address
>> endif
>>
>> Completely untested - it would be interesting to know if I am getting my 
>> regexp
>> syntax right.  :-)
>>
>> Not quite what you wanted - but hope it helps.
> 
> Useful, but not helpful in this case because there is no way to have postfix 
> check two headers
> 
> (If TO contains “amazon” and FROM_ does not contain “amazon”) isn’t something 
> postfix can do, but perhaps there is a milter out there that can.
> 
> I can do it in Sieve, but I would prefer to reject them before they get 
> delivered.
> 
> 

Thinking on a tangent - I have a method of protecting my mailing-list
identities; I accept the list-server(s) by host identity and then reject the
destination address(es) :-

check_client_access cidr:/etc/postfix/listserver_access.cidr,
check_recipient_access hash:/etc/postfix/recipient_access

Allen C

Re: Rejecting emails based on address extension?

[Allen Coates]

On 09/04/2020 00:01, @lbutlr wrote:
> Given an email address of user+ama...@example.com how can I reject all emails 
> to that address that do not come from amazon.com?
> 
> I think I did something like this once but if I did, I didn’t keep notes. :/
> 
> 

Funny you should mention that - within the last half-hour I have come up with
(for header checks file):-

if /^From:.*amazon\.co\.uk/ 
!/\<.*\@.*amazon\.co\.uk\>/ WARN Fake Amazon address
endif

Completely untested - it would be interesting to know if I am getting my regexp
syntax right.  :-)

Not quite what you wanted - but hope it helps.

Regards

Allen C

Re: Disabling TLSv1

[Allen Coates]

Virtually all my TLSv1 connections come from this mailing list...

Would there be any mileage in disabling OUTBOUND TLSv1 connections while
accepting inbound for a little while longer?

Allen C

On 05/03/2020 20:08, ratatouille wrote:
> Hello!
> 
> Don't know why TLSv1 is still offered on our servers running
> 
> mail_version = 2.11.3
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> 
> but a scan by ssllabs.com or with testssl.sh shows TLSv1 is still supported.
> 
> I am not sure what's wrong. What do I miss?
> 
> Other parameters I set:
> smtpd_tls_CApath = /var/lib/ca-certificates/pem
> smtpd_tls_ask_ccert = yes
> smtpd_tls_auth_only = yes
> smtpd_tls_cert_file = /etc/letsencrypt/live/bitcorner.de/fullchain.pem
> smtpd_tls_ciphers = high
> smtpd_tls_dh1024_param_file = ${config_directory}/dhparams.pem
> smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, 
> EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA, secp224r1, 
> ECDHE-RSA-DES-CBC3-SHA
> smtpd_tls_key_file = /etc/letsencrypt/live/bitcorner.de/privkey.pem
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1
> smtpd_tls_received_header = yes
> smtpd_tls_req_ccert = no
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_database = 
> btree:/var/lib/postfix/smtpd_tls_session_cache
> smtpd_tls_session_cache_timeout = 3600s
> 
> Regards
> 
>   Andreas
> 

Re: How to restrict imposters

[Allen Coates]

On 20/02/2020 03:39, Bob Proulx wrote:
> I do a slight variation on this that I think is slightly better.
> Instead of pcre tables I use hash tables.  Which should be slightly more
> efficient.  And won't suffer from common substring matches such as
> hitting by accident on goodkreme.com or otherkreme.com or
> krispykreme.com and so forth. :-)
> 
> My /etc/postfix/helo-access file:
> # Reject anybody that HELO's as being in our own domains.
> # Since this occurs after permit_mynetworks this does not
> # reject local clients.
> proulx.com  REJECT  You are not proulx.com.


I receive quite a few messages claiming to be from "accounts", "helpdesk", or
"personnel", so I have a very similar clause in my /etc/postfix/sender-access
file.  Again, it is after permit_mynetworks so it does not reject local clients.

Allen C

Re: postfix for IoT

[Allen Coates]

On 20/01/2020 02:31, Viktor Dukhovni wrote:
> On Mon, Jan 20, 2020 at 08:38:46AM +0800, Wesley Peng wrote:
> 
>> How to compile postfix into the  Embedded operating system (such as the
>> home router) and make it as a mail gateway for  Smart home appliances?
> 
> Most embedded systems are not sufficiently capable of running Postfix,
> nor would I recommend queueing email on an embedded router.
> 
> You can forward (DNAT) the relevant ports to a real computer.

Synology NAS boxes can run a Postfix/Dovecot system very nicely - even webmail
and RADIUS, if you want them.  I suppose other NAS boxes will do something very
similar, but I have no direct knowledge.

hope this helps.

Allen C

Re: What are these types trying to do?

[Allen Coates]

On 30/12/2019 22:32, Gerben Wierda wrote:
> Now that Finally have a postfix back with actual logging, I noticed this in 
> my log:
> 
> Dec 30 23:26:09 mail postfix/postscreen[16020]: CONNECT from 
> [182.99.42.88]:49546 to [192.168.2.66]:25
> Dec 30 23:26:10 mail postfix/postscreen[16020]: PREGREET 14 after 0.26 from 
> [182.99.42.88]:49546: EHLO ylmf-pc\r\n
> Dec 30 23:26:10 mail postfix/smtpd[16048]: connect from unknown[182.99.42.88]
> Dec 30 23:26:10 mail postfix/smtpd[16048]: lost connection after EHLO from 
> unknown[182.99.42.88]

<< etc >>

if you set the parameter

postscreen_greet_action = ENFORCE, or
postscreen_greet_action = DROP

these connections will be held back by postscreen, and will not actually reach
postfix.

The ENFORCE option will collect the (envelope) FROM and TO addresses for stats
purposes, if they are proffered.

Hope this helps

Allen C

Re: lots of connections that make no sense

[Allen Coates]

On 15/11/2019 16:15, @lbutlr wrote:
> On 15 Nov 2019, at 03:21, Allen Coates  wrote:
>> Disabling auth does not stop them from trying;  I scan my logs for the string
>> "auth=0/1", and add the offending IP address to a blacklist - a 
>> do-it-yourself
>> fail2ban.
> 
> Seems like a good idea.
> 
> Something like this?
> 
> pfctl -t badguys -T add $(grep "auth=0/1" /var/log/mail.log | egrep -o 
> "\[[^]]*\.[^]]*\]" | tr -d '[]’)
> 

I use cut statements rather than egrep - not as elegant but it isolates both
IPv4 and IPv6 addresses.

I sweep about two days' worth of logs, and offending addresses go into a
postscreen blacklist.  This is recompiled when there is something new.

Repeated postscreen disconnections (for whatever reason) escalate into an
iptables drop-list, where they stay until they stop trying to connect.

Allen C

Re: lots of connections that make no sense

[Allen Coates]

On 15/11/2019 12:33, Wietse Venema wrote:
> Jeffrey 'jf' Lim:
>>> Disabling auth does not stop them from trying;  I scan my logs for the 
>>> string
>>> "auth=0/1", and add the offending IP address to a blacklist - a 
>>> do-it-yourself
>>> fail2ban.
>>>
>>
>> It should. Unless they're the dumbest bots of all time, because you
>> should have stopped advertising auth in your EHLO response after
>> disabling.
> 
> Some bots are stupid. My server does not announce AUTH, but that
> does not stop them from trying.
> 
>   Wietse
> 

Blacklisting miscreants (once you have spotted them) stops them from trying
other probes/attacks.

Allen C

Re: lots of connections that make no sense

[Allen Coates]

On 15/11/2019 05:10, Fourhundred Thecat wrote:
> On 15/11/2019 06.06, Jeffrey 'jf' Lim wrote:
>>
>> ok then this makes sense. I've seen bots retry multiple passwords at
>> one go in the past; Fourhundred are all of these "auth=0/1"?
> 
> yes, all are "auth=0/1".
> 
> I have disabled auth on port 25, and I am using non-standard port for
> client authentication.
> 

Disabling auth does not stop them from trying;  I scan my logs for the string
"auth=0/1", and add the offending IP address to a blacklist - a do-it-yourself
fail2ban.

Allen C

Re: Dictionary attacks

[Allen Coates]

On 03/11/2019 02:42, Wietse Venema wrote:
> John Schmerold:
>> What is the best way to protect against dictionary attacks in Postfix?
>  
> Reportedly, fail2ban (no first-hand experience, because I have no
> SASL clients).
> 
>   Wietse
> 

I run a home-brewed fail2ban look-alike; I find it almost as useful as 
postscreen.

Another mailling list suggests an ACL based on IP netblocks, to define a
"service area" where incoming AUTH connections are permitted.

Allen C

Re: Postfix is not open relay but send spam

[Allen Coates]

On 15/10/2019 08:27, Julien Michaux wrote:
> Time to time, my server is attack and he sends spam. All spam are from a
> specific address "cy...@mydomain.com" I tried many things but nothing works> 
> I have to stop postfix for some hours and attack ends until next time.
> 

Have you tried putting "cy...@mydomain.com reject" into your sender_access file?

It is a crude quick-fix, and would also put a marker in your log-file.

hope this helps

allen C

Re: How to avoid being classified as spam by Google?

[Allen Coates]

On 07/10/2019 06:11, martin f krafft wrote:
> Quoting "Wietse Venema", who wrote on 2019-10-06 at 19:13 Uhr -0400:
>> Perhaps the SMTP client IP address 2001:db8:bad::cafe:: has no PTR record (or
>> the name does not resolve to 2001:db8:bad::cafe::).
> 
> Good point, but the address has a PTR record to a name with an  record
> pointing to the address.
> 
Only one set of double-colons is allowed in an IPv6 address.   It expands to an
unspecified number of zeros; doing it twice results in ambiguity.

Allen C

Re: Suggestions for less spam

[Allen Coates]

On 24/09/2019 12:08, Wietse Venema wrote:
> Dominic Raferd:
>> On Tue, 24 Sep 2019 at 11:31, Matus UHLAR - fantomas 
>> wrote:
>>
>>> On 24.09.19 12:11, Paul van der Vlis wrote:
 I am using now much of your setting and it seems to help. Thanks a lot!
>>>
>>> I would just like to note that all those reject_rbl_client directives are
>>> prone to errors when any of those blacklist fails.
>>
>>
>> An occasional individual blacklist lookup failure is not a problem, and is
>> rare (except for b.barracudacentral.org). I have not felt the need for
>> postscreen but of course it is a good tool: I prefer to block by ip last
>> and to log helo, envelope sender & recipient as well as client ip. This
>> puts a little more load on the server, but information is power.
> 
> Postscreen logs the helo, sender, recipient, client IP address
> and client port when it rejects a connection.
> 
>   Wietse
> 

In postscreen I use two access control lists - the first accepts known good mail
servers;  the second rejects entire "problem" countries - in my case China,
North Korea, Brazil, and Eastern Europe.  The country list is recompiled every
week, and the data comes from www.ipdeny.com.

In postfix, messages to a mailing-list identity are refused if they DON'T come
from the list-server (or a few whitelisted individuals). Senders see a polite
message to contact me on-list.

Allen C

Re: OT: Postscreen and scoring/blocking by ISP

[Allen Coates]

On 30/05/2019 22:21, Allen Coates wrote:
> Currently, I am using a CIDR access-control-list to block (in PostScreen) 
> hosts
> from certain "nuisance" countries.  A weekly script derives the netblocks from
> the zone lists published by http://www.ipdeny.com

A similar script could derive a DNS zone file - with varying levels of "badness"
- if you wanted to run your own RBL...

Allen C

Re: OT: Postscreen and scoring/blocking by ISP

[Allen Coates]

There is an RBL, zz.countries.nerd.dk, which will return a code based on country
of origin - or if you substitute a country code (eg uk.countries.nerd.dk) it
will return 127.0.0.1 if the host "belongs" to that country; it can be used to
load the final RBL score for an individual country.  I don't know how robust
these people are, but they are certainly sufficient for a domestic server.

Currently, I am using a CIDR access-control-list to block (in PostScreen) hosts
from certain "nuisance" countries.  A weekly script derives the netblocks from
the zone lists published by http://www.ipdeny.com

Allen C

On 30/05/2019 21:40, Charles Sprickman wrote:
> Hi David (and re-adding the list in case we say something interesting),
> 
> “Snowshoe spam”, as I understand it is basically a spammer sending batches 
> from a list of “clean” IPs - not too many emails per IP, but lots of hosts to 
> send from.  By the time an IP is blacklisted, it’s already done spamming.
> 
> Another theory I have is these folks work alphabetically, as the client I 
> have the most issues with has a domain starting with “b” and they just see 
> way more spam. Could just be random, or that it’s a very old domain (20+ 
> years).
> 
> Anyhow, I have my own list of hosting operations that seem to just keep being 
> used for this and I’d like to start them off at 4-5 points in my postscreen 
> config.
> 
> My typical filtering setup is Postscreen with a bunch of RBLs, and generally 
> I need 3-4 of the reliable RBLs to hit a sending IP before it hits the 
> threshold. After that, the mail moves to SpamAssassin. It scores most of the 
> missed emails around 2-3 points, almost exclusively via Bayes.
> 
> Thanks,
> 
> Charles
> 
>> On May 20, 2019, at 8:49 PM, David Mehler  wrote:
>>
>> Hello,
>>
>> I don't know about the netblocks your looking for, but what is
>> snowshoe spam? What does your spam blocking configuration look like? I
>> can send you mine if you think it would help.
>>
>> Dave.
>>
>>
>> On 5/20/19, Charles Sprickman  wrote:
>>> Hi all,
>>>
>>> I was looking through a few lists of RBLs and I’m not finding quite what I
>>> want.
>>>
>>> I have quite a bit of my spam blocking working fairly well, but I’m seeing
>>> quite a bit of “snowshoe spam” from a few providers. Rather than look up
>>> their netblocks and outright block them, I’d like to incorporate them into
>>> the postscreen scoring process.  As time goes on, I’m sure I’ll find others,
>>> but I do see ColoCrossing and Limestone Networks as pretty consistent
>>> sources.
>>>
>>> Are there any RBLs that exclusively deal with blocking by netblock/owner
>>> that I’m missing? Or am I better off just setting up a local RBL with the
>>> things I want to cover?  And while I’m asking, any interesting RBLs you
>>> folks use that are based on non-standard criteria (country-based RBLs, lists
>>> of RFC-ignorant hosts, etc.)?
>>>
>>> Thanks,
>>>
>>> Charles
> 
> 

Re: GEO IP based restrictions?

[Allen Coates]

http://www.ipdeny.com publish IP address-lists sorted by country zones; a script
can quite easily derive a .cidr access-list (or perhaps a DNS zone file).

Alternatively, there is an RBL, zz.countries.nerd.dk, which will return a code
based on country of origin - or if you substitute a country code (eg
uk.countries.nerd.dk) it will return a yes/no response, to blacklist (or
whitelist) an individual country.  I don't know how robust these people are, but
they are certainly sufficient for a domestic server.

I have tried both methods to postscreen, with some success.

Hope this helps

Allen C


On 14/05/2019 18:41, @lbutlr wrote:
> Has anyone implemented geo based restrictions for postfix login connections, 
> or is this something that needs to be done in dovecot?
> 
> I was thinking someway to add most of Asia and Eastern Europe to postscreen 
> checks would be useful?
> 

Re: How "safe" is reject_unknown_helo_hostname?

[Allen Coates]

I usually put my access-control lists EARLY,  so I have yes / no /
"further-processing" options

Allen C


On 27/04/2019 23:21, @lbutlr wrote:
> 
> smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname,
> reject_non_fqdn_helo_hostname, check_helo_access
> pcre:/etc/postfix/helo_checks.pcre permit
> 

Re: How "safe" is reject_unknown_helo_hostname?

[Allen Coates]

I can see that a mail-host might announce itself as "example.com" and not
"mail.example.com"   Getting DNS configuration letter-perfect can be quite 
tricky.

One must be tolerant of SOME mistakes - but absolute rubbish, reserved TLDs and
people claiming to be me will be thrown out (at this server) whatever the RFCs
might say.

It is getting the balance right...

Allen C


On 26/04/2019 14:46, Phil Stracchino wrote:
> On 4/25/19 7:56 PM, Allen Coates wrote:
>> I have been looking at the configuration parameter
>> "reject_unknown_helo_hostname", with a view to using it to resist spam.
>>
>> I know it is reasonably safe to reject an incoming email on an invalid or
>> non-fqdn HELO hostname, but *UNKNOWN?*
>>
>> I don't receive a sufficient corpus of email to make a reasoned judgment.
>>
>> Your comments would be appreciated.
> 
> 
> I don't see a fundamental risk in rejecting mail from servers claiming a
> HELO hostname that doesn't resolve.  If you're already going to reject
> HELO from non-fqdn or invalid hostnames, why accept it from ones that
> don't resolve at all?
> 
> 

How "safe" is reject_unknown_helo_hostname?

[Allen Coates]

I have been looking at the configuration parameter
"reject_unknown_helo_hostname", with a view to using it to resist spam.

I know it is reasonably safe to reject an incoming email on an invalid or
non-fqdn HELO hostname, but *UNKNOWN?*

I don't receive a sufficient corpus of email to make a reasoned judgment.

Your comments would be appreciated.

Allen C

Re: Assistance to protect from spam flood

[Allen Coates]

On 12/01/2019 11:09, Nick Howitt wrote:
> 
> Is there anything further I can do to cut down or stop this spam? Also are 
> there more effective blocks I can do to
> lighten the load on the server and reduce traffic?
> 
> Thanks,
> 
> Nick

If you are troubled by Chinese hosts, you might also like to look at the thread 
"SMTP filter using geo-localization" for
ideas.

But as others have said, ditching the secondary MX servers and setting up 
Postscreen should be your first two priorities.

Talk to me off-list.

Allen C

Re: Postscreen concurrency limits

[Allen Coates]

On 14/12/2018 06:13, Viktor Dukhovni wrote:
> 
> 
>> On Dec 13, 2018, at 8:25 PM, Alex  wrote:
>>
>> We had a Mimecast user report today that their mail was being rejected
>> with a 4.7.0 "too many connections" error. This is a "soft" error, in
>> that the mail client will later attempt to resend, correct?
> 
> Should be.
> 
>> Isn't the default of 50 concurrent connections sufficient for most
>> environments? Is there really any reason I should consider increasing
>> that limit?
> 
> Do read the log you post...
> 
>> Dec 13 17:01:18 mail03 postfix/smtpd[27153]: warning: Connection
>> concurrency limit exceeded: 5 from us-smtp-delivery-100.mimecast.com[2
>> 16.205.24.100] for service smtpd
> 
> 5 < 50.

I have a hunch that this is an excess count.  Some while ago I had a mini-DoS 
attack.  As I recall, the server accepted
the first 50 connections and then started counting the refusals.

Earlier log entries should prove it one way or the other.

Allen C

Re: how set postfix server as non-functional

[Allen Coates]

On 25/10/18 11:12, Viktor Dukhovni wrote:
>> On Oct 25, 2018, at 5:55 AM, Allen Coates  wrote:
>>
>> There are some anti-spam projects which offer MXes for your use.
>> You set one up with the LOWEST prioity (your "MX of last resort"); If a 
>> message reaches it, the MX will collect stats
>> and then return a TEMPFAIL.
> 
> I can't recommend this either.  You're directing some fraction of
> your email for delivery attempts to a third party.  They may get
> to log envelope sender and recipient addresses for any traffic
> that comes their way.  The traffic may well be legitimate, if
> your primary servers are briefly unreachable or tempfail resolution
> of the sending domain.  If you're doing DANE, you now need DANE
> support on the honeypots, ...
> 
> My advice is to run a decent mail plant with no kludges.  Instead
> I see a non-trivial fraction of folks creating fake MX hosts with
> an address of "1.1.1.1" or other addresses they are "sure" won't
> accept email.  This is all a bad idea.  The benefits are marginal
> at best.  Don't do it.
> 

I will go along with that.  I have no actual experience of these anti-spam 
schemes, I've only read about them.

Superficially they sound like a good idea, but I seem to be getting along quite 
well without them :-)

Postscreen is far and away the best "add-on" I have encountered to date.

Re: how set postfix server as non-functional

[Allen Coates]

On 25/10/18 07:33, Viktor Dukhovni wrote:
> On Thu, Oct 25, 2018 at 08:11:35AM +0200, Poliman - Serwis wrote:
> 
>> Hi. I heard that having a non-functional server as the primary MX is a
>> well-known trick to reduce the amount of incoming spam, as most software
>> used by spammers will only ever try the highest-priority MX. How to do this?
> 
> No.  This is a myth, and reduces the reliability and performance
> of legitimate email delivery.  Use a decent RBL, postscreen(8) may
> help to reduce the load on the server and keep smtpd(8) more available
> for legitimate email.
>
Yesterday, my Postscreen blocked 92 percent of incoming connection attempts:-

POSTSCREEN  ATTRITION  REPORT  FOR  Wed 24 Oct 2018

 Connections to Postscreen - IPv6:  28
 IPv4: 395
 Individual hosts: 105

 Misc disconnections   392
  Black-listed Locally:100
  Black-listed by DNSBL:   392
  Pre-greets:   13
  Hang-ups: 11
  Command Pipelining:1

 White-listed:  30
 PASSed by PostScreen:   1
  New:   1

 Refusal Ratio:  92 percent




There are some anti-spam projects which offer MXes for your use.
You set one up with the LOWEST prioity (your "MX of last resort"); If a message 
reaches it, the MX will collect stats
and then return a TEMPFAIL.

Legitimate mail would not be affected as a retry will be forced, though you may 
want to find out what the project does
with the stats they collect.

I think Project Honeypot does one, though they are more interested in Web 
decoys.

Hope this helps

Allen C

Re: Could you please explain a warning message

[Allen Coates]

Thanks for your reply - I am reassured.

My server is a slow machine with limited memory - not much better than a 
Raspberry Pi, but designed to run 24/7 - so it
is not surprising that processes will conflict from time to time.

One warning in eight months is more than acceptable :-)

Thanks again

Allen C


On 08/10/18 12:03, Ralf Hildebrandt wrote:
> * Allen Coates :
>> Yesterday I saw the following warning message in my logs:-
>>
>> 2018-10-06T14:11:19+01:00 geronimo postfix/postscreen[8194]: warning: 
>> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
>> delay is 151 ms
> 
> Oct  2 02:01:40 mail-cbf postfix/postscreen[23257]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 343 ms
> Oct  2 02:03:16 mail-cbf postfix/postscreen[23257]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 155 ms
> Oct  3 18:34:07 mail-cbf postfix/postscreen[23257]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 137 ms
> Oct  8 11:21:19 mail-cbf postfix/postscreen[65199]: warning: 
> psc_cache_update: btree:/var/lib/postfix/postscreen_cache update average 
> delay is 112 ms
> 
> Quoting from 
> http://postfix.1071664.n5.nabble.com/psc-cache-update-td10059.html
> 
> "It is a bit sluggish. The warning threshold is 100ms. It should not 
> take this long to insert one key/pair into the database. Perhaps your 
> system's disk is very busy, or you're on a VM slice, or your clock is 
> not stable. If this happens frequently you need to find out why."
> 
> and
> 
> "If this happens often, this means that postscreen cannot handle 
> more than 10 SMTP connections per second, or that your system clock 
> is jumping (as in: running inside a VM). 
> 
> I see the warning once a day on my lightly-loaded server with a 
> single 15kRPM disk under an ancient CPU; the timing suggests that 
> this happens while some cron job is doing house cleaning. 
> 
> I added this check because someone insisted on running postscreen 
> on top of an SQL database, and complained that postscreen performance 
> was erratic. After I added the warning he stopped complaining."
> 

Could you please explain a warning message

[Allen Coates]

Yesterday I saw the following warning message in my logs:-

2018-10-06T14:11:19+01:00 geronimo postfix/postscreen[8194]: warning: 
psc_cache_update:
btree:/var/lib/postfix/postscreen_cache update average delay is 151 ms

A tenth of a second is an ENORMOUS delay for an SSD, and my immediate thought 
was/is an incipient disc failure, but
the monthly disc tests say 95 percent of the life expectancy remains.

I have swept my logs since February and this is the only instance of the 
message.

I am operating a domestic server (50 messages a day), running on a Synology NAS 
device, with things in the background
I can't turn off.

Could someone please explain what this message implies.

Many thanks

Allen C

Perhaps I should get some back-ups done :-)

Re: What is postscreen_dnsbl_reply_map use for?

[Allen Coates]

On 23/09/18 15:46, Bill Cole wrote:
> On 23 Sep 2018, at 10:13 (-0400), John anderson wrote:
> 
>> What is the meaning of `postscreen_dnsbl_reply_map` in postscreen (postfix) ?
>> I've read from documentation:
>>
>>> if your DNSBL queries have a "secret" in the domain name, you must censor
>>> this information from the postscreen(8) SMTP replies ([1])
>>
>> And from manual:
>>
>>> A mapping from actual DNSBL domain name which includes a secret password,
>> to the DNSBL domain name that postscreen will reply with when it rejects
>> mail. When no mapping is found, the actual DNSBL domain will be used. ([2])
>>
>> I don't understand about *a secret password* means, how a DNS domain name
>> will include a password?
>>
>> Could you explain me?
> 
> Some non-free DNSBLs give customers a secret DNS label to insert between the 
> base domain and the query target (i.e.
> octet-reversed IP or domain name) as a form of authentication. Obviously this 
> "secret" isn't well-protected from
> snooping by actors who can sniff the DNS traffic, but as a practical matter 
> it is safe enough for most DNSBLs' needs.
> 
> -- 
> Bill Cole
> b...@scconsult.com or billc...@apache.org
> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
> Available For Hire: https://linkedin.com/in/billcole
> 

You can also use it to redirect ALL your DNSBLs to the same reference website 
(for arguments sake,
http://multirbl.valli.org)

Allen C

Re: How to white list

[Allen Coates]

On 23/07/18 21:17, dur...@mgtsciences.com wrote:
> I have whitelisted the ip in postscreen_access.cidr.  I can see the 
> 'whitelisted' for postscreen in log.
> But it does not get past smtpd.
> 
> I do not want to remove reject_invalid_helo_hostname as this really opens 
> up more spam.  So how
> do I white list the ip for smtpd?
> 
> Jul 23 13:53:32 postfix/smtpd[16279]: Anonymous TLS connection established 
> from unknown[65.100.117.244]: TLSv1.2 with cipher AECDH-AES256-SHA 
> (256/256 bits)
> Jul 23 13:53:32 postfix/smtpd[16279]: NOQUEUE: reject: RCPT from 
> unknown[65.100.117.244]: 450 4.7.1 Client host rejected: cannot find your 
> reverse hostname, [65.100.117.244]; from= 
> to= proto=ESMTP helo=
> Jul 23 13:53:33 postfix/smtpd[16279]: disconnect from 
> unknown[65.100.117.244] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 rset=1 
> quit=1 commands=6/8
> 
> Thank you,
> 
> Durwin
> 
> === main.cf ===

[snip]

> shlib_directory = /usr/lib64/postfix
> smtp_helo_name = mail.mycompany.com
> smtpd_authorized_xclient_hosts = 172.23.93.0/24
> smtpd_banner = mail.mycompany.com ESMTP $mail_name ($mail_version)

> smtpd_client_restrictions = reject_unknown_reverse_client_hostname
THIS is the line which is rejecting the email;

you could try
smtpd_client_restrictions = permit_mynetworks,
check_client_access cidr:/etc/postfix/postscreen_access.cidr
reject_unknown_reverse_client_hostname

anything white-listed by postscreen will bypass client restrictions also

> smtpd_delay_reject = yes
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks check_helo_access 
> hash:/etc/postfix/helo_access reject_invalid_helo_hostname permit

Two useful (and safe) additions to your smtpd_helo_restrictions are:
reject_invalid_helo_hostname, and
reject_non_fqdn_helo_hostname
these force the HELO argument to be RFC compliant

Hope this helps

Allen C

Re: Greylisting?

[Allen Coates]

Late last year I tried the Postscreen "deep protocol tests" as a
primitive form of greylisting; It was a high-maintenance exercise for
minimal benefit and I have since stopped using it.

Google and the like, use a different mail server for each connect
attempt.  You need an actively maintained whitelist to bypass the
grey-list process.

Also, (in my case) I was plagued by Ukrainian spamming mail servers;
they just retried and got through.

The experiment DID stop a few zombies, but not many.

Allen C



On 12/03/18 02:39, john wrote:
> I  was just taking a look through my postfix configuration and noticed
> that I have a "check_policy_service" for postgrey a greylisting service.
> 
> I greylisting still considered worthwhile or should I drop it?
> 
> TIA
> 
> John A
> 
> 
> 

Re: Question regarding smtpd DNS resolution

[Allen Coates]

On 05/02/18 00:12, Viktor Dukhovni wrote:
> 
> 
>> On Feb 4, 2018, at 5:46 PM, J Doe  wrote:
>>
>> Feb 4 15:05:46 server postfix/smptd[718]: warning: hostname 
>> 1-2-3-4.dyn.isp.net does not resolve to address 1.2.3.4: Name or service not 
>> known
>>
>> Does this mean that:
>>
>> 1. smtpd receives a connection from an smtp client and does a reverse DNS 
>> lookup
>> 2. smtpd performs a forward DNS lookup on the result and compares the 
>> resulting IP address to the initial IP
>> 3. If the IP addresses don’t match it reports this error
>>
>> ... or is some other logic used to generate the error message?
> 
> The message happens when the hostname obtained from 1 fails to resolve
> to an IP address that can be compared in 2.  The error is a hard error
> (NXDomain).
> 

Is this a reliable bad-host detector?   The last three instances in my
log were subsequently rejected by a DNSBL

Allen C

Re: Best practice when setting up a mail relay

[Allen Coates]

On 06/01/18 18:27, Jonathan Sélea wrote:

> For example:
> www.siteA.xyz on ServerY is hacked and someone is using mail() in order
> to send hundreds of thousands email via localhost - that is relayed to
> the smtp relay (that only accepts mail from internal servers). And
> instead of relaying them out to the web it does stop thoose kind of email.
> 
> Is that possible? Can postfix just dump the emails "down the drain"
> instead of sending them? And can that be triggered if ServerY sends 100
> emails in 10 seconds for example.


In main.cf:-

smtpd_client_connection_count_limit  (default is 50 connections)
Limits the number of simultaneous connections
a remote host can make.

smtpd_client_connection_rate_limit (disabled by default)
Limits the number of connection attempts
a remote host can make per time unit.

anvil_rate_time_unit (default is 60 seconds)
Sets the value of the time unit.

A simple script can pick up the connect refusal from the postfix log,
and add the host address to an iptables block-list.

Allen C

Re: PSA University of Michigan research IP space

[Allen Coates]

On 08/12/17 03:59, Viktor Dukhovni 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?
> 

The netblocks (above) are not the whole university, but only the range
used by the research scans.

The website (also above) explains what the research is all about, and
should you wish to opt out of the research, invites you to drop the
aforementioned netblocks in your firewall.

To me, this seems a very reasonable and equitable arrangement.

Allen C

Message Rejection

[Allen Coates]

Is there any way of making a bad email address (eg a spam-trap) reject
an entire multi-destination transaction?

If one RCPT TO command is to a spamtrap address, then that message will
be spam;  you do not want it being delivered to any other (genuine) RCPT
TO destinations.

Allen C

Re: Regarding ciphers

[Allen Coates]

On 23/11/17 09:30, Jonathan Sélea wrote:
> 
> My question is, can I improve  this futher or do you guys/girls have any
> opinion regarding this?
> I am grateful for all comments, tips or other suggestions :)
> 
> / Jonathan
> 

Thinking at a tangent, if your messages are particularly sensitive, you
may wish to consider encrypting the original message with something like
PGP (or GPG)

Postfix only encrypts the comms link; once messages reach the server,
they are queued/stored in clear again.

Allen C

Re: Regarding ciphers

[Allen Coates]

On 23/11/17 09:30, Jonathan Sélea wrote:

> My question is, can I improve  this futher or do you guys/girls have any
> opinion regarding this?
> I am grateful for all comments, tips or other suggestions :)
> 
> / Jonathan
> 

If the remote host does not support the cyphers you deploy, then you
have the choice of letting the message delivery fail, or sending the
message unencrypted.

It is usually considered better to use a weak cypher than none at all.

The default settings of postfix will try to use an encrypted connection,
but will fall back to unencrypted - as a "last resort".

Allen C

Re: Ban IP or Host

[Allen Coates]

To limit repeating offenders, you might like to try playing with

smtpd_client_connection_count_limit,
smtpd_client_connection_rate_limit, and
anvil_rate_time_unit

For my quiet (domestic) server, I have set limits of two simultaneous
connections, and twelve connections per hour.

If a remote host exceeds either of these limits, the connection request
is refused.

Ironically, the refusal often generates more log entries than the actual
offence,  but it is an extra hurdle for the "baddies" to circumvent.

Alternatively, if it is only one host doing this, you could add
"91.200.12.56  REJECT" into your hosts access-control file.


Allen C


On 16/10/17 12:32, Maurizio Caloro wrote:
> Hello Together
> Please i have a lot of this messages, exist here any possibilities to ban
> this ip or host, so this will try every view min.
> 
>  
> 
> Oct 16 12:33:59 mail postfix/smtpd[23436]: warning: hostname walkerj235.com
> does not resolve to address 91.200.12.56
> 
> Oct 16 12:34:03 mail postfix/smtpd[23436]: warning: unknown[91.200.12.56]:
> SASL LOGIN authentication failed: ZuFzc3waA31Zb
> 
> Oct 16 12:38:06 mail postfix/smtpd[20167]: warning: hostname walkerj235.com
> does not resolve to address 91.200.12.56
> 
> Oct 16 12:38:08 mail postfix/smtpd[20167]: warning: unknown[91.200.12.56]:
> SASL LOGIN authentication failed: ZuFzc3waA31Zb
> 
> Oct 16 12:42:16 mail postfix/smtpd[27854]: warning: hostname walkerj235.com
> does not resolve to address 91.200.12.56
> 
> Oct 16 12:42:20 mail postfix/smtpd[27854]: warning: unknown[91.200.12.56]:
> SASL LOGIN authentication failed: ZuFzc3waA31Zb
> 
> Oct 16 12:44:12 mail postfix/smtpd[11374]: warning: unknown[80.82.77.153]:
> SASL LOGIN authentication failed: ZuFzc3waA31Zb
> 
> Oct 16 12:46:28 mail postfix/smtpd[30250]: warning: hostname walkerj235.com
> does not resolve to address 91.200.12.56
> 
> Oct 16 12:46:31 mail postfix/smtpd[30250]: warning: unknown[91.200.12.56]:
> SASL LOGIN authentication failed: ZuFzc3waA31Zb
> 
> Oct 16 12:47:46 mail postfix/smtpd[30250]: warning: unknown[191.96.249.214]:
> SASL LOGIN authentication failed: ZuFzc3waA31Zb
> 
> Oct 16 12:50:46 mail postfix/smtpd[1148]: warning: hostname walkerj235.com
> does not resolve to address 91.200.12.56
> 
>  
> 
> Thanks for any help
> 
> Reards
> 
> Mauri
> 
> 

Re: Postscreen exceptions and blacklisting

[Allen Coates]

In your exceptions list, use ACCEPT or REJECT;
DUNNO means "let something else decide" ...

Allen C

On 08/09/17 09:36, Nikolaos Milas wrote:
> Hello,
> 
> I have tried to whitelist some servers for postscreen, but I notice that
> they continue to get blocked if they are blacklisted.
> 
> What I am doing wrong in whitelisting them?
> 
> How can I successfully whitelist them so that they are not blocked even
> if they are blacklisted in a RBL/RSBL?
> 
> Here is a session with remote server 195.134.100.81 (ours is 62.217.124.2):
> 
> Aug 31 11:14:01 mailgw3 postfix/postscreen[6476]: CONNECT from
> [195.134.100.81]:50520 to [62.217.124.2]:25
> Aug 31 11:14:02 mailgw3 postfix/dnsblog[6328]: addr 195.134.100.81
> listed by domain b.barracudacentral.org as 127.0.0.2
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DNSBL rank 2 for
> [195.134.100.81]:50520
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
> from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
> [195.134.100.81] blocked using b.barracudacentral.org; from=<>,
> to=, proto=SMTP, helo=
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: NOQUEUE: reject: RCPT
> from [195.134.100.81]:50520: 550 5.7.1 Service unavailable; client
> [195.134.100.81] blocked using b.barracudacentral.org;
> from=, to=, proto=SMTP,
> helo=
> Aug 31 11:14:07 mailgw3 postfix/postscreen[6476]: DISCONNECT
> [195.134.100.81]:50520
> 
> My setup (on Postfix 2.11.0):
> 
> # postconf -n
> allowed_list1 = check_client_access cidr:/etc/postfix/vmail.cidr,reject
> allowed_list2 = check_client_access
> cidr:/etc/postfix/internalnetworks.cidr,reject
> command_directory = /usr/sbin
> config_directory = /etc/postfix
> content_filter = smtp-amavis:[127.0.0.1]:10024
> daemon_directory = /usr/libexec/postfix
> data_directory = /var/lib/postfix
> debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
> xxgdb $daemon_directory/$process_name $process_id & sleep 5
> default_process_limit = 50
> disable_vrfy_command = yes
> enable_long_queue_ids = yes
> header_checks = pcre:/etc/postfix/blacklisted_maillists
> html_directory = no
> inet_interfaces = all
> inet_protocols = ipv4, ipv6
> local_recipient_maps =
> local_transport = error:local mail delivery is disabled
> mail_name = NOA Mail Srv XAPITI XPICTOY
> mail_owner = postfix
> mailq_path = /usr/bin/mailq.postfix
> manpage_directory = /usr/share/man
> message_size_limit = 15728640
> mydestination =
> mynetworks = 127.0.0.1/32 [::1]/128
> myorigin = $mydomain
> newaliases_path = /usr/bin/newaliases.postfix
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_exceptions.cidr
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_action = enforce
> postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2,
> psbl.surriel.com*2
> postscreen_dnsbl_threshold = 2
> postscreen_greet_action = enforce
> queue_directory = /var/spool/postfix
> relay_domains = noa.gr, astro.noa.gr, admin.noa.gr, nestor.noa.gr,
> space.noa.gr, meteo.noa.gr, gein.noa.gr, technet.noa.gr, hesperia-space.eu
> relay_recipient_maps =
> sendmail_path = /usr/sbin/sendmail.postfix
> setgid_group = postdrop
> smtp_tls_security_level = may
> smtpd_helo_required = yes
> smtpd_recipient_restrictions = check_client_access
> hash:/etc/postfix/amavis_bypass check_sender_access
> hash:/etc/postfix/blacklisted_senders check_sender_access
> pcre:/etc/postfix/blacklisted_maillists reject_unverified_recipient
> reject_unauth_destination check_recipient_access
> hash:/etc/postfix/protected_destinations permit_mynetworks
> reject_invalid_hostname reject_unauth_pipelining reject_non_fqdn_sender
> reject_unknown_sender_domain reject_non_fqdn_recipient
> reject_unknown_recipient_domain reject_rbl_client b.barracudacentral.org
> reject_rbl_client zen.spamhaus.org reject_rbl_client psbl.surriel.com
> reject_rbl_client bl.spamcop.net reject_rbl_client dnsbl.sorbs.net
> reject_rhsbl_client dbl.spamhaus.org reject_rhsbl_sender
> dbl.spamhaus.org reject_rhsbl_helo dbl.spamhaus.org check_policy_service
> unix:postgrey/socket permit
> smtpd_restriction_classes = allowed_list1,allowed_list2
> smtpd_tls_CAfile = /etc/pki/tls/certs/DigiCertCA.crt
> smtpd_tls_cert_file = /etc/pki/tls/certs/star_noa_gr-1365536.crt
> smtpd_tls_exclude_ciphers = DES,3DES,MD5,aNULL,AES128,CAMELLIA128
> smtpd_tls_key_file = /etc/pki/tls/private/star_noa_gr-1365536.key
> smtpd_tls_loglevel = 1
> smtpd_tls_mandatory_ciphers = high
> smtpd_tls_security_level = may
> smtpd_tls_session_cache_timeout = 3600s
> transport_maps = hash:/etc/postfix/transportmap
> unknown_local_recipient_reject_code = 550
> unverified_sender_reject_code = 550
> virtual_alias_maps = hash:/etc/postfix/virtualmap
> 
> and cidr:/etc/postfix/postscreen_exceptions.cidr is:
> 
>195.134.100.72   dunno
>195.134.100.69   dunno
>195.134.100.81   dunno
>195.134.100.119  dunno
> 
> Please advise!
> 
> Thanks a lot,
> Nick
> 
> 

Re: Postscreen Feature Request

[Allen Coates]

On 03/09/17 00:43, Wietse Venema wrote:
> On 02/09/17 22:03, Wietse Venema wrote:
>> Surprise: I already solved that problem: postscreen would hand off
>> the _decrypted_ session to the tarpitting daemon :-)
> 
> Allen Coates:
>> How would you optionally hand off to the tarpit daemon, instead of to
>> postfix?
> 
> That requires new code for a config parameter that specifies the
> pathname of the tarpit service's UNIX-domain socket, and new code
> for making the Postfix library call to send the SMTP session's file
> descriptor to that socket.
> 
>   Wietse
> 
Thanks for that.  My spam defences are pretty well sorted - only eight
since march - and I am itching to take the fight to them.

Thanks for your time.

Allen

Re: Postscreen Feature Request

[Allen Coates]

On 02/09/17 22:03, Wietse Venema wrote:
> 
> Surprise: I already solved that problem: postscreen would hand off
> the _decrypted_ session to the tarpitting daemon :-)
> 

How would you optionally hand off to the tarpit daemon, instead of to
postfix?

Allen C

Postscreen Feature Request

[Allen Coates]

GIVEN THAT, when the Postscreen internal SMTP engine is invoked, the
decision to reject the message has already been made;
It seems to me that this is an opportunity to tar-pit the (bad) remote
host, diminishing spam throughput, and eroding the host's useful life-span.

I SUGGEST, therefore, that an additional "TAR-PIT" option be added to
the list of available postscreen_mumble_action's.   I envisage this as
being the same as "ENFORCE", but with an added delay.

It would be very nice if the tar-pit action could be invoked from within
the Postscreen access control lists, but I appreciate that this could
disrupt stable and well-tested code.

I would be interested to hear what others make of this idea.

Allen C

Re: Postscreen temporary whitelist

[Allen Coates]

Thanks for your comments

I am currently trying

postscreen_cache_retention_time = 1d
postscreen_non_smtp_command_ttl = 1d
postscreen_bare_newline_ttl = 1d
postscreen_pipelining_ttl  = 1d

FWIW I am also using the "deep protocol tests as a form of grey-listing

Allen C

On 23/08/17 13:24, Wietse Venema wrote:
> Allen Coates:
>> Is there any way of reducing the TTL of the postscreen temporary whitelist?
> 
> As of Postfix 3.1, these are the defaults:
> 
> postscreen_bare_newline_ttl = 30d
> postscreen_dnsbl_max_ttl = 
> ${postscreen_dnsbl_ttl?{$postscreen_dnsbl_ttl}:{1}}h
> postscreen_dnsbl_min_ttl = 60s
> postscreen_greet_ttl = 1d
> postscreen_non_smtp_command_ttl = 30d
> postscreen_pipelining_ttl = 30d
> 
> Earlier versions have postscreen_dnsbl_ttl instead of 
> postscreen_dnsbl_max_ttl,
> and they don't have postscreen_dnsbl_min_ttl.
> 
>> I am having problems with spammers repeatedly getting through postscreen
>> with a "PASS OLD" result.
>>
>> While I can't stop them trying, at least I can cost them time by making
>> them run the full postscreen gauntlet more frequently...
> 
> The postscreen_dnsbl(_max)_ttl setting should fix that.
> 
>   Wietse
> 

Postscreen temporary whitelist

[Allen Coates]

Is there any way of reducing the TTL of the postscreen temporary whitelist?

I am having problems with spammers repeatedly getting through postscreen
with a "PASS OLD" result.

While I can't stop them trying, at least I can cost them time by making
them run the full postscreen gauntlet more frequently...

Many thanks

Allen C

Re: Strategies for using backup MX records

[Allen Coates]

The thing I liked about my pop-3 solution was, if my server blew up and
I had to rebuild from scratch with new hardware, I could still read my
emails via my (almost redundant) ISP account

Allen C

On 17/08/17 16:10, Chris Green wrote:
> On Thu, Aug 17, 2017 at 02:24:45PM +0100, Allen Coates wrote:
>>
>>
>> On 17/08/17 13:38, Chris Green wrote:
>>> I run Postfix on a home server which is on all the time of course but,
>>> as it's connected via a 'domestic' broadband service it's not a 100%
>>> reliable connection. There are also times when I reconfigure things
>>> (e.g. upgrade the server) that cause downtimes.
>>>
>>
>> I am in an identical situation to you - my broadband modem locked up
>> this morning & I had to reboot everything :-(
>>
>> My original domain hosting service forwarded emails to a pop-3 account
>> (run by my ISP)
>> When postfix came along, the pop-3 account became my fall-back.
>>
>> My new domain host offers a back-up server, and that is how I am running
>> now.
>>
>> In reality, I receive very few genuine emails via the back-up server;
>> they are mostly spam which has been refused by my primary, or from hosts
>> which didn't bother trying the primary.
>>
>> About a month ago I implemented grey-listing within postscreen.  Since
>> then I have had half a dozen or so immediate retries via the secondary.
>>
>> I am brooding over the idea of obtaining an "el cheapo" second internet
>> connection - that opens up the possibility of running my own secondary
>> server on a raspberry pi, or something.
>>
>> I don't think any harm would come by NOT having a back-up of some sort -
>> but it runs severely against my nature.
>>
>> hope this helps
>>
> Thanks, it's good to hear other people puzzle over the same problems.
> 
> What I currently do (and I'll probably continue to do after reading
> the comments here) is to deliver all my mail to two destinations.
> This is easy as my hosting provider does this, I simply put two
> addresses in the mail forwarding for my main E-Mail address.
> 
> One of these is my home system, the other is a system where I have an
> account with ssh access.  On my home system the E-Mail is sorted and
> filtered as needed, on the ssh access system all the mail simply drops
> into a single mailbox and is deleted when more than a couple of weeks
> old.  Thus if my home system is off for any reason I can recover
> urgent E-Mails from the remote system.
> 
> Thanks for all the comments and ideas, as I said I'm pretty convinced
> that I will continue as at present.
> 

Re: Strategies for using backup MX records

[Allen Coates]

On 17/08/17 13:38, Chris Green wrote:
> I run Postfix on a home server which is on all the time of course but,
> as it's connected via a 'domestic' broadband service it's not a 100%
> reliable connection. There are also times when I reconfigure things
> (e.g. upgrade the server) that cause downtimes.
>

I am in an identical situation to you - my broadband modem locked up
this morning & I had to reboot everything :-(

My original domain hosting service forwarded emails to a pop-3 account
(run by my ISP)
When postfix came along, the pop-3 account became my fall-back.

My new domain host offers a back-up server, and that is how I am running
now.

In reality, I receive very few genuine emails via the back-up server;
they are mostly spam which has been refused by my primary, or from hosts
which didn't bother trying the primary.

About a month ago I implemented grey-listing within postscreen.  Since
then I have had half a dozen or so immediate retries via the secondary.

I am brooding over the idea of obtaining an "el cheapo" second internet
connection - that opens up the possibility of running my own secondary
server on a raspberry pi, or something.

I don't think any harm would come by NOT having a back-up of some sort -
but it runs severely against my nature.

hope this helps

Allen C

Re: Why there is no `reject_rbl_sender` restriction?

[Allen Coates]

On 03/08/17 11:55, Matus UHLAR - fantomas wrote:
> You apparently mean something like check_sender_mx_access (reject when MX
> server of sending domain points to blacklisted IP) or maybe
> check_sender_a_access (similar), but with dnsbl lookups.
>
> Doing it on MX would require dnsbl lookups for each MX server in all
> received mail.
> That would massively increase amount of dnsbl lookups.
>
> Doing it on A would do the same, just not that much.

Do it after a white-list of senders you know

Allen C

Re: Why there is no `reject_rbl_sender` restriction?

[Allen Coates]

For a while I tried a local black-list based on the senders of bounced
emails. It was deployed using "check_sender_access ".

Using the whole email address didn't work - I never sawthe same sender
twice;
and using just the domain part gave me more false positives than true.

A more targeted list, containing PROVEN dud domains and reserved TLDs -
example.com or invalid.net - might have more success.  I haven't given
up on the idea completely.  :-)
 
Not quite what you asked - but it might help to explain


Allen C


On 03/08/17 10:07, Martin Jiřička wrote:
> Hi,
>
> why there is no `reject_rbl_sender` restriction? It probably does not
> make so much sense as `reject_rbl_client`, but it would help me in my
> spam battle. Quite a lot of emails come from servers not listed inside
> Spamhause blacklists, but sender's domain points to blacklisted IP.
>
> For example yesterday came email from: Jaromil
>  from client: bounce.countrcultur.com
> [66.45.255.215]
>
> Client is not blacklisted under Spamhaus, but lets have a look in more
> detail to sender.
>
> # Domain is not listed:
>> host spplalru.com.dbl.spamhaus.org
> Host spplalru.com.dbl.spamhaus.org not found: 3(NXDOMAIN)
>
> # Check for IP:
>> host spplalru.com
> spplalru.com has address 185.140.110.3
>
> # But the domain point on blacklisted server!
>> host 3.110.140.185.zen.spamhaus.org
> 3.110.140.185.zen.spamhaus.org has address 127.0.0.2
>
>
> And this is not a unique case! In fact most of spam that pass my
> anti-spam setting would be filtered with such restriction according
> sender domain. Maybe it is more problem of Spamhaus and its list
> synchronization, I do not know.
>
> Or is there any fundamental reason why rejecting emails according
> sender's domain IP is not a good idea?
>
>
> My best wishes,
> Martin Jiřička
>

Re: postscreen fail2ban filter

[Allen Coates]

On 17/07/17 21:04, Scott Techlist wrote:
>> Postcreen logs DISCONNECT for clients that PASS the "after 220 greeting"
>> tests (bare newline, non-SMTP command, pipelining).
> Exactly what I was afraid of, thanks for the confirmation.
>
>> I don't think there is much to gain from parsing postscreen logging to
> produce
>> fail2ban rules. postscreen is designed to handle a lot of abuse with
> near-zero
>> resources.
> I understand and that's great.  But it would be nice to prevent at least
> some of connections and their ongoing log entries.  Without getting out of
> my comfort zone in solutions like Robert's and Allen's.

FWIW, I decided to implement iptables blocking after several bouts of 
hundreds of concurrent connect requests.  They created a weeks "worth"
of log entries in less than ten minutes  - which I didn't like !

These days I only see two or three such connect requests before they are
blocked.   From the IP table counters, some hosts keep trying to connect
for a month or more.

For some reason, I am also quite intolerant about AUTH probes, even
though there is nothing to find...

On balance, I would like to keep Fail2Ban, or something similar -  but
as a back-up, not a primary filter.

Allen C

Re: postscreen fail2ban filter

[Allen Coates]

On 17/07/17 16:43, Scott Techlist wrote:
> As I watch the bots and spammers hammer my server with connection attempts,
> I figured I might as well stop them even closer to the front door when they
> try repeatedly.
>
> I have fail2ban running already and once I enabled postscreen it didn't seem
> to have much to do anymore.
>
> My primary question is: Can I filter on the DISCONNECT log line for bad
> connections (and only bad connections), or do some "good" connections also
> log a DISCONNECT.  Like this:
>
> Jul 17 10:08:27 tn3 postfix/postscreen[19184]: DISCONNECT
> [110.175.112.118]:63862
>
> My server isn't "live" yet and my logs are just from bots and spammers
> already knocking at the door.  So I don't have a lot of "good" connections
> to look at.  I couldn't figure out if a "good" connection that went through
> after 220 tests, or any other pass, also got a DISCONNECT entry.  I fit
> does, I can't use it.  
>
> I've only found a couple of other's fail2ban filters related to postscreen
> logs:
>
> One from:
> https://github.com/jannickfahlbusch/fail2ban-rulez/blob/master/MailServer/Po
> stFix/postfix-dnsblog.conf
>
> That one picks up on the "listed by domain" string but because I may have
> multiple "hits" per connection due to multiple dnsbls, it throws off my
> banning thresholds.  Not a huge deal, but not the count I want.  This
> connection counted 4 "fails"
>
> Jul 17 10:01:40 tn3 postfix/postscreen[19136]: CONNECT from
> [105.174.2.98]:11607 to [45.63.111.83]:25
> Jul 17 10:01:40 tn3 postfix/dnsblog[19138]: addr 105.174.2.98 listed by
> domain b.barracudacentral.org as 127.0.0.2
> Jul 17 10:01:40 tn3 postfix/dnsblog[19142]: addr 105.174.2.98 listed by
> domain zen.spamhaus.org as 127.0.0.11
> Jul 17 10:01:40 tn3 postfix/dnsblog[19142]: addr 105.174.2.98 listed by
> domain zen.spamhaus.org as 127.0.0.4
> Jul 17 10:01:40 tn3 postfix/dnsblog[19143]: addr 105.174.2.98 listed by
> domain dnsbl.sorbs.net as 127.0.0.7
> Jul 17 10:01:46 tn3 postfix/postscreen[19136]: DNSBL rank 6 for
> [105.174.2.98]:11607
> Jul 17 10:01:48 tn3 postfix/postscreen[19136]: DISCONNECT
> [105.174.2.98]:11607
>
> >From searching this list I saw this filter:
> https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=U
> TF-8&u=https%3A%2F%2Fkupschke.net%2F2013%2F04%2F20%2Ffail2ban-und-postscreen
> %2F&edit-text=&act=url
>
> That one is picking up on 5xx reject codes like this one.  I don't' have
> many like this (yet):
>
> Jul 17 07:58:28 tn3 postfix/postscreen[8899]: CONNECT from
> [66.231.40.205]:64187 to [45.63.111.83]:25
> Jul 17 07:58:28 tn3 postfix/dnsblog[8904]: addr 66.231.40.205 listed by
> domain zen.spamhaus.org as 127.0.0.4
> Jul 17 07:58:34 tn3 postfix/postscreen[8899]: DNSBL rank 3 for
> [66.231.40.205]:64187
> Jul 17 07:58:35 tn3 postfix/postscreen[8899]: NOQUEUE: reject: RCPT from
> [66.231.40.205]:64187: 550 5.7.1 Service unavailable; client [66.231.40.205]
> blocked using zen.spamhaus.org;
> from=<36jr3j36jr36jr3.3625327...@superuser.com>,
> to=, proto=ESMTP, helo=<[192.168.1.5]>
> Jul 17 07:58:35 tn3 postfix/postscreen[8899]: DISCONNECT
> [66.231.40.205]:64187
>
> Anyone have any good postscreen fail2ban filters?
>
> Mine for now is:
> failregex =   ^%(__prefix_line)saddr  listed by domain .* as .*$
>   reject: RCPT from (.*)\[\]:([0-9]{4,5}:)? 550

My homespun iptables blocker works in two stages:

The log is swept over the last day or so, and -
a) Multiple transgressions puts the offender into a local blacklist.
b) Multiple blacklist refusals and they are added to an iptables DROP list.

and they stay there until they stop trying to connect ...

It is overkill for my (domestic) server,  but it keeps my hand in for
writing scripts.

(And I hate spam!!)

FYI  Below is today's attrition report:


Nuisance hosts currently blocked by firewall:91
Still active:24

POSTSCREEN  ATTRITION  REPORT  FOR  Today so far

Connections handled by Postscreen:189
White-listed:11
Black-listed Locally:23
Black-listed by DNSBL:75
Early hang-ups:9
Pre-Greets:3
Command pipelining:0
Non-SMTP commands:0
Multi-connect refusals:2

Grey-list Deferrals:1

Refusal Ratio:93 percent

Connections passed on to mail server:12
Early disconnects:0
Authorisation Probes:0
Client Host Refused:0
Bad HELO Command:0
Bad Sender address:0
Illegal Relay Attempts:0

Invalid Recipients:0

messages placed into Postfix queue:12
Sent to Dovecot:12
Outbound messages:0

Actual messages received in mailbox:12


Regards

Allen C











>
>

Re: Block forged addresses

[Allen Coates]

On 14/07/17 10:28, Abi Askushi wrote:
> Hi all,
>
> I was wondering what choices are there to block forged sender email
> addresses.
>
> I was thinking SPF could assist.
> The other option I saw is reject_sender_login_mismatch in postfix. *
> *
> Do you have any other suggestion?
>
> Many thanx
> Abi*
> *

Some while ago I created a file to kill inbound spam from non-existent
users such as "accounts" or "help-desk":-

hash:/etc/postfix/valid_users:
ali...@example.comDUNNO
ali...@example.comDUNNO
example.comREJECT Invalid address

and in main.cf:
check_sender_access hash:/etc/postfix/valid_users

The file gets auto-recompiled whenever the alias files change.

Also, when used with check_recipient_access  hash:/etc/postfix/valid_users,
it kills off any log-in identities which I don't want to use as an email
addresses.

hope this helps


Allen C

Re: Limit the damage of a hacked sender acount

[Allen Coates]

On 24/06/17 00:37, Daniel Miller wrote:
> I had a couple of accounts with too simple passwords hacked. And
> obviously my mail server is entirely too efficient - I think about 50k
> spams got blasted out before I caught it (because we got in the DNSBL's).
>
> Separate from improving the password security - what can I do to limit
> the damage a compromised account can cause? Without receiving user
> complaints about not being able to send the latest cute kitty pictures
> to their whole addressbook?
>
> Are there per-sender limits that can/should be applied? And is there a
> way I can be notified of a suspicious condition - without manually
> monitoring the queue?
>
> -- 
> Daniel
>

You might like to consider an ACL, or something like
http://www.postfix.org/postconf.5.html#smtpd_reject_unlisted_sender
to limit (forged) outbound emails from domains you don't control.

Allen C

Re: Forged FROM Adresses deny based on actual user?

[Allen Coates]

On 07/05/17 17:12, BlackIce_ wrote:
> Lately I have been getting SPAM mails that mimic our typical adress
> (i.e. user@domain) Ideally, the postfix server should only accept mail
> from ACTUAL users (or aliases to users) on the server.
>
> Is there a config change that can accomplish this easily? Seems like
> it should be the default.
>
> If the user does not exist, do not accept mail from them regardless of
> domain.
>
> Thanks,
>
> Rick
>

I am not sure that it would scale very well, but I use a file called
"valid_users":

valid_users:
postmas...@example.comDUNNO
... etc
validuse...@example.comDUNNO
validuse...@example.comDUNNO
... etc
example.comREJECT Invalid address


and in main.cf:
check_sender_access hash:/etc/postfix/valid_users,
check_recipient_access hash:/etc/postfix/valid_users,


It is VERY effective on my "toy" server;  if you could automate the
creation of the valid_user file, it might just work for you.

Regards

Allen C

Re: Optimising new system and postscreen questions

[Allen Coates]

On 01/05/17 13:17, Simon Wilson wrote:
>
> 3. Any other ways to speed it up, or should I accept the trade-off
> between speed and accuracy of result?
>

If you can create a postscreen white-list of your "regular" remote
hosts,  they will be almost instantly passed on to the mail server.

Hope this helps

Regards

Allen C

Re: Alert Trend Micro reputation LIST QIL

[Allen Coates]

If you check your IP address on THEIR look-up page -
https://www.ers.trendmicro.com/reputations - it will tell you WHY you
are black-listed. 

For example, my own IP4 address is in their "Dynamic User List" - not
surprising, as I am a domestic user with a personal mail server.

Hope this helps


Allen C


On 28/04/17 10:37, Matteo Cazzador wrote:
> Hi Everybody, maybe this is not the correct list, but i 've a problem
> related to Trend Micro QIL list.
>
> My mail server everyday is blocked by this QIL list.
>
> I made a global check with tool like http://mxtoolbox.com/ and i don't
> find  any serious problem.
>
> The server is not making spam.
>
> I dont'know what to do.
>
> Someone have the same problem?
>
> Thanks a lot.
>

Re: Recent upsurge of spam messages rate

[Allen Coates]

I have a script that does a simple "head-count" over the last 1500
maillog entries.

Just now it showed the following results:



Nuisance hosts blocked by firewall:97

Connections handled by Postscreen:134
Black-listed Locally:10
Black-listed by DNSBL:94
Pre-Greets:1
Hang-ups:78
No-Queues:7

Connections passed on to mail server:21
Auth Probes:2
No-Queues:1

Messages actually received:18

Ratio of bad connections is86 percent



Allen C


On 28/03/17 22:00, Daniele Nicolodi wrote:
> Hello,
>
> this is not strictly Postfix related, but I don't know how to get in
> contact with a similar crowd of experienced folks. Please direct me to a
> more suitable mailing list, it one exist.
>
> In the last two weeks I've seen an upsurge of the rate to which spam
> messages are delivered to my domain inboxes. Nothing is changed in my
> quite standard configuration, thus I guess that spammers found a way to
> circumvent the basic protections I have in place. Did anyone notice
> something similar? What are the possible countermeasures?
>
> I use Postfix with this simple configuration:
>
> header_checks = pcre:/etc/postfix/header_checks.pcre
> smtpd_helo_required = yes
> smtpd_delay_reject = yes
> disable_vrfy_command = yes
> smtpd_recipient_restrictions =
> permit_sasl_authenticated
> reject_invalid_hostname
> reject_non_fqdn_hostname
> reject_non_fqdn_sender
> reject_non_fqdn_recipient
> reject_unknown_sender_domain
> reject_unknown_recipient_domain
> permit_mynetworks
> reject_unauth_destination
> permit_dnswl_client list.dnswl.org
> reject_rbl_client zen.spamhaus.org
> reject_rbl_client b.barracudacentral.org
> reject_rbl_client dul.dnsbl.sorbs.net
> reject_rhsbl_reverse_client dbl.spamhaus.org
> reject_rhsbl_sender dbl.spamhaus.org
> reject_rhsbl_helo dbl.spamhaus.org
> permit
>
> with header_checks.pcre containing:
>
> /^X-Delivered-To: .*@grinta\.net$/  REJECT Mail forwarding loop detected
> /^(Delivered-To: .*@grinta\.net)$/  REPLACE X-$1
> /^X-Spam-Status: Yes/  REJECT Looks like spam
>
> and SpamAssassin as a SMTP proxy filter via spampd.
>
> Thanks for any comment.
>
> Best,
> Daniele
>

Re: Recent upsurge of spam messages rate

[Allen Coates]

I have also noticed an increase of "bad connections" to my server.

Fortunately, very few get past postscreen - I heartily recommend its use.

Allen C

On 28/03/17 22:00, Daniele Nicolodi wrote:
> Hello,
>
> this is not strictly Postfix related, but I don't know how to get in
> contact with a similar crowd of experienced folks. Please direct me to a
> more suitable mailing list, it one exist.
>
> In the last two weeks I've seen an upsurge of the rate to which spam
> messages are delivered to my domain inboxes. Nothing is changed in my
> quite standard configuration, thus I guess that spammers found a way to
> circumvent the basic protections I have in place. Did anyone notice
> something similar? What are the possible countermeasures?
>
> I use Postfix with this simple configuration:
>
> header_checks = pcre:/etc/postfix/header_checks.pcre
> smtpd_helo_required = yes
> smtpd_delay_reject = yes
> disable_vrfy_command = yes
> smtpd_recipient_restrictions =
> permit_sasl_authenticated
> reject_invalid_hostname
> reject_non_fqdn_hostname
> reject_non_fqdn_sender
> reject_non_fqdn_recipient
> reject_unknown_sender_domain
> reject_unknown_recipient_domain
> permit_mynetworks
> reject_unauth_destination
> permit_dnswl_client list.dnswl.org
> reject_rbl_client zen.spamhaus.org
> reject_rbl_client b.barracudacentral.org
> reject_rbl_client dul.dnsbl.sorbs.net
> reject_rhsbl_reverse_client dbl.spamhaus.org
> reject_rhsbl_sender dbl.spamhaus.org
> reject_rhsbl_helo dbl.spamhaus.org
> permit
>
> with header_checks.pcre containing:
>
> /^X-Delivered-To: .*@grinta\.net$/  REJECT Mail forwarding loop detected
> /^(Delivered-To: .*@grinta\.net)$/  REPLACE X-$1
> /^X-Spam-Status: Yes/  REJECT Looks like spam
>
> and SpamAssassin as a SMTP proxy filter via spampd.
>
> Thanks for any comment.
>
> Best,
> Daniele
>

Re: Fallback to IPV4 in case of IPV6 is not available

[Allen Coates]

On 25/03/17 14:43, Wietse Venema wrote:
> Postfix can be configured to try IPv6 before IPv4 (with
> smtp_address_preference), but that feature is independent from
> routing features such as transport_maps, smtp_fallback_relay, and
> so on. That is, there are no ipv6_transport_maps or
> ipv4_smtp_fallback_relay features.
>

A slightly different approach:

You don't try to favour IPv6 over v4.  However -
If transport selects an IPv6 address, the message goes directly.
If transport selects IPv4, it goes via the smart-host relay.

Would this work?

It would be useful to me, as my (domestic) IPv4 address is listed in the
Spamhaus Policy blocklist,  whereas my 6-over-4 tunnel is "clean".

Allen C

Re: Autoresponder?

[Allen Coates]

> On 2017-01-16 13:49, @lbutlr wrote:
>> I have an email account that belonged to someone who died recently.
>> Rather than simply shutdown the account and bounce all future emails,
>> the family would like some sort of automated messages for at least a
>> few months saying something like “ died in November, 2016.
>> Please redirect emails to ”.
>  

How about a simple alias, that forwards the messages to a final
destination?  No bounces, and the bereavement notice can be tailored to
the individual sender.

Or is that too simple?

Allen C

Re: Stopping compromised accounts

[Allen Coates]

On 06/12/16 01:52, Alex wrote:
> Hi,
>
> I have a postfix-3.0.5 system with a few hundred users. They have
> access to submission, webmail, and dovecot to send and receive mail.
>
> On occasion, user's local desktop are compromised, and with it their
> account on this system. This leads to their local desktop using the
> submission service to send hundreds or thousands of spam emails
> through this compromised account.
>
> They're only stopped after the user receives a ton of bounce messages,
> or we happen to see it somehow while watching logs.
>
> What mechanisms are available to say, control the number of messages
> sent per day or otherwise be made aware of a pattern of messages being
> sent by an account that could be indicative of account compromise?
>
> Thanks,
> Alex
>
If you read the thread   "block emails which pretend to originate from
my domain", there is a suggestion that stops outbound emails where MAIL
FROM is not your own domain.

This might also help

Allen C

Re: Strange log entry

[Allen Coates]

On 30/11/16 11:45, Wietse Venema wrote:
> Allen Coates:
>> Hello all
>>
>> From time to time I see a strange log entry:
>>
>> 2016-11-30T10:40:43+00:00 geronimo postfix/postscreen[20844]: warning:
>> getpeername: Transport endpoint is not connected -- dropping this connection
> The connection was closed before postscreen could determine the IP
> address information. Could be a portscan, some other probing system,
> or some other abnormal client.
>

I had a hunch that it might be some sort of probe.

>> Is there anything I could/should do about it?
> On the Internet, shit happens. If you're curious you could run a
> network sniffer and find out the source IP address of those
> connections.
>
>   Wietse
>
In my working days, there was an engineering proverb:  "If you don't
want them to play with knobs and switches, don't give them any".
I am a staunch believer in not giving "them" the remotest opportunity to
break into -  or break - a system.

In this case, I think I will content myself with a review of my firewall
rules.

Many thanks

Allen C

Strange log entry

[Allen Coates]

Hello all

>From time to time I see a strange log entry:

2016-11-30T10:40:43+00:00 geronimo postfix/postscreen[20844]: warning:
getpeername: Transport endpoint is not connected -- dropping this connection

Can someone explain what this means, please.

Is there anything I could/should do about it?

many thanks

Allen C

Re: Postfix and IPV6

[Allen Coates]

An fe80:: IP address is not formally attached to any particular
interface. It "just happens" as part of the autoconfigure regime.

To use one in a listen or bind type statement, you would have to
expressly state which interface you wish to use.

For example, you need to use the argument "-I eth0" (or whatever) before
ping6 will work with an fe80:: address.

Hope this helps

Allen C


On 19/11/16 12:41, Wietse Venema wrote:
> postfix:
>> Nov 19 06:13:02 tico postfix/master[23428]: fatal: bind 
>> fe80::4216:7eff:fea7:c56b port 587: Invalid argument
> I have never seen this problem.
>
> As a fix, don't specify link-local interfaces in main.cf:inet_interfaces.
>
>   Wietse
>

Re: SV: block emails which pretend to originate from my domain

[Allen Coates]

I also receive a fair amount of spam where the HELO is either my domain
name or my public-facing IP address. I block this as an additional
precaution.

smtpd_helo_restrictions =  permit_mynetworks,
check_helo_access hash:/volume1/Config/postfix/helo_access,
. . .

/volume1/Config/postfix/helo_access:   

example.comREJECT
12.34.56.78REJECT
. . .

Allen C



On 17/11/16 16:25, Phil Stracchino wrote:
> On 11/17/16 09:16, Sebastian Nielsen wrote:
>> You have your permit_sasl_authenticated inside smtpd_sender_restrictions 
>> right?
>> Replace that with "check_sender_access hash:/path/to/file"
>
> ...Right, never mind, reading too early in the morning.
>
>
>> Inside the file /path/to/file, you add the following:
>> mydomain.com permit_sasl_authenticated, reject
>>
>> Essentially, you move your "permit_sasl_authenticated" to the /path/to/file 
>> file.
>>
>> Or do you already have a check_sender_access containing 
>> permit_sasl_authenticated?
>
> I'm actually achieving the same end a different way:
>
>
> smtpd_recipient_restrictions = ...
>...
>  check_sender_access btree:/etc/postfix/block-local-sender
>
> /etc/postfix/block-local-sender:
> caerllewys.netREJECT Local sender address is not allowed
>
>