Does This Look Right?

[Colony.three]

Looks like it's doing what it's supposed to, but just checking...

Dec  5 06:58:26 quantumn postfix/smtpd[51554]: lost connection after AUTH from 
unknown[110.83.135.178]
Dec  5 06:58:26 quantumn postfix/smtpd[51554]: disconnect from 
unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2
Dec  5 06:58:26 quantumn postfix/smtpd[51554]: warning: hostname 
178.135.83.110.broad.nd.fj.dynamic.163data.com.cn does not resolve to address 
110.83.135.178: Name or service not known
Dec  5 06:58:26 quantumn postfix/smtpd[51554]: connect from 
unknown[110.83.135.178]
Dec  5 06:58:27 quantumn postfix/smtpd[51554]: lost connection after AUTH from 
unknown[110.83.135.178]
Dec  5 06:58:27 quantumn postfix/smtpd[51554]: disconnect from 
unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2
Dec  5 06:58:27 quantumn postfix/smtpd[51554]: warning: hostname 
178.135.83.110.broad.nd.fj.dynamic.163data.com.cn does not resolve to address 
110.83.135.178: Name or service not known
Dec  5 06:58:27 quantumn postfix/smtpd[51554]: connect from 
unknown[110.83.135.178]
Dec  5 06:58:28 quantumn postfix/smtpd[51554]: lost connection after AUTH from 
unknown[110.83.135.178]
Dec  5 06:58:28 quantumn postfix/smtpd[51554]: disconnect from 
unknown[110.83.135.178] ehlo=1 auth=0/1 commands=1/2
Dec  5 06:58:28 quantumn postfix/smtpd[51554]: warning: hostname 
178.135.83.110.broad.nd.fj.dynamic.163data.com.cn does not resolve to address 
110.83.135.178: Name or service not known
Dec  5 06:58:28 quantumn postfix/smtpd[51554]: connect from 
unknown[110.83.135.178]
Dec  5 06:58:28 quantumn postfix/smtpd[51554]: lost connection after AUTH from 
unknown[110.83.135.178]

Re: FIlter

[Junk]

what i am asking is how to you manage actual IPs of the hosts providing 
services.
What if at some point one of them or more are out of service?
D you monitor it so in case some stop providing the services you remove them or 
replace them?

Does send mail provide similar functionality to postscreen?

If i understand it correctly this feature allows to stop email from being 
delivered before it gets through MTA.
So spam assassin does same filtering but it requires more processing?
thx

