Re: Postfix anvil logs behind haproxy upstream

2017-05-02 Thread plataleas

the haproxy health checks produced the postfix/anvil logs.

After adding the haproxy IP to the "smtpd_client_event_limit_exeptions"
the postfix/anvil logs showed correctly the originating IP of the brute
force attacks.

smtpd_client_event_limit_exceptions = $mynetworks $haproxy




On 05/01/2017 05:43 PM, plataleas wrote:
>
> Hi all
>
> We have submission enabled behind an haproxy. The setup works like a
> charm:
>
> /smtp01#cat /etc/postfix/master.cf//
> //...//
> //submission inet n   -   -   -   -   smtpd//
> //  -o syslog_name=postfix/submission//
> //  -o content_filter=smtp:[127.0.0.1]:10024//
> //  -o smtpd_tls_security_level=may//
> //  -o smtpd_sasl_auth_enable=yes//
> //  -o smtpd_upstream_proxy_protocol=haproxy//
> //  -o
> smtpd_sender_restrictions=permit_sasl_authenticated,reject_unauth_destination//
> //..//
> //
> haproxy01#cat /etc/haproxy/haproxy.cfg
> /
>
> /frontend frontend_smtp.example.com-587//
> //  bind x.x.x.x:587   # listening ip removed//
> //  mode tcp//
> //  default_backend backend_smtp.example.com-587//
> //backend backend_smtp.example.com-587//
> //  mode tcp//
> //  balance source//
> //  server smtp01.example.com smtp01.example.com:587 check send-proxy//
> //  server smtp02.example.com smtp02.example.com:587 check send-proxy/
>
> /
> smtp01 # postconf | grep mail_version//
> //mail_version = 2.11.3//
> haproxy01 # haproxy -v//
> HA-Proxy version 1.5.8 2014/10/31/
>
> From the Postfix logs we see brute force attacks (173.220.99.186 is
> the client IP, not the haproxy IP) : 
>
>
> /smtp01# grep 'authentication failed'  /var/log/mail.log/
>
> /May  1 16:10:55 smtp01 postfix/submission/smtpd[21376]: warning:
> ool-addc63ba.static.optonline.net[173.220.99.186]: SASL LOGIN
> authentication failed: authentication failure//
> //May  1 16:10:55 smtp01 postfix/submission/smtpd[20989]: warning:
> ool-addc63ba.static.optonline.net[173.220.99.186]: SASL LOGIN
> authentication failed: authentication failure//
> //May  1 16:10:56 smtp01 postfix/submission/smtpd[21376]: warning:
> ool-addc63ba.static.optonline.net[173.220.99.186]: SASL LOGIN
> authentication failed: authentication failure//
> //May  1 16:10:57 smtp01 postfix/submission/smtpd[20989]: warning:
> ool-addc63ba.static.optonline.net[173.220.99.186]: SASL LOGIN
> authentication failed: authentication failure//
> //May  1 16:10:58 smtp01 postfix/submission/smtpd[21376]: warning:
> ool-addc63ba.static.optonline.net[173.220.99.186]: SASL LOGIN
> authentication failed: authentication failure//
> //May  1 16:10:59 smtp01 postfix/submission/smtpd[20989]: warning:
> ool-addc63ba.static.optonline.net[173.220.99.186]: SASL LOGIN
> authentication failed: authentication failure/
>
>
> We would like to implement rate limiting. However the anvil logs
> (anvil is used for rate limiting) are showing the haproxy IP instead
> of the client IP (in this example 173.220.99.186):
>
> /smtp01# grep anvil /var/log/mail.log
>
> //May  1 16:11:01 smtp01 postfix/anvil[23221]: statistics: max cache
> size 12 at May  1 16:01:05
> May  1 16:21:01 smtp01 postfix/anvil[23221]: statistics: max
> connection rate 62/60s for (submission:*a.b.c.d*) at May  1 16:11:20
> May  1 16:21:01 smtp01 postfix/anvil[23221]: statistics: max
> connection count 2 for (submission:*a.b.c.d*) at May  1 16:11:01
> May  1 16:21:01 smtp01 postfix/anvil[23221]: statistics: max cache
> size 13 at May  1 16:11:44/
>
> *a.b.c.d:*  is against our expectations the haproxy IP.
> -> we would expect that a.b.c.d is the SASL Login source client (in
> this example 173.220.99.186)
>
> Did we miss something? Thanks a lot!
>
> plataleas
>
>



Re: Postfix anvil logs behind haproxy upstream

2017-05-02 Thread Wietse Venema
plataleas:
> 
> the haproxy health checks produced the postfix/anvil logs.
> 
> After adding the haproxy IP to the "smtpd_client_event_limit_exeptions"
> the postfix/anvil logs showed correctly the originating IP of the brute
> force attacks.
> 
> smtpd_client_event_limit_exceptions = $mynetworks $haproxy

Thanks, that makes sense. There is no way for the proxy's IP address
to leak into Postfix after a 'normal' HaProxy handshake.

Wietse


Re: Trace spam activity on mail server

2017-05-02 Thread Michael Segel
Ok, 
This is a little bit off topic for the mail list. 

Assuming as you say, you don’t spam… 

You may be included in a RBL if you reside on a net block that has a spammer on 
it. 
So while your domain isn’t  spamming, if your next door virtual neighbor is… 
you’re SOL (Shit Out of Luck) until you ask your ISP to move you to another net 
block, or you find a different Provider. 

