Re: simple greylisting by geoip? milter or policy server?

[Benning, Markus]

On 2016-06-14 02:28, list...@tutanota.com wrote:

I am considering the installation of Greylisting with Postfix.

I want it only for one condition, to greylist mail originating from
certain countries.


Hi,

may be mtpolicyd is an option for you:

https://www.mtpolicyd.org

It is a modular policyd and ships with a plugin for geoip.
It works like this:

  
module = "GeoIPLookup"
database = "/usr/share/GeoIP/GeoIP.dat"
  
  
module = "GeoIPAction"
result_from = "geoip"
country_codes = "DE,AT,CH,FR,IT"
mode = passive
score = -1
  
  
module = "GeoIPAction"
result_from = "geoip"
country_codes = "RU,UA,CN,IN"
mode = passive
score = 5
  

Instead of a score you could also set actions:

  
module = "GeoIPAction"
result_from = "geoip"
country_codes = "AQ"
mode = "reject"
reject_message = "too cold"
  

Theres also a Greylisting plugin.
You can combine them for conditional greylisting:

  
module = "ScoreAction"
threshold = 5

  module = "Greylist"
  score = -5
  mode = "passive"
  # activating the autowl will require a SQL database
  use_autowl = 0

  


Markus

--
https://markusbenning.de/

Re: simple greylisting by geoip? milter or policy server?

[Allen Coates]

On 14/06/16 23:31, list...@tutanota.com wrote:
>
> 14. Jun 2016 15:01 by njo...@megan.vbhcs.org
> :
>
> Is there some way to integrate the GeoIP dbs with postscreen?
>
>
> No, at least not easily.
>
>  
>
> Ok.  That would be a nice function to have, in my own opinion.
>

FWIW -  my postscreen_dnsbl_sites contains the lines:-

zz.countries.nerd.dk,
zz.countries.nerd.dk=127.0.3.58*-1,

The first line ALWAYS returns  a country code (for analysis), and also
scores 1 "blacklist point" which is
recinded by the second line if the remote host is in my own country (the UK)

You can also interrogate the site by country, eg   "host
4.3.2.1.uk.countries.nerd.dk", which will only return a code if the ip
address belongs to the uk...

It might give you another "angle" on processing by country

Regards

Allen C




> Or for that case is the milter-greylist idea better?
> Yes, that will work fine for selective greylisting.
>
>
> I've been looking at this and am uncertain that it helps.
>
>
> Because the milter will have to be after postscreen right?  So The
> traffic from blocked countries will still get past the postscreen stage?
>
>
> I guess that is better than all the way through to delivery in any case.
>
>
>

Re: sender_dependent_default_transport_maps ignored by smtpd

[Russell Yanofsky]

To be more specific: the check_recipient_rcpt_maps() function is
called multiple places, but the call that fails in this case is in the
one at the bottom of smtpd_check_rcpt().

On Tue, Jun 14, 2016 at 6:28 PM, Russell Yanofsky  wrote:
> Hi,
>
> I think there is a bug in handling of sender_dependent_default_transport_maps
> within smtpd when default_transport is set to error:...
>
> I'm configuring postfix as follows using default_transport and
> sender_dependent_default_transport_maps to reject all external
> outgoing mail, unless the envelope sender comes from a particular
> domain (yanofsky.org):
>
>   default_transport = error:External delivery disabled
>   sender_dependent_default_transport_maps = inline:{
> @yanofsky.org=smtp:[smtp-relay.gmail.com]:587 }
>
> This works correctly for messages sent locally though the sendmail
> command. But it doesn't work for messages that come in through smtpd.
> The problem is that smtpd rejects all external outgoing messages after
> the RCPT command, even when the sender is from @yanofsky.org.
>
> Looking at the smtpd source code, the problem seems to be that instead
> of smtpd calling the resolve_clnt_query_from() function which takes
> the sender into account, it always calls the resolve_clnt_query()
> function, which ignores the message sender.
>
> The exact point of failure happens in the
> strcmp(STR(reply->transport), MAIL_SERVICE_ERROR) check inside the
> check_rcpt_maps() function when it is called by
> check_recipient_rcpt_maps(), which is called by smtpd_check_rcpt(),
>
> The problem looks like it could be straightforward to fix if the
> resolve_clnt_query() call inside smtpd were changed to
> resolve_clnt_query_from(), but I haven't tried making this change yet,
> and I don't know what other effects this might have.
>
> Other notes: I'm running postfix-3.1.1, and the exact smtpd failure message 
> is:
>
> Jun 14 17:40:51 jumpy postfix/smtpd[31276]: NOQUEUE: reject: RCPT from
> jumpy[2600:3c03::f03c:91ff:fe55:105d]: 550 5.1.1
> : Recipient address rejected: External
> delivery disabled; from=
> to= proto=ESMTP helo=

Re: simple greylisting by geoip? milter or policy server?

[lists42]

14. Jun 2016 15:01 by njo...@megan.vbhcs.org:

>> Is there some way to integrate the GeoIP dbs with postscreen?
>
> No, at least not easily.

 