> On Dec 4, 2017, at 4:30 PM, Reindl Harald  wrote:
> 
> 
> 
> Am 04.12.2017 um 23:17 schrieb Junk:
>> So I wonder if
>> postscreen_dnsbl is enabled is it possible that mail get lost by mistake?
>> Somehow some false positive?
>> How do you maintain the list?
> 
> the whole point is that you don't need to babysit the list because you have 
> not that thrustworth lists with low scores but reject if enough other RBL's 
> at the same time agree
> 
> you have a combination of blacklists and whitelists, see the whitelists at 
> the end with negative score and when the summary is 
> "postscreen_dnsbl_threshold" or higher the message is rejected
> __
> 
> the first 3 with the poision pill score 8 or higher are with names
> 
> * dul.dnsbl.sorbs.net
> * noserver.dnsbl.sorbs.net
> * pbl.spamhaus.org
> 
> these are normally deadly safe "reject it" but even that ones are guided by 
> the whitelists and so it typically needs at least one additional RBL to get 
> above 8
> 
> the 127.0.0.x stuff are the responses from the DNSBL/DNSWL server so that 
> postscreen only needs to ask "dnsbl.sorbs.net" once and probably get more 
> than one ip back, each ip response has it's score and so wehn you get back 
> "127.0.0.10" *and* "127.0.0.14" it's listed on both (dul/noserver) and get 17 
> points plus the responses from other lists minus whitelist responses and the 
> final number makes the decision
> 
> well, and with a caching nameserver spamassassin can re-use the cached 
> responses
> 
> postscreen_dnsbl_threshold = 8
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> postscreen_dnsbl_sites =
> dnsbl.sorbs.net=127.0.0.10*9
> dnsbl.sorbs.net=127.0.0.14*9
> zen.spamhaus.org=127.0.0.[10;11]*8
> dnsbl.sorbs.net=127.0.0.5*7
> zen.spamhaus.org=127.0.0.[4..7]*7
> b.barracudacentral.org=127.0.0.2*7
> zen.spamhaus.org=127.0.0.3*7
> dnsbl.inps.de=127.0.0.2*7
> hostkarma.junkemailfilter.com=127.0.0.2*4
> dnsbl.sorbs.net=127.0.0.7*4
> bl.spamcop.net=127.0.0.2*4
> bl.spameatingmonkey.net=127.0.0.[2;3]*4
> dnsrbl.swinog.ch=127.0.0.3*4
> ix.dnsbl.manitu.net=127.0.0.2*4
> psbl.surriel.com=127.0.0.2*4
> bl.mailspike.net=127.0.0.[10;11;12]*4
> bl.mailspike.net=127.0.0.2*4
> zen.spamhaus.org=127.0.0.2*3
> score.senderscore.com=127.0.4.[0..20]*3
> bl.spamcannibal.org=127.0.0.2*3
> dnsbl.sorbs.net=127.0.0.6*3
> dnsbl.sorbs.net=127.0.0.8*2
> hostkarma.junkemailfilter.com=127.0.0.4*2
> dnsbl.sorbs.net=127.0.0.9*2
> dnsbl-1.uceprotect.net=127.0.0.2*2
> all.spamrats.com=127.0.0.38*2
> bl.nszones.com=127.0.0.[2;3]*1
> dnsbl-2.uceprotect.net=127.0.0.2*1
> dnsbl.sorbs.net=127.0.0.2*1
> dnsbl.sorbs.net=127.0.0.4*1
> score.senderscore.com=127.0.4.[0..69]*1
> dnsbl.sorbs.net=127.0.0.3*1
> hostkarma.junkemailfilter.com=127.0.1.2*1
> dnsbl.sorbs.net=127.0.0.15*1
> ips.backscatterer.org=127.0.0.2*1
> bl.nszones.com=127.0.0.5*-1
> score.senderscore.com=127.0.4.[90..100]*-1
> wl.mailspike.net=127.0.0.[18;19;20]*-2
> hostkarma.junkemailfilter.com=127.0.0.1*-2
> ips.whitelisted.org=127.0.0.2*-2
> list.dnswl.org=127.0.[0..255].0*-2
> dnswl.inps.de=127.0.[0;1].[2..10]*-2
> list.dnswl.org=127.0.[0..255].1*-3
> list.dnswl.org=127.0.[0..255].2*-4
> list.dnswl.org=127.0.[0..255].3*-5

Re: TO_NO_BRKTS_DYNIP

[RW]

On Mon, 4 Dec 2017 12:52:29 -0800 (PST)
John Hardin wrote:

> On Mon, 4 Dec 2017, Joseph Brennan wrote:
> 
> > New rule: TO_NO_BRKTS_DYNIP  
> 
> Old rule, perhaps newly promoted and published.
> 
> > Since TO_NO_BRKTS_DYNIP is 2.361 and its component RDNS_DYNAMIC is
> > 2.639, one gets an even 5.0 score just for sending from
> > ec2-54-225-189-51.compute-1.amazonaws.com without < > around the To
> > address.  
> 
> I'd be open to putting a limit on the score, say 1.5, so that the 
> combination isn't by itself a poison pill.
> 

Those high scores are from the score set without Bayes or net rules
where there's often not a lot to go on.

The score for TO_NO_BRKTS_DYNIP is autogenerated, the two scores
probably add up to exactly 5.000 for good reason.

Maybe some special handling for amazonaws.com would be better.

Re: FIlter

[Junk]

So I wonder if
postscreen_dnsbl is enabled is it possible that mail get lost by mistake?
Somehow some false positive?

How do you maintain the list?