You can run a check on your MX Server… there are a couple of web sites that do 
this… and I think one or two will identify the RBLs that include you. 


Now, if you have a spammer on your server… 

1) Are you an open relay? (Check with one of the MX sites to validate your 
configuration) 

2) Do you host other domains?  Anyone of those domains could be listed which 
means your IP addresses are listed. 

3) You said you have a mailing list. 
   a) How do people subscribe to the list? 
   b) What’s the purpose of the list? 
   c) How do you let people unsubscribe? 
   d) Do you comply with the ‘CAN-SPAM’ law (which isn’t much or that good of a 
law) 


The reason you will find those who run the RBLs to be less than responsive is 
that Spam has been an ongoing problem for almost 30 years. (Wasn’t the 
Cantor-Siegel green card spam in ’88 or was it ’89?)
Spamhaus has been around for roughly 20 years. (I met Steve in Madison WI, 19 
years ago at a dinner meeting)  

I’m sure that every RBL list maintainer has heard every excuse in book 
including pink contracts from ISPs, which resulted in the IDP (Internet Death 
Penalty) being created. 


While I’ve since moved on and have forgotten what little I knew of Mail 
Servers, there are things that you should be able to do. 

In theory, you can track your outbound email and run a simple counter based on 
the sender’s info.  If you have a spammer on your network, you would be able to 
see how many emails they send, and how many bcc’s are on each email.  

Another thing you can do is to check the domain registration of your clients. 
If the domain registration information is bogus, its a good sign you have a 
spammer.  
If the domain registration is blocked, then you should look a little deeper 
since you’re hosting the domain. 
(If you’re in country A, and the person buying access is in country B, that’s 
another ‘red’ flag. ) 

That’s pretty much common sense. 

Most of the RBLs implement an auto aging policy. Meaning if they don’t get a 
report that you’re spamming, they will automatically remove your IP from the 
list unless of course someone else in your netblock is spamming. Then you need 
to move, maybe even to a new ISP. 


HTH

-Mike

> On May 1, 2017, at 3:44 PM, li...@lazygranch.com wrote:
> 
> I did a whois on your domain, checked the Trend Micro list, and it was not 
> found. 
> 
> Replies to this email will be no different than your previous email. 
> Basically all you can do is request the block be removed. These RBLs have 
> little sympathy for those they block. 
> 
> My best solution for non-reposnse RBLs is to get them removed from any email 
> server that I care about. When you contact an administrator and show that you 
> pass a hundred RBLs, they will either drop the offending RBL that has false 
> positives or whitelist your domain. 
> 
> Out of three problem RBLs, only one admitted they were the problem and 
> cleared me.
> 
> When I first set up my email server, I thought the more RBLs the better. 
> Eventually I learned less is more.
>   Original Message  
> From: Matteo Cazzador
> Sent: Monday, May 1, 2017 3:36 AM
> To: postfix users
> Subject: Trace spam activity on mail server
> 
> Hi, i need an help. A Trend micro QIL list re-include Continuously my 
> mail server (Linux Centos).
> 
> All other list not include my ip.
> 
> TrendMicro don't give me specific motivation.
> 
> I don't see in postfix log any meaningful spam activities.
> 
> There is a method to trace eventually spam activity don't logged?
> 
> Or a web application or local to monitor my mail server activities?
> 
> Examples: connections on 25/587 port that are not logged by postfix?
> 
> I trace all php mail function script but, i don't see any activities for 
> now.
> 
> I dont see any NDR o backscatter activities.
> 
> I do not know what to do
> 
> Thanks
> 
> -- 
> Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.
> 
> Le informazioni contenute in questa e-mail e nei files eventualmente allegati 
> sono destinate unicamente ai destinatari della stessa e
> sono da considerarsi strettamente riservate. E' proibito copiare, salvare, 
> utilizzare, inoltrare a terzi e diffondere il contenuto della presente
> senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge 
> n. 196/2003. Se avete ricevuto questo messaggio per errore siete
> pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di 
> cancellarne il contenuto senza procedere ad ulteriore o differente 
> trattamento.
> 
> 
> **
> Ing. Matteo Cazzador

Re: Trace spam activity on mail server

2017-05-02 Thread Kevin A. McGrail

On 5/2/2017 9:51 AM, Michael Segel wrote:

You can run a check on your MX Server… there are a couple of web sites that do 
this… and I think one or two will identify the RBLs that include you.
One trick I use a lot when I have an infected machine on a network or a 
customer with a problem is that I setup a smarthost running a milter 
that runs the email through a spam checker, logs the answer and then 
tempfails the emails.


Then I can analyze if there is an issue and do a silent discard by 
subject or internal IP if we find a compromised machine while letting 
everything else go through.


Regards,
KAM


Re: Trace spam activity on mail server

2017-05-02 Thread Michael Segel
Just to follow up… 
I ran the check on his domain:
https://mxtoolbox.com/domain/netlite.it/

Pretty clean, maybe a few things to fix, but he’s not on any black list. 

I don’t know when he set up his domain, it could be that Trend Micro blocked 
the IP block due to a previous tenant and never took them off. 

Truthfully, I don’t use much more than Spamhaus these days. in terms of RBLs.  