Ok.  That would be a nice function to have, in my own opinion.





> Or for that case is the milter-greylist idea better?
> Yes, that will work fine for selective greylisting.
>




I've been looking at this and am uncertain that it helps.




Because the milter will have to be after postscreen right?  So The traffic 
from blocked countries will still get past the postscreen stage?




I guess that is better than all the way through to delivery in any case.

sender_dependent_default_transport_maps ignored by smtpd

[Russell Yanofsky]

Hi,

I think there is a bug in handling of sender_dependent_default_transport_maps
within smtpd when default_transport is set to error:...

I'm configuring postfix as follows using default_transport and
sender_dependent_default_transport_maps to reject all external
outgoing mail, unless the envelope sender comes from a particular
domain (yanofsky.org):

  default_transport = error:External delivery disabled
  sender_dependent_default_transport_maps = inline:{
@yanofsky.org=smtp:[smtp-relay.gmail.com]:587 }

This works correctly for messages sent locally though the sendmail
command. But it doesn't work for messages that come in through smtpd.
The problem is that smtpd rejects all external outgoing messages after
the RCPT command, even when the sender is from @yanofsky.org.

Looking at the smtpd source code, the problem seems to be that instead
of smtpd calling the resolve_clnt_query_from() function which takes
the sender into account, it always calls the resolve_clnt_query()
function, which ignores the message sender.

The exact point of failure happens in the
strcmp(STR(reply->transport), MAIL_SERVICE_ERROR) check inside the
check_rcpt_maps() function when it is called by
check_recipient_rcpt_maps(), which is called by smtpd_check_rcpt(),

The problem looks like it could be straightforward to fix if the
resolve_clnt_query() call inside smtpd were changed to
resolve_clnt_query_from(), but I haven't tried making this change yet,
and I don't know what other effects this might have.

Other notes: I'm running postfix-3.1.1, and the exact smtpd failure message is:

Jun 14 17:40:51 jumpy postfix/smtpd[31276]: NOQUEUE: reject: RCPT from
jumpy[2600:3c03::f03c:91ff:fe55:105d]: 550 5.1.1
: Recipient address rejected: External
delivery disabled; from=
to= proto=ESMTP helo=

Re: simple greylisting by geoip? milter or policy server?

[Michael J Wise]

> On 6/14/2016 4:06 PM, list...@tutanota.com wrote:
>>
>> Is there some way to integrate the GeoIP dbs with postscreen?
>
> No, at least not easily.

I would think it would be a Simple Matter of Programming, given a list of
the countries and languages you trusted, to generate a list of all the
ones you didn't. Would require a little binary math, but the list
shouldn't change that often.

Or, it could be a lookup of some sort.

>> Or for that case is the milter-greylist idea better?
>
> Yes, that will work fine for selective greylisting.