> On 12/02/2017 09:09 PM, Junk wrote:
>> Is there any list that can be trusted and is publicly available or
>> unless you pay nothing is trusted?
>>
>>
>
> See my previous list of postscreen_dnsbl_sites entries.  These can be
> trusted in aggregate but not individually.  Traditionally in MTAs, a
> single block list hit will reject email but that is too risky.  You
> really should consider switching to Postfix and try out
> postscreen_dnsbl_sites to combine the results of block lists.  More
> trustworthy lists get a higher weight and less trustworthy lists get a
> lower weight above zero.  Whitelists get a negative weight to lower the
> total score.
>
> /etc/postfix/main.cf:
> postscreen_cache_retention_time  = 7d
> postscreen_bare_newline_ttl  = 7d
> postscreen_greet_ttl = 7d
> postscreen_non_smtp_command_ttl  = 7d
> postscreen_pipelining_ttl= 7d
> postscreen_dnsbl_ttl = 1m
> postscreen_dnsbl_threshold   = 8
> postscreen_dnsbl_action  = enforce
> postscreen_greet_action  = enforce
> postscreen_greet_wait= ${stress?1}${stress:11}s
> postscreen_bare_newline_action   = enforce
> postscreen_bare_newline_enable   = yes
> postscreen_non_smtp_command_enable   = yes
> postscreen_pipelining_enable = yes
> postscreen_dnsbl_whitelist_threshold = -1
> postscreen_blacklist_action  = drop
>
> postscreen_dnsbl_sites =
>... (from previous email)
>
>>> On Dec 2, 2017, at 7:44 PM, Bill Cole
>>>  wrote:
>>>
 On 2 Dec 2017, at 13:33 (-0500), David Jones wrote:

 Then you can start experimenting with RBLs at
 http://multirbl.valli.org/lookup/
>>>
>>> Be VERY careful with that list of DNSBLs. For years they listed and
>>> tested my local, private, never-public DNSBL (which has always had an
>>> external view that "lists the world") despite repeated requests to
>>> stop, resulting in a steady stream of clueless users pleading,
>>> rationalizing, and/or threatening me over their supposed listing. It is
>>> only after I started to give actively hostile answers to external
>>> queries that they took my DNSBL off their lookup page, but they still
>>> ping it every day or so. Apparently, similar sites copied them and some
>>> end users seem to have gotten the bright idea to query the zone,
>>> sometimes in substantial volume.
>>>
>>> The bottom line: before actually *using* any of the DNSBLs you find via
>>> any 3rd-party site, research the list's actual purpose and
>>> availability.
>>>
>>> --
>>> Bill Cole
>>> b...@scconsult.com or billc...@apache.org
>>> (AKA @grumpybozo and many *@billmail.scconsult.com addresses)
>>> Currently Seeking Steady Work: https://linkedin.com/in/billcole
>>
>
>
> --
> David Jones
>

Re: TO_NO_BRKTS_DYNIP

[John Hardin]

On Mon, 4 Dec 2017, Joseph Brennan wrote:


New rule: TO_NO_BRKTS_DYNIP


Old rule, perhaps newly promoted and published.


Since TO_NO_BRKTS_DYNIP is 2.361 and its component RDNS_DYNAMIC is 2.639,
one gets an even 5.0 score just for sending from
ec2-54-225-189-51.compute-1.amazonaws.com without < > around the To address.


I'd be open to putting a limit on the score, say 1.5, so that the 
combination isn't by itself a poison pill.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Microsoft is not a standards body.
---
 3 days until The 76th anniversary of Pearl Harbor

Re: TO_NO_BRKTS_DYNIP

[Alan Hodgson]

On Mon, 2017-12-04 at 15:20 -0500, Joseph Brennan wrote:
> New rule: TO_NO_BRKTS_DYNIP
> 
> Since TO_NO_BRKTS_DYNIP is 2.361 and its component RDNS_DYNAMIC is
> 2.639, one gets an even 5.0 score just for sending from ec2-54-225-
> 189-51.compute-1.amazonaws.com without < > around the To address.
> 
> Should the amazonaws.com hosts not be in RDNS_DYNAMIC? I'm not silly
> enough to say they are free of spam customers, but they are
> definitely servers.
> 
> Joseph Brennan / Columbia U
> 
> 

Mail servers don't generally have generic reverse DNS, if they don't
want to be mistaken for end-user IPs or spambots.

https://aws.amazon.com/blogs/aws/reverse-dns-for-ec2s-elastic-ip-
addresses/

TO_NO_BRKTS_DYNIP

[Joseph Brennan]

New rule: TO_NO_BRKTS_DYNIP

Since TO_NO_BRKTS_DYNIP is 2.361 and its component RDNS_DYNAMIC is 2.639,
one gets an even 5.0 score just for sending from
ec2-54-225-189-51.compute-1.amazonaws.com without < > around the To address.

Should the amazonaws.com hosts not be in RDNS_DYNAMIC? I'm not silly enough
to say they are free of spam customers, but they are definitely servers.

Joseph Brennan / Columbia U