He’s not running an open relay and if there was a spammer on his network, 
Spamhaus would have caught it too. Or someone else. 

Its not Matteo’s server and I suspect its Trend Micro. 

HTH

-Mike

> On May 2, 2017, at 8:56 AM, Kevin A. McGrail  wrote:
> 
> On 5/2/2017 9:51 AM, Michael Segel wrote:
>> You can run a check on your MX Server… there are a couple of web sites that 
>> do this… and I think one or two will identify the RBLs that include you.
> One trick I use a lot when I have an infected machine on a network or a 
> customer with a problem is that I setup a smarthost running a milter that 
> runs the email through a spam checker, logs the answer and then tempfails the 
> emails.
> 
> Then I can analyze if there is an issue and do a silent discard by subject or 
> internal IP if we find a compromised machine while letting everything else go 
> through.
> 
> Regards,
> KAM



Re: Trace spam activity on mail server

2017-05-02 Thread Kevin A. McGrail

On 5/2/2017 10:02 AM, Michael Segel wrote:

Just to follow up…
I ran the check on his domain:
https://mxtoolbox.com/domain/netlite.it/

Pretty clean, maybe a few things to fix, but he’s not on any black list.

I don’t know when he set up his domain, it could be that Trend Micro blocked 
the IP block due to a previous tenant and never took them off.

Truthfully, I don’t use much more than Spamhaus these days. in terms of RBLs.

He’s not running an open relay and if there was a spammer on his network, 
Spamhaus would have caught it too. Or someone else.

Its not Matteo’s server and I suspect its Trend Micro.


Yes, I'm a big fan of MXToolBox.  Great tool!  I agree, you might be 
looking for a ghost in the machine that doesn't exist and it's a FP from 
TrendMicro.



Regards,
KAM

--
*Kevin A. McGrail*
CEO

Peregrine Computer Consultants Corporation
10311 Cascade Lane
Fairfax, VA 22032

http://www.pccc.com/

703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-798-0171 (wireless)
kmcgr...@pccc.com 



Re: Trace spam activity on mail server

2017-05-02 Thread Matteo Cazzador
Hi, everybody,  yes is the first thing i try, i use mxtoolbox always 
before every investigation (from 1 year).


For me the problem is related only at spam activity that my server don't 
trace or a somthing compromise, like an user account.


But on my server there are no trace of spam.

Or it is a false positive alert, that cause a lot of problem to my customer.

The domain implicated is not my mail domain but mail server is the same.

Thanks.

Il 02/05/2017 16:40, Kevin A. McGrail ha scritto:

On 5/2/2017 10:02 AM, Michael Segel wrote:

Just to follow up…
I ran the check on his domain:
https://mxtoolbox.com/domain/netlite.it/

Pretty clean, maybe a few things to fix, but he’s not on any black list.

I don’t know when he set up his domain, it could be that Trend Micro blocked 
the IP block due to a previous tenant and never took them off.

Truthfully, I don’t use much more than Spamhaus these days. in terms of RBLs.

He’s not running an open relay and if there was a spammer on his network, 
Spamhaus would have caught it too. Or someone else.

Its not Matteo’s server and I suspect its Trend Micro.


Yes, I'm a big fan of MXToolBox.  Great tool!  I agree, you might be 
looking for a ghost in the machine that doesn't exist and it's a FP 
from TrendMicro.



Regards,
KAM

--
*Kevin A. McGrail*
CEO

Peregrine Computer Consultants Corporation
10311 Cascade Lane
Fairfax, VA 22032

http://www.pccc.com/

703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-798-0171 (wireless)
kmcgr...@pccc.com 



--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.

Le informazioni contenute in questa e-mail e nei files eventualmente allegati 
sono destinate unicamente ai destinatari della stessa e
sono da considerarsi strettamente riservate. E' proibito copiare, salvare, 
utilizzare,  inoltrare a terzi e diffondere il contenuto della presente
senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 
196/2003. Se avete ricevuto questo messaggio per errore siete
pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di 
cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**



RE: Trace spam activity on mail server

2017-05-02 Thread L . P . H . van Belle
So far i can see, is your web site the target not you mail server.

I personaly use : http://multirbl.valli.org/lookup/netlite.it.html 
About the same as mx toolbox, but i did notice that the list of multirbl is 
much shorted when the domainname is used.
If i check with this hostname:  mail.netlite.it (212.29.157.98) 
http://multirbl.valli.org/lookup/212.29.157.98.html 

DNSBL Blacklist Test Summary
Ip based:  231 of 231 tests done. 
Domain base: 49 of 49 tests done. 
Result, not listed anywere. 

You are running with out of date wordpress plugins. Checked a few.
Thats asking for problems. Check you webserver logs for strange/out of the 
order things. 

If you dont use mod security, get it, learn it, install it and stop the 
wordpress abuse.

Greetz, 

Louis