Aloha mai Nai`a.
-- 
" So this is how Liberty dies ...  http://kapu.net/~mjwise/
" To Thunderous Applause.

Re: simple greylisting by geoip? milter or policy server?

[Noel Jones]

On 6/14/2016 4:06 PM, list...@tutanota.com wrote:
> 
> Is there some way to integrate the GeoIP dbs with postscreen?

No, at least not easily.

> 
> Or for that case is the milter-greylist idea better?

Yes, that will work fine for selective greylisting.


  -- Noel Jones

Re: simple greylisting by geoip? milter or policy server?

[lists42]

13. Jun 2016 17:54 by wie...@porcupine.org:

> list...@tutanota.com> :
>> But then I also read that that 'Policy delegation is now the preferred 
>> method
>> for adding policies to Postfix.'
>
> Milter support was added later, because some things can't be done
> with policy servers.




Ok.  I was'not sure about the differences or benefits.




> As for greylisting, you could use postscreen's deep protocol tests
> instead - those tests require that clients disconnect and come back
> before they can send mail.
>




I do not want to delay all the inbound mail.





I didn't understand that I could delay only some countries with the deep 
protocol tests, using for example the GeoIP databases.



Is there some way to integrate the GeoIP dbs with postscreen?

Or for that case is the milter-greylist idea better?

Re: global postfix sender whitelist

[Noel Jones]

On 6/14/2016 12:12 PM, Вадим Бажов wrote:
> Didn't receive your answer due to our mailserver maintenance
> schedule ( fail ! ;) )
> Thank you for explanations.
> Have some questions though.
> You say:
> 
>> check_client_access checks either the IP address or the verified
>> client hostname.  This is very hard to spoof and is the preferred
>> way to whitelist.
>>
>> check_sender_access checks the envelope sender email address, or
>> domain part of the envelope sender address.  This is very easy to
>> spoof; avoid sender based whitelists unless you have no other way to
>> whitelist some particular message.
>>
> /verified client hostname/ - what makes hostname verified ? Is it
> getting checked by check_client_access based on ip-address resolving
> or something ?

Postfix confirms all hostnames with forward and reverse name
lookups.  A host that fails any step of the verification is labeled
"unknown".  This is difficult to spoof.
https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS

> 
> /This is very easy to spoof : /I always thought that sender address
> from the envelope headers is getting checked against it's domain
> part by resolving it and compairing with HELO or ip adress that is
> already known by that time.

The sender address is trivial to spoof.  There is no requirement for
the sender address to have any relation to the HELO/IP/hostname, and
in practice this is a very poor spam indicator -- only poorly
written spam filters even bother checking.

SPF is the method to combat sender spoofing, but is not available
for check_sender_access map lookups.  If you must whitelist by
sender, you are strongly encouraged to use a filter, policy service,
or milter that checks SPF and rejects spoofed mail.


  -- Noel Jones

Re: global postfix sender whitelist

[Noel Jones]

On 6/14/2016 9:22 AM, Вадим Бажов wrote:
> Still didn't get any feedback.
> Any thoughts about complete white list ?

This was answered.

http://comments.gmane.org/gmane.mail.postfix.user/255986

Re: global postfix sender whitelist

[Wietse Venema]

> Still didn't get any feedback.
> Any thoughts about complete white list ?

Noel Jones posted a follow-up to your question. But, if you did not
receive that, then you won't receive this reply, either.

Wietse

Re: mysql local_recipient_map

[Wietse Venema]

Paul R. Ganci:
> On 06/14/2016 04:28 AM, Wietse Venema wrote:
> > Paul R. Ganci:
> >> anyone know what I am missing in that it seems postfix did resolve the
> >> IP address when communicating with the mysql database?
> > The host lookup is done by the MSQL library.
> That doesn't seem correct to me because with hosts = 
> server-1.example.comin/etc/postfix/local_recipient_map.cf
> 
> postmap -q sally@example.commysql:/etc/postfix/local_recipient_map.cf
> 
> works correctly
> 
> but the postfix daemon query fails (both requests work with an IP 
> address). If the MYSQL library was handling the host name resolution 
> then why does the postmap -q query succeed? Shouldn't both queries fail?

Perhaps you are running postmap as ROOT; Postfix runs as on-root.

Perhaps you have chroot enabled in master.cf. This is the default on 
debian/ubuntu. See http://www.postfix.org/DEBUG_README.html#no_chroot
Change the master.cf entry should to this:
smtp  inet  n   -   n   -   -   smtpd
---^^^
Using chroot requires additional setup.

Wietse

Re: mysql local_recipient_map

[Paul R. Ganci]

On 06/14/2016 04:28 AM, Wietse Venema wrote:

Paul R. Ganci:

anyone know what I am missing in that it seems postfix did resolve the
IP address when communicating with the mysql database?

The host lookup is done by the MSQL library.
That doesn't seem correct to me because with hosts = 
server-1.example.comin/etc/postfix/local_recipient_map.cf


postmap -q sally@example.commysql:/etc/postfix/local_recipient_map.cf

works correctly

but the postfix daemon query fails (both requests work with an IP 
address). If the MYSQL library was handling the host name resolution 
then why does the postmap -q query succeed? Shouldn't both queries fail?


--
Paul (ga...@nurdog.com)
Cell: (303)257-5208

Re: postfix virtual domain walking

[Phil Stracchino]

On 06/14/16 09:59, Kris Deugau wrote:
> James B. Byrne wrote:
>> 3.  If there is nothing that involves Postfix then something like what
>> you propose must be the case.  Or someone has gone to some lengths to
>> scan for these addresses using our domain name as a search term.
> 
> Every now and then I have seen indications in the mail logs of various
> systems that some spammer is once again taking all of the username parts
> they've ever seen and mix-and-matching them with domain names.
> 
> I have also seen, even less often, the next best thing to literally
> trying all possible ASCII usernames, in order - or at least trying all
> dictionary words from a modest dictionary mixed with that username list,
> in ASCII order.


Dictionary attacks are cheap when you have a botnet and it's not *your*
CPU cycles or bandwidth that you're burning.


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: 603.293.8485

Re: postfix virtual domain walking

[Kris Deugau]

James B. Byrne wrote:
> 3.  If there is nothing that involves Postfix then something like what
> you propose must be the case.  Or someone has gone to some lengths to
> scan for these addresses using our domain name as a search term.

Every now and then I have seen indications in the mail logs of various
systems that some spammer is once again taking all of the username parts
they've ever seen and mix-and-matching them with domain names.

I have also seen, even less often, the next best thing to literally
trying all possible ASCII usernames, in order - or at least trying all
dictionary words from a modest dictionary mixed with that username list,
in ASCII order.

-kgd

Re: Mail deferred instead rejected

[Il Neofita]

On Sun, Jun 12, 2016 at 7:39 PM, Wietse Venema  wrote:

> Wietse:
> Fix the username lookup, so that Postfix can determine that
> the user does not exist.
>

I found the problem in nssswitch, after removing the ldap everything start
work also for the local

Re: mysql local_recipient_map

[Wietse Venema]

Paul R. Ganci:
> I changed the line hosts = server-1.example.com to use an IP address 
> instead hosts = 192.168.1.200 and everything started working. Does 
> anyone know what I am missing in that it seems postfix did resolve the 
> IP address when communicating with the mysql database?

The host lookup is done by the MSQL library.

Wietse