> -Oorspronkelijk bericht-
> Van: dovecot_...@hotmail.com 
> [mailto:owner-postfix-us...@postfix.org] Namens Michael Segel
> Verzonden: dinsdag 2 mei 2017 16:02
> Aan: Kevin A. McGrail
> CC: li...@lazygranch.com; Matteo Cazzador; postfix users
> Onderwerp: Re: Trace spam activity on mail server
> 
> Just to follow up…
> I ran the check on his domain:
> https://mxtoolbox.com/domain/netlite.it/
> 
> Pretty clean, maybe a few things to fix, but he’s not on any 
> black list. 
> 
> I don’t know when he set up his domain, it could be that 
> Trend Micro blocked the IP block due to a previous tenant and 
> never took them off. 
> 
> Truthfully, I don’t use much more than Spamhaus these days. 
> in terms of RBLs.  
> 
> He’s not running an open relay and if there was a spammer on 
> his network, Spamhaus would have caught it too. Or someone else. 
> 
> Its not Matteo’s server and I suspect its Trend Micro. 
> 
> HTH
> 
> -Mike
> 
> > On May 2, 2017, at 8:56 AM, Kevin A. McGrail 
>  wrote:
> > 
> > On 5/2/2017 9:51 AM, Michael Segel wrote:
> >> You can run a check on your MX Server… there are a couple 
> of web sites that do this… and I think one or two will 
> identify the RBLs that include you.
> > One trick I use a lot when I have an infected machine on a 
> network or a customer with a problem is that I setup a 
> smarthost running a milter that runs the email through a spam 
> checker, logs the answer and then tempfails the emails.
> > 
> > Then I can analyze if there is an issue and do a silent 
> discard by subject or internal IP if we find a compromised 
> machine while letting everything else go through.
> > 
> > Regards,
> > KAM
> 
> 



Re: Trace spam activity on mail server

2017-05-02 Thread lists
Would a spammy email server only trigger one RBL?

While mxtoolbox looks complete, there are more RBLs than on their list. I never 
knew Trend Micro had a RBL. ‎

‎Spamrl.com is one I can't stay off of. They do honor their one week reprieve. 
Like I said, I managed to get them removed from servers that I communicate 
with. There are over a hundred RBLs. If one is a problem child, dump it.

Pulled right from their website.
"Unfortunately, we cannot disclose any details about WHY your IP has a bad 
reputation.‎"

This thread is about spamrl.com, and no, I'm not a participant in the thread. 
http://www.webhostingtalk.com/showthread.php?t=1598238‎

Supposedly spamrl.com uses honeypots, which makes me wonder if a prankster can 
spoof headers and spam the honeypots just to drum up customers for commercial 
white lists. 

  Original Message  
From: Michael Segel
Sent: Tuesday, May 2, 2017 7:02 AM
To: Kevin A. McGrail
Cc: li...@lazygranch.com; Matteo Cazzador; postfix users
Subject: Re: Trace spam activity on mail server

Just to follow up… 
I ran the check on his domain:
https://mxtoolbox.com/domain/netlite.it/

Pretty clean, maybe a few things to fix, but he’s not on any black list. 

I don’t know when he set up his domain, it could be that Trend Micro blocked 
the IP block due to a previous tenant and never took them off. 

Truthfully, I don’t use much more than Spamhaus these days. in terms of RBLs. 

He’s not running an open relay and if there was a spammer on his network, 
Spamhaus would have caught it too. Or someone else. 

Its not Matteo’s server and I suspect its Trend Micro. 

HTH

-Mike

> On May 2, 2017, at 8:56 AM, Kevin A. McGrail  wrote:
> 
> On 5/2/2017 9:51 AM, Michael Segel wrote:
>> You can run a check on your MX Server… there are a couple of web sites that 
>> do this… and I think one or two will identify the RBLs that include you.
> One trick I use a lot when I have an infected machine on a network or a 
> customer with a problem is that I setup a smarthost running a milter that 
> runs the email through a spam checker, logs the answer and then tempfails the 
> emails.
> 
> Then I can analyze if there is an issue and do a silent discard by subject or 
> internal IP if we find a compromised machine while letting everything else go 
> through.
> 
> Regards,
> KAM



Re: Trace spam activity on mail server

2017-05-02 Thread Kevin A. McGrail

On 5/2/2017 10:56 AM, li...@lazygranch.com wrote:

Would a spammy email server only trigger one RBL?


Sure.

Spam is often in the eye of the beholder, people use different feeds, 
different policies, purposes, etc.


I wouldn't discount it that it's an issue just because it's only on one 
RBL.  I'm a public mirror for quite a few and the overlap is not as high 
as one might think.


Regards,
KAM



RE: Trace spam activity on mail server

2017-05-02 Thread L . P . H . van Belle
Maybe its handy to tell us the real domainname and ip involving this problem? 
 
 


Re: Trace spam activity on mail server

2017-05-02 Thread Matteo Cazzador

This i s very interesting thanks i follow this suggest.

I was moving on wrog way.

Thanks


Il 02/05/2017 16:52, L.P.H. van Belle ha scritto:

So far i can see, is your web site the target not you mail server.

I personaly use : http://multirbl.valli.org/lookup/netlite.it.html
About the same as mx toolbox, but i did notice that the list of multirbl is 
much shorted when the domainname is used.
If i check with this hostname:  mail.netlite.it (212.29.157.98)
http://multirbl.valli.org/lookup/212.29.157.98.html

DNSBL Blacklist Test Summary
Ip based:  231 of 231 tests done.
Domain base: 49 of 49 tests done.
Result, not listed anywere.

You are running with out of date wordpress plugins. Checked a few.
Thats asking for problems. Check you webserver logs for strange/out of the 
order things.

If you dont use mod security, get it, learn it, install it and stop the 
wordpress abuse.

Greetz,

Louis




-Oorspronkelijk bericht-
Van: dovecot_...@hotmail.com
[mailto:owner-postfix-us...@postfix.org] Namens Michael Segel
Verzonden: dinsdag 2 mei 2017 16:02
Aan: Kevin A. McGrail
CC: li...@lazygranch.com; Matteo Cazzador; postfix users
Onderwerp: Re: Trace spam activity on mail server

Just to follow up…
I ran the check on his domain:
https://mxtoolbox.com/domain/netlite.it/

Pretty clean, maybe a few things to fix, but he’s not on any
black list.

I don’t know when he set up his domain, it could be that
Trend Micro blocked the IP block due to a previous tenant and
never took them off.

Truthfully, I don’t use much more than Spamhaus these days.
in terms of RBLs.

He’s not running an open relay and if there was a spammer on
his network, Spamhaus would have caught it too. Or someone else.

Its not Matteo’s server and I suspect its Trend Micro.

HTH

-Mike


On May 2, 2017, at 8:56 AM, Kevin A. McGrail

 wrote:

On 5/2/2017 9:51 AM, Michael Segel wrote:

You can run a check on your MX Server… there are a couple

of web sites that do this… and I think one or two will
identify the RBLs that include you.

One trick I use a lot when I have an infected machine on a

network or a customer with a problem is that I setup a
smarthost running a milter that runs the email through a spam
checker, logs the answer and then tempfails the emails.

Then I can analyze if there is an issue and do a silent

discard by subject or internal IP if we find a compromised
machine while letting everything else go through.

Regards,
KAM




--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.

Le informazioni contenute in questa e-mail e nei files eventualmente allegati 
sono destinate unicamente ai destinatari della stessa e
sono da considerarsi strettamente riservate. E' proibito copiare, salvare, 
utilizzare,  inoltrare a terzi e diffondere il contenuto della presente
senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 
196/2003. Se avete ricevuto questo messaggio per errore siete
pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di 
cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**



Re: Trace spam activity on mail server

2017-05-02 Thread Matteo Cazzador

I don't find any site compromise, i try to write

to Trend Micro for the third time..

Thanks everybody.


Il 02/05/2017 17:03, Matteo Cazzador ha scritto:

This i s very interesting thanks i follow this suggest.

I was moving on wrog way.

Thanks


Il 02/05/2017 16:52, L.P.H. van Belle ha scritto:

So far i can see, is your web site the target not you mail server.

I personaly use : http://multirbl.valli.org/lookup/netlite.it.html
About the same as mx toolbox, but i did notice that the list of 
multirbl is much shorted when the domainname is used.

If i check with this hostname:  mail.netlite.it (212.29.157.98)
http://multirbl.valli.org/lookup/212.29.157.98.html

DNSBL Blacklist Test Summary
Ip based:  231 of 231 tests done.
Domain base: 49 of 49 tests done.
Result, not listed anywere.

You are running with out of date wordpress plugins. Checked a few.
Thats asking for problems. Check you webserver logs for strange/out 
of the order things.


If you dont use mod security, get it, learn it, install it and stop 
the wordpress abuse.


Greetz,

Louis




-Oorspronkelijk bericht-
Van: dovecot_...@hotmail.com
[mailto:owner-postfix-us...@postfix.org] Namens Michael Segel
Verzonden: dinsdag 2 mei 2017 16:02
Aan: Kevin A. McGrail
CC: li...@lazygranch.com; Matteo Cazzador; postfix users
Onderwerp: Re: Trace spam activity on mail server

Just to follow up…
I ran the check on his domain:
https://mxtoolbox.com/domain/netlite.it/

Pretty clean, maybe a few things to fix, but he’s not on any
black list.

I don’t know when he set up his domain, it could be that
Trend Micro blocked the IP block due to a previous tenant and
never took them off.

Truthfully, I don’t use much more than Spamhaus these days.
in terms of RBLs.

He’s not running an open relay and if there was a spammer on
his network, Spamhaus would have caught it too. Or someone else.

Its not Matteo’s server and I suspect its Trend Micro.

HTH

-Mike


On May 2, 2017, at 8:56 AM, Kevin A. McGrail

 wrote:

On 5/2/2017 9:51 AM, Michael Segel wrote:

You can run a check on your MX Server… there are a couple

of web sites that do this… and I think one or two will
identify the RBLs that include you.

One trick I use a lot when I have an infected machine on a

network or a customer with a problem is that I setup a
smarthost running a milter that runs the email through a spam
checker, logs the answer and then tempfails the emails.

Then I can analyze if there is an issue and do a silent

discard by subject or internal IP if we find a compromised
machine while letting everything else go through.

Regards,
KAM






--
Rispetta l'ambiente: se non ti è necessario, non stampare questa mail.

Le informazioni contenute in questa e-mail e nei files eventualmente allegati 
sono destinate unicamente ai destinatari della stessa e
sono da considerarsi strettamente riservate. E' proibito copiare, salvare, 
utilizzare,  inoltrare a terzi e diffondere il contenuto della presente
senza il preventivo consenso, ai sensi dell'articolo 616 c.p. e della Legge n. 
196/2003. Se avete ricevuto questo messaggio per errore siete
pregati di comunicarlo immediatamente all'indirizzo mittente, nonché di 
cancellarne il contenuto senza procedere ad ulteriore o differente trattamento.


**
Ing. Matteo Cazzador
NetLite snc di Cazzador Gagliardi
Corso Vittorio Emanuele II, 188 37069
Villafranca di Verona VR
Tel 0454856656
Fax 0454856655
Email: mat...@netlite.it
Web: http://www.netlite.it
**



Re: Trace spam activity on mail server

2017-05-02 Thread Michael Segel
First, honey pots aren’t an issue and spoofing an IP address is fairly easy to 
pickup. 

As to spam is in the eye of the beholder, if you go back to my questions… 

You’ll see that I asked about the OP’s mail list. 

Free clue… if you purchased a list of potential customers… you’re a spammer. 
If you scraped email addresses. You’re a spammer. 


If you just moved the the IP block, request a new block.  Or a new ISP. 

But I’d also make sure you’re running a clean shop too. 

> On May 2, 2017, at 10:00 AM, Kevin A. McGrail  wrote:
> 
> On 5/2/2017 10:56 AM, li...@lazygranch.com wrote:
>> Would a spammy email server only trigger one RBL?
> 
> Sure.
> 
> Spam is often in the eye of the beholder, people use different feeds, 
> different policies, purposes, etc.
> 
> I wouldn't discount it that it's an issue just because it's only on one RBL.  
> I'm a public mirror for quite a few and the overlap is not as high as one 
> might think.
> 
> Regards,
> KAM
> 



Re: Trace spam activity on mail server

2017-05-02 Thread lists
My point was some prankster and/or whitelist service  could ‎spam the honeypot 
with your credentials forged. That is a great way for a white list service to 
get customers. 

Without knowing the setup of the honeypot, it could be spoofed. These RBLs 
shoot first and ask questions later. 

Anyway, destroying the spamrl.com customer base one customer at a time works 
for me. A google search will find plenty of false positive complaints. 

Requesting a new IP just leaves the problem for the next owner. I managed to 
free up a block of Digital Ocean IP space by convincing one RBL that they were 
wrong regarding the IP space. Granted Digital Ocean should have done that. 

I never used any customer list nor scraped email addresses. 

The reality is these RBLs aren't bug free, and they never provide evidence of 
spamming. They prefer you go on a wild goose chase. Mind you any time I report 
a hack, I provide log data. That is how it should be done.

Two easy things to harden your server:
1) no web mail
2) all accounts use TLS



  Original Message  
From: Michael Segel
Sent: Tuesday, May 2, 2017 9:02 AM
To: Kevin A. McGrail
Cc: li...@lazygranch.com; Matteo Cazzador; postfix users
Subject: Re: Trace spam activity on mail server

First, honey pots aren’t an issue and spoofing an IP address is fairly easy to 
pickup. 

As to spam is in the eye of the beholder, if you go back to my questions… 

You’ll see that I asked about the OP’s mail list. 

Free clue… if you purchased a list of potential customers… you’re a spammer. 
If you scraped email addresses. You’re a spammer. 


If you just moved the the IP block, request a new block. Or a new ISP. 

But I’d also make sure you’re running a clean shop too. 

> On May 2, 2017, at 10:00 AM, Kevin A. McGrail  wrote:
> 
> On 5/2/2017 10:56 AM, li...@lazygranch.com wrote:
>> Would a spammy email server only trigger one RBL?
> 
> Sure.
> 
> Spam is often in the eye of the beholder, people use different feeds, 
> different policies, purposes, etc.
> 
> I wouldn't discount it that it's an issue just because it's only on one RBL. 
> I'm a public mirror for quite a few and the overlap is not as high as one 
> might think.
> 
> Regards,
> KAM
> 



New approach with fqrdns.pcre file

2017-05-02 Thread Steve Jenkins
I know many of us have used the fqrdns.pcre in Postfix's
smtpd_client_restrictions for many years to help block "low hanging" spam.
Long ago, after the project was abandoned by Stan H, I adopted it and moved
it to GitHub:

https://github.com/stevejenkins/hardwarefreak.com-fqrdns.pcre

One of Stan's principles with this helpful file was to avoid false
positives. So I always struggled with requests to add more strict rules
because I didn't want to increase that risk. For the past 18 months or so,
the "development" branch of the project has been split into three separate
files, which progressively block more spam and misconfigured mailers. The
basic fqrdns.pcre file is still in the original location, and still aims
for zero false positives. The fqrdns-plus.pcre file adds a few rules, but
still has a very low chance of false positives. The fqrdns-max.pcre file
adds a few more, but will block misconfigured mailers which may be
attempting to deliver otherwise legit mail. How strict you choose to be is
up to you, and you can use one, two, or all three files in conjunction to
achieve your goals. You should (as stated in the README) list them in your
smtpd_client_restrictions from most to least aggressive.

After 18 months of testing, I've moved the three-tiered approach to the
"master" branch. Thank you to the many on this list who have helped test
this three-tier approach. For those who have been grabbing the fqrdns.pcre
file from the GitHub master repo, you probably won't see much (if any)
difference in your spam blocking. For those who want to add additional
tiers, the instructions are in the README.

Please feel free to open issues on GitHub for feedback or suggestions. I
figured it was worth mentioning here on the Postfix list because this is
where the file originated, and I know a lot of us have used it for a long
time. These files, combined with Postscreen, block a massive amount of
incoming junk and make life for my Postfix servers much easier. :)

Thanks,

SteveJ


Re: Trace spam activity on mail server

2017-05-02 Thread Michael Segel
I got what you were saying. 

What you’re talking about is known as a Joe Job. 
And its harder to do because its easier to spot fake headers these days. 
So while its possible, its highly improbable and if it were done, it wouldn’t 
be on a single RBL. 

As to RBL services… yes, over time, some get dropped because they become stale 
and aren’t being maintained.  Some have nut jobs running them. 

Trend Micro doesn’t fit in to those categories. 

I agree to using TLS as a way to harden the security, but depending on the web 
mail server … YMMV. 

There’s a reason why the RBLs don’t provide the ‘evidence’. Spammers are 
cockroaches, but they also learn from their mistakes. 
Right now I’m working on my new server and its set up as my secondary MX. 
Already I have spammers hitting this machine and it looks like they are 
bypassing my primary server altogether. 

You are correct, the owner of the Netblock is ultimately responsible. So you 
should be able to get a new net block and let Digital Ocean worry.  


> On May 2, 2017, at 3:07 PM, li...@lazygranch.com wrote:
> 
> My point was some prankster and/or whitelist service  could ‎spam the 
> honeypot with your credentials forged. That is a great way for a white list 
> service to get customers. 
> 
> Without knowing the setup of the honeypot, it could be spoofed. These RBLs 
> shoot first and ask questions later. 
> 
> Anyway, destroying the spamrl.com customer base one customer at a time works 
> for me. A google search will find plenty of false positive complaints. 
> 
> Requesting a new IP just leaves the problem for the next owner. I managed to 
> free up a block of Digital Ocean IP space by convincing one RBL that they 
> were wrong regarding the IP space. Granted Digital Ocean should have done 
> that. 
> 
> I never used any customer list nor scraped email addresses. 
> 
> The reality is these RBLs aren't bug free, and they never provide evidence of 
> spamming. They prefer you go on a wild goose chase. Mind you any time I 
> report a hack, I provide log data. That is how it should be done.
> 
> Two easy things to harden your server:
> 1) no web mail
> 2) all accounts use TLS
> 
> 
> 
>   Original Message  
> From: Michael Segel
> Sent: Tuesday, May 2, 2017 9:02 AM
> To: Kevin A. McGrail
> Cc: li...@lazygranch.com; Matteo Cazzador; postfix users
> Subject: Re: Trace spam activity on mail server
> 
> First, honey pots aren’t an issue and spoofing an IP address is fairly easy 
> to pickup. 
> 
> As to spam is in the eye of the beholder, if you go back to my questions… 
> 
> You’ll see that I asked about the OP’s mail list. 
> 
> Free clue… if you purchased a list of potential customers… you’re a spammer. 
> If you scraped email addresses. You’re a spammer. 
> 
> 
> If you just moved the the IP block, request a new block. Or a new ISP. 
> 
> But I’d also make sure you’re running a clean shop too. 
> 
>> On May 2, 2017, at 10:00 AM, Kevin A. McGrail  wrote:
>> 
>> On 5/2/2017 10:56 AM, li...@lazygranch.com wrote:
>>> Would a spammy email server only trigger one RBL?
>> 
>> Sure.
>> 
>> Spam is often in the eye of the beholder, people use different feeds, 
>> different policies, purposes, etc.
>> 
>> I wouldn't discount it that it's an issue just because it's only on one RBL. 
>> I'm a public mirror for quite a few and the overlap is not as high as one 
>> might think.
>> 
>> Regards,
>> KAM
>> 
> 



Sending mail to two streams...

2017-05-02 Thread Michael Segel
Hi, 

I am curious about being able to send email to both Dovecot for the end user’s 
mail box and then also on to a stream where one can do some analytics? 
Or chain the streams so that you can do analytics on both in-bound and 
out-bound  and then deliver it? 

I know that it can be done (theoretically) but I’m not a guru on Postfix so I’m 
at a loss as to where to begin doing research. 

Any pointers? 

Thx

-Mike



Re: Trace spam activity on mail server

2017-05-02 Thread lists
‎From the wiki:
"Joe job victims may lose website hosting or network connectivity due to 
complaints to their Internet service providers, and even face increased 
bandwidth costs (or server overload) due to increased website traffic. The 
victim may also find his or her email blacklisted by spam filters."
  Original Message  
From: Michael Segel
Sent: Tuesday, May 2, 2017 1:36 PM
To: li...@lazygranch.com
Cc: Kevin A. McGrail; Matteo Cazzador; postfix users
Subject: Re: Trace spam activity on mail server

I got what you were saying. 

What you’re talking about is known as a Joe Job. 
And its harder to do because its easier to spot fake headers these days. 
So while its possible, its highly improbable and if it were done, it wouldn’t 
be on a single RBL. 

As to RBL services… yes, over time, some get dropped because they become stale 
and aren’t being maintained. Some have nut jobs running them. 

Trend Micro doesn’t fit in to those categories. 

I agree to using TLS as a way to harden the security, but depending on the web 
mail server … YMMV. 

There’s a reason why the RBLs don’t provide the ‘evidence’. Spammers are 
cockroaches, but they also learn from their mistakes. 
Right now I’m working on my new server and its set up as my secondary MX. 
Already I have spammers hitting this machine and it looks like they are 
bypassing my primary server altogether. 

You are correct, the owner of the Netblock is ultimately responsible. So you 
should be able to get a new net block and let Digital Ocean worry. 


> On May 2, 2017, at 3:07 PM, li...@lazygranch.com wrote:
> 
> My point was some prankster and/or whitelist service could ‎spam the honeypot 
> with your credentials forged. That is a great way for a white list service to 
> get customers. 
> 
> Without knowing the setup of the honeypot, it could be spoofed. These RBLs 
> shoot first and ask questions later. 
> 
> Anyway, destroying the spamrl.com customer base one customer at a time works 
> for me. A google search will find plenty of false positive complaints. 
> 
> Requesting a new IP just leaves the problem for the next owner. I managed to 
> free up a block of Digital Ocean IP space by convincing one RBL that they 
> were wrong regarding the IP space. Granted Digital Ocean should have done 
> that. 
> 
> I never used any customer list nor scraped email addresses. 
> 
> The reality is these RBLs aren't bug free, and they never provide evidence of 
> spamming. They prefer you go on a wild goose chase. Mind you any time I 
> report a hack, I provide log data. That is how it should be done.
> 
> Two easy things to harden your server:
> 1) no web mail
> 2) all accounts use TLS
> 
> 
> 
> Original Message 
> From: Michael Segel
> Sent: Tuesday, May 2, 2017 9:02 AM
> To: Kevin A. McGrail
> Cc: li...@lazygranch.com; Matteo Cazzador; postfix users
> Subject: Re: Trace spam activity on mail server
> 
> First, honey pots aren’t an issue and spoofing an IP address is fairly easy 
> to pickup. 
> 
> As to spam is in the eye of the beholder, if you go back to my questions… 
> 
> You’ll see that I asked about the OP’s mail list. 
> 
> Free clue… if you purchased a list of potential customers… you’re a spammer. 
> If you scraped email addresses. You’re a spammer. 
> 
> 
> If you just moved the the IP block, request a new block. Or a new ISP. 
> 
> But I’d also make sure you’re running a clean shop too. 
> 
>> On May 2, 2017, at 10:00 AM, Kevin A. McGrail  wrote:
>> 
>> On 5/2/2017 10:56 AM, li...@lazygranch.com wrote:
>>> Would a spammy email server only trigger one RBL?
>> 
>> Sure.
>> 
>> Spam is often in the eye of the beholder, people use different feeds, 
>> different policies, purposes, etc.
>> 
>> I wouldn't discount it that it's an issue just because it's only on one RBL. 
>> I'm a public mirror for quite a few and the overlap is not as high as one 
>> might think.
>> 
>> Regards,
>> KAM
>> 
> 



virtual transport lmtp vs. dovecot lda?

2017-05-02 Thread David Mehler
Hello,

I'm running a Postfix 3.1 setup with Dovecot 2.29 and Mysql 5.7. I am
trying to track down an elusive problem. Previously I had my
virtual_transport set to dovecot with a dovecot service in master.cf.
I then enabled the lmtp service which uses a socket
/var/spool/postfix/private/dovecot-lmtp

I keep getting the error in the logs to many connections to the mysql
database and stuff is deferred.

Any ideas?

Thanks.
Dave.


Re: virtual transport lmtp vs. dovecot lda?

2017-05-02 Thread Viktor Dukhovni

> On May 2, 2017, at 6:17 PM, David Mehler  wrote:
> 
> I keep getting the error in the logs to many connections to the mysql
> database and stuff is deferred.
> 
> Any ideas?

Nothing specific, while you remain reticent about sharing the actual log
entries and your server configuration.  Generally, use "proxy:mysql:"
whenever you're otherwise tempted to use "mysql:".

-- 
Viktor.



Re: Sending mail to two streams...

2017-05-02 Thread Wietse Venema
Michael Segel:
> Hi, 
> 
> I am curious about being able to send email to both Dovecot for
> the end user?s mail box and then also on to a stream where one can
> do some analytics?  Or chain the streams so that you can do analytics
> on both in-bound and out-bound  and then deliver it?
>
> I know that it can be done (theoretically) but I?m not a guru on
> Postfix so I?m at a loss as to where to begin doing research.

You can add a recipient with any of the following:

sender_bcc_maps
recipient_bcc_maps
virtual_alias_maps
always_bcc

(perhaps using a pcre map for the maps-based mechanisms).

And using smtpd_proxy_filter with a null filter that acts as a 'Y'
splitter (Viktor has used that to implement an archival service).

Wietse


Re: virtual transport lmtp vs. dovecot lda?

2017-05-02 Thread David Mehler
Hi,

I'm not sure what to send. I've temporarily solved the problem by
increasing the mysql max_connections setting from 256 to 300 and
started working. Something is using up mysql processes when the lmtp
socket is used.

Dave.


On 5/2/17, Viktor Dukhovni  wrote:
>
>> On May 2, 2017, at 6:17 PM, David Mehler  wrote:
>>
>> I keep getting the error in the logs to many connections to the mysql
>> database and stuff is deferred.
>>
>> Any ideas?
>
> Nothing specific, while you remain reticent about sharing the actual log
> entries and your server configuration.  Generally, use "proxy:mysql:"
> whenever you're otherwise tempted to use "mysql:".
>
> --
>   Viktor.
>
>