Re: limited port 587

[li...@rhsoft.net]

Am 27.05.2014 07:59, schrieb Tom Kinghorn:
> Is it possible to limit port 587 access to users who are known to be 
> traveling outside your network (foreign
> countries)?
> 
> We have a user who cannot access port 25 and as such I am looking at the 
> submission port, however, do not want to
> open it up to the net.

and why?

*nobody* should use anything else than 587 with MUA and SMTP-Auth

Re: custom script and loops problem - looking for professional support

[mancyb...@gmail.com]

On Mon, 26 May 2014 17:33:52 -0500
Noel Jones  wrote:

> On 5/26/2014 6:19 AM, mancyb...@gmail.com wrote:
> > Hi I wrote this script: http://pastebin.com/BZGNDcdn
> > which is configured in postfix in transport_maps like this:
> > emailtocatcherr...@example.com myCustomScript:dummy
> > and is supposed to catch emails that return errors ("Undelivered Mail 
> > Returned to Sender") when emailtocatcherr...@example.com sends emails.
> > (btw I'm sending 100% legit traffic, nothing spammy here)
> > 
> > It works very well
> > but if I try to send an email to emailtocatcherr...@example.com
> > it loops 10 times and then gives up (554 5.4.0 Error: too many hops).
> 
> A transport must deliver mail outside of postfix, such as to a
> remote system, a mailbox, or another postfix instance.  The
> transport must not loop mail back into the same postfix instance.
> 
> Perhaps a simple content_filter will fit your needs better than a
> transport. Or maybe not.
> http://www.postfix.org/FILTER_README.html#simple_filter
> 
> 
>   -- Noel Jones
> 
> 
> > 
> > I'm seeking community or professional support to fix this issue.
> > 
> > 
> > Thanks for your attention,
> > regards and have a nice day,
> > Mike
> > 
> 

Hi Noel, thanks for your suggestion but unfortunately I've already been there.
If you configure the script as a FILTER, instead of a transport_map, you'll not 
be able to catch bounced emails
as suggested here: http://marc.info/?l=postfix-users&m=139933564703452&w=2


Thanks to the helpful community,
regards and have a nice day,
Mike

Re: custom script and loops problem - looking for professional support

[Wietse Venema]

Noel Jones:
> Perhaps a simple content_filter will fit your needs better than a
> transport. Or maybe not.
> http://www.postfix.org/FILTER_README.html#simple_filter
 
mancyb...@gmail.com:
> If you configure the script as a FILTER, instead of a transport_map, you'll 
> not be able to catch bounced emails
> as suggested here: http://marc.info/?l=postfix-users&m=139933564703452&w=2

The FILTER has already handled the email BEFORE it bounced.
Why do you need to see it twice?

Wietse

Re: custom script and loops problem - looking for professional support

[mancyb...@gmail.com]

On Tue, 27 May 2014 06:41:22 -0400 (EDT)
wie...@porcupine.org (Wietse Venema) wrote:

> Noel Jones:
> > Perhaps a simple content_filter will fit your needs better than a
> > transport. Or maybe not.
> > http://www.postfix.org/FILTER_README.html#simple_filter
>  
> mancyb...@gmail.com:
> > If you configure the script as a FILTER, instead of a transport_map, you'll 
> > not be able to catch bounced emails
> > as suggested here: http://marc.info/?l=postfix-users&m=139933564703452&w=2
> 
> The FILTER has already handled the email BEFORE it bounced.
> Why do you need to see it twice?
> 
>   Wietse


Hi Wietse, thanks for your attention.

When using the script as a FILTER, it isn't able to catch emails generated by 
postfix itself, as described here:
http://marc.info/?l=postfix-users&m=139932881701528&w=2

instead, while using it as a transport_map, it works very well
but works only with emails generated by postfix itself:
when trying to send an email to it, it loops 10 times and then gives up with 
the 'too many hops' error.

It is the last part of the script: http://pastebin.com/BZGNDcdn

this part:

$sendmail = '/usr/sbin/sendmail -G -i ' . implode(' ', $argv);
$handle = popen($sendmail, 'w');
fwrite($handle, $content);
$sendmail_return_value = pclose($handle);

the script passes the email to the receiver (itself in this given problem 
case), but it loops and then it gives up.


Thanks, regards and have a nice day,
Mike

Re: custom script and loops problem - looking for professional support

[Viktor Dukhovni]

On Tue, May 27, 2014 at 11:36:46AM +0200, mancyb...@gmail.com wrote:

> Hi Noel, thanks for your suggestion but unfortunately I've already been there.

And yet Noel is right.  Transport overrides that direct mail to a
script are NOT compatible with re-injection of the message back
into the same Postfix queue by the script.  This obviously leads
to a loop, how could it not?

Therefore, you must either use a FILTER (which works with re-injection
provided that re-injection does activate the filter again, see
FILTER_README), or else you MUST NOT re-inject the message back
into the same queue.

Since you've not explained what goals this particular script is
intended to address, further help is difficult.  So far, we're
tackling this at the wrong layer, discussing your solution, rather
than your problem.

-- 
Viktor.

Re: custom script and loops problem - looking for professional support

[mancyb...@gmail.com]

On Tue, 27 May 2014 13:02:20 +
Viktor Dukhovni  wrote:

> On Tue, May 27, 2014 at 11:36:46AM +0200, mancyb...@gmail.com wrote:
> 
> > Hi Noel, thanks for your suggestion but unfortunately I've already been 
> > there.
> 
> And yet Noel is right.  Transport overrides that direct mail to a
> script are NOT compatible with re-injection of the message back
> into the same Postfix queue by the script.  This obviously leads
> to a loop, how could it not?
> 
> Therefore, you must either use a FILTER (which works with re-injection
> provided that re-injection does activate the filter again, see
> FILTER_README), or else you MUST NOT re-inject the message back
> into the same queue.
> 
> Since you've not explained what goals this particular script is
> intended to address, further help is difficult.  So far, we're
> tackling this at the wrong layer, discussing your solution, rather
> than your problem.
> 
> -- 
>   Viktor.

Hi I've explained my goal here: 
http://marc.info/?l=postfix-users&m=139932881701528&w=2
then here: http://marc.info/?l=postfix-users&m=140015047902115&w=2
and here: http://marc.info/?l=postfix-users&m=140110327807685&w=2
also suppliying code.

Anyway I've 'fixed' the problem by using another email to catch those errors
and adding a 'reply-to' header.


Thanks and regards,
Mike

Re: custom script and loops problem - looking for professional support

[Wietse Venema]

Noel Jones:
> Perhaps a simple content_filter will fit your needs better than a
> transport. Or maybe not.
> http://www.postfix.org/FILTER_README.html#simple_filter

mancyb...@gmail.com:
> If you configure the script as a FILTER, instead of a transport_map, you'll 
> not be able to catch bounced emails
> as suggested here: http://marc.info/?l=postfix-users&m=139933564703452&w=2
> 
> The FILTER has already handled the email BEFORE it bounced.
> Why do you need to see it twice?

mancyb...@gmail.com:
> When using the script as a FILTER, it isn't able to catch emails generated by 
> postfix itself, as described here:

I repeat: THE FILTER HAS ALREADY SEEN THE MAIL BEFORE IT BOUNCED.

Why do you need to see the same message twice?

Wietse

postfix rewrite Return-Path when used as relay

[Stéphane MERLE]

Hi all,

I use postfix for a while as a "direct" mailer, but I have to setup a 
postfix box as relay ... and It look like postfix rewrite the 
Return-Path header. I use PHPMailer to send the mail to postfix (on an 
other port than 25) and postfix make the final delivery (it's working 
fine except for the Return-Path changed with the FROM header).


I checked the Debug of PHPMailer to see exactly the SMTP dialog and I 
got the correct Return-Path header ...


2014-05-27 13:13:55 CLIENT -> SERVER: Date: Tue, 27 May 2014 
15:13:55 +0200
2014-05-27 13:13:55 CLIENT -> SERVER: Return-Path: 



is there a parameter to set for postfix not to touch the Return-Path ? 
and why setting a return path would be offending ? (I use it a lot for 
my stats and bounce managing ...)


my postfix main.cf :

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
readme_directory = no
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_recipient_restrictions = permit_mynetworks 
permit_sasl_authenticated defer_unauth_destination

myhostname = nameserversmtp.ledomaine.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = ledomaine.com, localhost, localhost.localdomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128xxx.xxx.xxx.xxx/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all

Thanks for your help, and thanks for postfix, the best ever !

Stéphane

Re: custom script and loops problem - looking for professional support

[Viktor Dukhovni]

On Tue, May 27, 2014 at 03:23:02PM +0200, mancyb...@gmail.com wrote:

> Hi I've explained my goal here: 
> http://marc.info/?l=postfix-users&m=139932881701528&w=2

If you're trying to capture bounced messages for list maintenance,
you can certainly configure the bounce address (envelope sender of
original message) to be handled by script executed via a pipe
transport, or delivered to an account that runs procmail or a
.forward script, ...

What you MUST NOT do is attempt to re-inject the message back into
the Postfix queue as your script is doing.  Record the bounce in
some database and discard the message.

-- 
Viktor.

Re: postfix rewrite Return-Path when used as relay

[Wietse Venema]

St?phane MERLE:
> I use postfix for a while as a "direct" mailer, but I have to setup a 
> postfix box as relay ... and It look like postfix rewrite the 
> Return-Path header.

The Return-Path header is READ-ONLY.

Setting the Return-Path header HAS NO EFFECT.

The Return-Path header shows the ENVELOPE SENDER ADDRESS.  Your PHP
app must provide the correct ENVELOPE SENDER when posting mail.

http://us2.php.net/manual/en/function.mail.php

Begin quote
additional_parameters (optional)

... For example, this can be used to set the envelope sender address 
End quote.

Wietse

Re: limited port 587

[LuKreme]

On 26 May 2014, at 23:59 , Tom Kinghorn  wrote:
> Is it possible to limit port 587 access to users who are known to be 
> traveling outside your network (foreign countries)?

You setup port 587 with authenticated submission, which allows only your users 
to submit email. It would be very difficult to IP restrict to people outside of 
the country, but it is not difficult to restrict to people outside your IP 
range.

I cannot think of a single reason to do this.

> We have a user who cannot access port 25 and as such I am looking at the 
> submission port, however, do not want to open it up to the net.

Why?

What you should do is open 578 with auth and lock off port 25 to submissions.

-- 
Im finding's you'r mis'use of apostrophe's disturbing.

Re: postfix rewrite Return-Path when used as relay

[Stéphane MERLE]

Hi Wietse,

Le 27/05/2014 16:12, Wietse Venema a écrit :

St?phane MERLE:

I use postfix for a while as a "direct" mailer, but I have to setup a
postfix box as relay ... and It look like postfix rewrite the
Return-Path header.

The Return-Path header is READ-ONLY.

Setting the Return-Path header HAS NO EFFECT.

The Return-Path header shows the ENVELOPE SENDER ADDRESS.  Your PHP
app must provide the correct ENVELOPE SENDER when posting mail.

http://us2.php.net/manual/en/function.mail.php

Begin quote
additional_parameters (optional)

... For example, this can be used to set the envelope sender address 
End quote.


Thanks for your fast reply, I hope I am not wasting your time !

in fact, I use PHPMailer because it can handle the connexion directly in 
SMTP and not with the php mail() function.


if I understood you correctly, what i am doing right now (and since 
about 8 years ...) is wrong. I got this kind of headers (sender domain 
<> return path domain as use de same return path domain for common 
treatment ) :


Return-Path:*newsletter_id1_id2_...@maindomain.com*
Received: from id0019.domainesender.com (id0019.domainesender.com 
[XXX.XXX.XXX.XXX])
by mail.domainereceiver.com with ESMTP
; Tue, 27 May 2014 05:31:58 +0200
Received: by id0019.domainesender.com (Postfix, from userid 0)
id 04EF83945C56; Tue, 27 May 2014 05:31:19 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; s=dkim.maindomain.key; d=maindomain.com; 
c=simple; q=dns;
b=TgLj5KbVOh+On9dZQlbqvdDS0b6R1wmMEv0h3Oe8u2Yc6Hs36thKFVJeuQTHY0GJl
3G8rviVx4r3uG1p5B3Qd3xWCwOFkDKpsGAkNvA4fq+Dxg7OJRiYnwOnZPeAiQ/nt3kD
Ytl9Bl1Ph1SOjsKCDDn8vcQw27yjS5DbWzefSzE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=maindomain.com;
s=dkim.maindomain.key; t=1401161480;
bh=Ntyfl2eDwVj+SG+OhZJek3G0/3k7E6VbHxW9sTP7jsM=;
h=To:Subject:From:MIME-Version:Content-Type:Message-Id:Date;
b=SSpZTklmAxg+f/Bf82Z5zsM2XwHANzPpbhWpfUrDvM4eHlAxoIN6IPJN3dEu64FHK
 6Uol6Kyn29Wm+MAusqTNq1648KAROIV9qA5gC/xQowAXeMdddKb5CAfHZPqP0xuyL2
 qMoCNb3VjRu4MshwTgzf3B64aSrAfnERMn1D0bbg=
To: destemail@destdomaine
Subject: bonjour, ceci est le sujet
*From: "ne pas louper" *
X-abuse-contact: ab...@autredomaine.com


but ... it's working ... my emails are arriving correctly and I have a perl 
script which parse the postfix logs for stats ...


Stéphane


Wietse

Re: postfix rewrite Return-Path when used as relay

[Wietse Venema]

St?phane MERLE:
> in fact, I use PHPMailer because it can handle the connexion directly in 
> SMTP and not with the php mail() function.
> 
> if I understood you correctly, what i am doing right now (and since 
> about 8 years ...) is wrong. I got this kind of headers (sender domain 
> <> return path domain as use de same return path domain for common 
> treatment ) :

The return-path header is DELETED when Postfix receives mail.

The return-path header is CREATED when Postfix delivers mail.

The return-path header contains the envelope sender address.

If the return-path header does not contain what you want, then 
you must specify the correct envelope sender email address.

Wietse

initial 220 greeting delay from hosts with no RDNS

[Joe Shamblin]

Hello,

I am experiencing an issue where hosts that do not have reverse DNS see an 
extended delay (45-60 seconds for ssl or non-ssl connections) before they get 
the initial 220 greeting. Hosts that do have properly registered entries get in 
immediately. I have downloaded the source, and the programs that perform the 
lookups gethostbyaddr, etc... all seem to return quickly enough. DNS on the 
machine is also snappy and returns the lack of RDNS quickly. Setting 
smtpd_peername_lookup to no solves the issue, but has other ramifications. The 
server in question is running postfix 2.9.6-1 on ubuntu 12.04. A different 
server with the same configuration does not seem to have the issue. Setting the 
debug_peer for the hosts show the same thing for the hosts that experience a 
delay versus those that do not, basically a bunch of match_hostaddr and 
match_hostname calls. Once the initial delay is out of the way, everything 
proceeds as normal. 

Here is the postconf -n output, any suggestions?

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
message_size_limit = 52428800
milter_default_action = accept
milter_protocol = 2
mydestination = /etc/postfix/local-host-names duke.cs.duke.edu cs.duke.edu
myhostname = duke.cs.duke.edu
mynetworks = /etc/postfix/local-host-names 152.3.140.177 152.3.140.0/23 
152.3.144.0/23 152.3.136.0/23 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = cs.duke.edu
non_smtpd_milters = inet:localhost:8891
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (feed me)
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, 
reject_rbl_client r.mail-abuse.com, warn_if_reject reject_unauth_pipelining, 
permit
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks, reject_non_fqdn_hostname, 
reject_invalid_helo_hostname, permit
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = check_recipient_access 
hash:/etc/postfix/expired, permit_mynetworks, permit_sasl_authenticated, 
reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unauth_destination, 
reject_unknown_recipient_domain, permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
smtpd_sasl_local_domain =
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, 
check_recipient_access hash:/etc/postfix/access, reject_unknown_sender_domain, 
permit
smtpd_tls_CAfile = /etc/ssl/cacert.pem
smtpd_tls_cert_file = /etc/ssl/server.crt
smtpd_tls_key_file = /etc/ssl/server.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_random_source = dev:/dev/urandom

Thanks,

Joe
--
Joe Shamblinw...@cs.duke.edu
Senior IT Analyst   Department of Computer Science
(919) 660-6582  Duke University



smime.p7s
Description: S/MIME cryptographic signature

Re: initial 220 greeting delay from hosts with no RDNS

[Wietse Venema]

Joe Shamblin:
> I am experiencing an issue where hosts that do not have reverse
> DNS see an extended delay (45-60 seconds for ssl or non-ssl
> connections) before they get the initial 220 greeting. Hosts that
> do have properly registered entries get in immediately. I have
> downloaded the source, and the programs that perform the lookups
> gethostbyaddr, etc... all seem to return quickly enough. DNS on
> the machine is also snappy and returns the lack of RDNS quickly.
> Setting smtpd_peername_lookup to no solves the issue, but has other
> ramifications. The server in question is running postfix 2.9.6-1
> on ubuntu 12.04. A different server with the same configuration
> does not seem to have the issue. Setting the debug_peer for the
> hosts show the same thing for the hosts that experience a delay
> versus those that do not, basically a bunch of match_hostaddr and
> match_hostname calls. Once the initial delay is out of the way,
> everything proceeds as normal.

Please TURN OFF chroot in master.cf.

The master.cf entry should look like this:

smtp  inet  n   -   n   -   -   smtpd

Then do "postfix reload".

More information: http://www.postfix.org/DEBUG_README.html#no_chroot

Wietse

Re: initial 220 greeting delay from hosts with no RDNS

[Joe Shamblin]

On May 27, 2014, at 2:38 PM, Wietse Venema  wrote:

> Joe Shamblin:
>> I am experiencing an issue where hosts that do not have reverse
>> DNS see an extended delay (45-60 seconds for ssl or non-ssl
>> connections) before they get the initial 220 greeting. Hosts that
>> do have properly registered entries get in immediately. I have
>> downloaded the source, and the programs that perform the lookups
>> gethostbyaddr, etc... all seem to return quickly enough. DNS on
>> the machine is also snappy and returns the lack of RDNS quickly.
>> Setting smtpd_peername_lookup to no solves the issue, but has other
>> ramifications. The server in question is running postfix 2.9.6-1
>> on ubuntu 12.04. A different server with the same configuration
>> does not seem to have the issue. Setting the debug_peer for the
>> hosts show the same thing for the hosts that experience a delay
>> versus those that do not, basically a bunch of match_hostaddr and
>> match_hostname calls. Once the initial delay is out of the way,
>> everything proceeds as normal.
> 
> Please TURN OFF chroot in master.cf.
> 
> The master.cf entry should look like this:
> 
> smtp  inet  n   -   n   -   -   smtpd
> 
> Then do "postfix reload".
> 
> More information: http://www.postfix.org/DEBUG_README.html#no_chroot

Yes that did the trick, thanks very much. Though it seems to break sasl 
authentication without making other changes. 

I had seen that in the documentation, and as the all caps imply should have 
payed closer attention, but I did verify that the chroot environment seemed 
correct as well. As I mentioned I have two hosts running basically the same 
configuration (except the local hostnames), and one seems to work fine and the 
other not. I assume that the chrooted environment is slightly preferred due to 
security. Is there an expedient way to track down where the problem might be 
with the chrooted environment, or a likely candidate from the information in 
the first post?

Thanks again!

Joe
--
Joe Shamblinw...@cs.duke.edu
Senior IT Analyst   Department of Computer Science
(919) 660-6582  Duke University



smime.p7s
Description: S/MIME cryptographic signature

Re: initial 220 greeting delay from hosts with no RDNS

[Wietse Venema]

Joe Shamblin:
> > Please TURN OFF chroot in master.cf.
> > 
> > The master.cf entry should look like this:
> > 
> > smtp  inet  n   -   n   -   -   smtpd
> > 
> > Then do "postfix reload".
> > 
> > More information: http://www.postfix.org/DEBUG_README.html#no_chroot
> 
> Yes that did the trick, thanks very much. Though it seems to break
> sasl authentication without making other changes.

You might be able to restore chroot operation, but then you'd
have to update the resolv.conf file or some other file related to
name lookup.

Wietse

Milter to block registrars

[James B. Byrne]

Without going into a lot of detail and without naming names I wish to know if,
at the time of connection to Postfix, there exists any feasible means of
determining the registrar used by the connecting domain?  As well, I would
like to know is there any practical means of determining at the time of smtp
connection by direct enquiry of a registrar when the connecting domain was
registered and block all connections from all non-whitelisted domains
registered within the past N days?

I am aware of the 'Day Old Bread' RBL / Greylist is used by SpamAssassin but
after some investigation I have come to the belief that a registrar is in fact
behind the latest spam attack we have encountered. Our experience is that by
the time DOB is updated the domain is no longer generating mail at all.  Given
the remote possibility that any domain registered with that registrar would
ever have a legitimate reason to contact us I wish to simply deny access to
our servers from any domain registered with them.  Given the equal
implausibility of a newly registered domain having any legitimate need I wish
also to block these.

Does anyone know of any milter projects usable by Postfix that address either
of these desires?


-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: Milter to block registrars

[Bennett Todd]

Two thoughts. 

I've received legitimate email from a registrar where I was listed as a contact 
for a domain. If no one uses an email address in your domain to register, 
that's not a problem. 

And second, whois is the way I query to find out about a domain, answers to 
questions like who registered it, with which registrar, and when. 
It may be safe to query it directly, but I'm a chicken, when I decided to 
include whois reports for each distinct IP address that directed Heartbleed 
attacks at our servers, I  rate limited the queries and cached the results. 

Relay access denied 454 not 544

[M. Rodrigo Monteiro]

Hi.
I wanna know why Postfix is reject mail with temp error (4xx) and not 5xx
for Relay access denied.

Here is the log:

May 27 12:11:34  postfix/smtpd[31197]: NOQUEUE: reject: RCPT from
mx2.mydomain.com.br[XXX.XXX.XXX.37]: 454 4.7.1 <
return-58306-110-...@otherdomain.com.br>: Relay access denied; from=<> to=<
return-58306-110-...@otherdomain.com.br> proto=ESMTP helo=<
mx2.mydomain.com.br>


Here is the conf:

smtpd_recipient_restrictions =
reject_multi_recipient_bounce,
permit_mynetworks,
reject_unauth_destination,
permit

# postconf relay_domains_reject_code
relay_domains_reject_code = 554


This server is a content filter only. It recieves mail from 2 MXs (mx1 and
mx2.mydomain.com), verify virus and spam, and relay to the destination.



M. Rodrigo Monteiro
  


   

"Free as in Freedom, not free as in free beer"
"As we are liberated from our own fear, our presence automatically
liberates others"
Linux User # 403730

Pense antes de imprimir. Think before printing.

AVISO LEGAL
Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é
dirigida, podendo conter informação confidencial e/ou legalmente
privilegiada. Se você não for destinatário desta mensagem, desde já fica
notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de
qualquer forma, utilizar a informação contida nesta mensagem, por ser
ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos
retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo
em sua base de dados, registros ou sistema de controle. Fica desprovida de
eficácia e validade a mensagem que contiver vínculos obrigacionais,
expedida por quem não detenha poderes de representação.

LEGAL ADVICE
This message is exclusively destined for the people to whom it is directed,
and it can bear private and/or legally exceptional information. If you are
not addressee of this message, since now you are advised to not release,
copy, distribute, check or, otherwise, use the information contained in
this message, because it is illegal. If you received this message by
mistake, we ask you to return this email, making possible, as soon as
possible, the elimination of its contents of your database, registrations
or controls system. The message that bears any mandatory links, issued by
someone who has no representation powers, shall be null or void.

Re: Milter to block registrars

[Wietse Venema]

James B. Byrne:
> Without going into a lot of detail and without naming names I wish to know if,
> at the time of connection to Postfix, there exists any feasible means of
> determining the registrar used by the connecting domain?  As well, I would

Beware, some whois servers enforce rate limits, so this is likely
to cause problems for a busy mail server.

On the other hand, Postfix has support to block domains by their
DNS (or MX) service provider: check_mumble_{ns,mx}_access for mumble
in client, reverse_client, helo, sender, recipient.

I have used that in the past to block snowshoe spam.

Wietse

Re: Relay access denied 454 not 544

[Wietse Venema]

M. Rodrigo Monteiro:
> Hi.
> I wanna know why Postfix is reject mail with temp error (4xx) and not 5xx
> for Relay access denied.
> 
> Here is the log:
> 
> May 27 12:11:34  postfix/smtpd[31197]: NOQUEUE: reject: RCPT from
> mx2.mydomain.com.br[XXX.XXX.XXX.37]: 454 4.7.1 <

Maybe the SMTP server has soft_bounce turned on.

Maybe the server has logged a DNS temporary lookup error prior to
this reject.

Wietse

Re: Relay access denied 454 not 544

[M. Rodrigo Monteiro]

2014-05-27 16:43 GMT-03:00 Wietse Venema :

>
> Maybe the SMTP server has soft_bounce turned on.
>
>
# postconf soft_bounce
soft_bounce = no



> Maybe the server has logged a DNS temporary lookup error prior to
> this reject.
>
>
No.


> Wietse
>

Re: Relay access denied 454 not 544

[Viktor Dukhovni]

On Tue, May 27, 2014 at 04:38:31PM -0300, M. Rodrigo Monteiro wrote:

> Hi.
> I wanna know why Postfix is reject mail with temp error (4xx) and not 5xx
> for Relay access denied.

What version of Postfix is this?

> Here is the conf:

Generally, you should post the output of "postconf -n" rather than
just what you think is relevant.

> smtpd_recipient_restrictions =
> reject_multi_recipient_bounce,
> permit_mynetworks,
> reject_unauth_destination,
> permit
> 
> # postconf relay_domains_reject_code
> relay_domains_reject_code = 554

With 2.10 or later, relay control is via smtpd_relay_restrictions.

-- 
Viktor.

Re: Milter to block registrars

[LuKreme]

On 27 May 2014, at 13:19 , James B. Byrne  wrote:

> Without going into a lot of detail and without naming names I wish to know if,
> at the time of connection to Postfix, there exists any feasible means of
> determining the registrar used by the connecting domain?

Not really.

Even if you wrote a milter or local rbl and used something like greylisting to 
give you time to do the lookups, you would probably run into problems with 
making many whois queries. Not only that, but every registrar seems to return 
info in different forms, so parsing the data will be difficult.

> As well, I would like to know is there any practical means of determining at 
> the time of smtp connection by direct enquiry of a registrar when the 
> connecting domain was registered and block all connections from all 
> non-whitelisted domains registered within the past N days?

Same problem.

> I am aware of the 'Day Old Bread' RBL / Greylist is used by SpamAssassin but
> after some investigation I have come to the belief that a registrar is in fact
> behind the latest spam attack we have encountered. Our experience is that by
> the time DOB is updated the domain is no longer generating mail at all.  Given
> the remote possibility that any domain registered with that registrar would
> ever have a legitimate reason to contact us I wish to simply deny access to
> our servers from any domain registered with them.  Given the equal
> implausibility of a newly registered domain having any legitimate need I wish
> also to block these.

You could modify a greylist setup to keep track of domains sending you mail and 
not allow a new domain for x days if you've never seen them before. I doubt 
this is a good idea, but you could certainly investigate it.

-- 
Dinosaurs are attacking! Throw a barrel!

relay ip map

[Alfredo Saldanha]

Hi there,

Is possible to create a hash map file with IPs to allow relay in my outbound 
server?
But I can not use the mynetworks entry to this.
I know that in 2.10 exist smtpd_relay_restrictions, but my version is 2.9.6.

Is there another way?

Thanks.

Re: Milter to block registrars

[Robert Schetterer]

Am 27.05.2014 21:19, schrieb James B. Byrne:
> Without going into a lot of detail and without naming names I wish to know if,
> at the time of connection to Postfix, there exists any feasible means of
> determining the registrar used by the connecting domain?  As well, I would
> like to know is there any practical means of determining at the time of smtp
> connection by direct enquiry of a registrar when the connecting domain was
> registered and block all connections from all non-whitelisted domains
> registered within the past N days?
> 
> I am aware of the 'Day Old Bread' RBL / Greylist is used by SpamAssassin but
> after some investigation I have come to the belief that a registrar is in fact
> behind the latest spam attack we have encountered. Our experience is that by
> the time DOB is updated the domain is no longer generating mail at all.  Given
> the remote possibility that any domain registered with that registrar would
> ever have a legitimate reason to contact us I wish to simply deny access to
> our servers from any domain registered with them.  Given the equal
> implausibility of a newly registered domain having any legitimate need I wish
> also to block these.
> 
> Does anyone know of any milter projects usable by Postfix that address either
> of these desires?
> 
> 

perhaps this helps

http://rss.uribl.com/nic/


Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

RE: Milter to block registrars

[Marius Gologan]

Whois should definitely not be implemented in automated systems - read ToS
of RIPE, ARIN, LACNIC etc.
A special-made milter that will dig for details during the connection time
is not applicable.
A secondary benefit of greylist is IP rotation. That will provide you an
insight about some networks , IP ranges and ISPs.
Registrars or hosting providers are not behind attacks, but they play a key
role in providing resources and delisting - notice the delisting rules of
some popular RBLs for IP classes. Now are there, next day are gone despite
their own retention policy.

I would go with reputation (mine or a third-party - the decision depends on
the messages volume) since some registrars are less tolerable than others,
volume and percentage are important too. 
For example, you don't want to block domains registered with godaddy just
because they might have some spamming domains there.

You can adjust the scoring in spamassassin for uribl.com if you want to be
more aggressive.
As a fast doable solution, I would prefer a custom meta rule (uribl.com &
bayes_90+ & pyzor - maybe) and a shortcircut rule to reduce resources and
time.
Plus a script that will collect all those IPs/Domains and put them into
postfix or rbldnsd to reject next connections more efficiently.

Geographic rules may help reducing spam, but not in all cases.
Too many non-existing recipients is also a sign of spam. You can turn some
of them into spam traps.

Marius.

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of James B. Byrne
Sent: Tuesday, May 27, 2014 10:20 PM
To: postfix-users-dig...@cloud9.net
Subject: Milter to block registrars

Without going into a lot of detail and without naming names I wish to know
if,
at the time of connection to Postfix, there exists any feasible means of
determining the registrar used by the connecting domain?  As well, I would
like to know is there any practical means of determining at the time of smtp
connection by direct enquiry of a registrar when the connecting domain was
registered and block all connections from all non-whitelisted domains
registered within the past N days?

I am aware of the 'Day Old Bread' RBL / Greylist is used by SpamAssassin but
after some investigation I have come to the belief that a registrar is in
fact
behind the latest spam attack we have encountered. Our experience is that by
the time DOB is updated the domain is no longer generating mail at all.
Given
the remote possibility that any domain registered with that registrar would
ever have a legitimate reason to contact us I wish to simply deny access to
our servers from any domain registered with them.  Given the equal
implausibility of a newly registered domain having any legitimate need I
wish
also to block these.

Does anyone know of any milter projects usable by Postfix that address
either
of these desires?


-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: Milter to block registrars

[James B. Byrne]

On Tue, May 27, 2014 15:32, Bennett Todd wrote:
> Two thoughts.
>
> I've received legitimate email from a registrar where I was listed as a
> contact for a domain. If no one uses an email address in your domain to
> register, that's not a problem.

I am attempting to be circumspect with respect to this situation.  Briefly, I
have formed the belief -- based upon evidence of mass changes to the ownership
and contact information of domains I reported as providing fraudulent contact
information and acting as ephemeral sources of mass UCE mailings -- that the
registrar of these domains is directly involved in the underlying SPAM
utterances and is not simply incompetent, inefficient, disinterested or simply
lazy.  As I say, this is my belief and I do not ask any to share it.  However,
I am prepared to act upon it in my own interests.

Presently I am not in the position to develop my own milter although that may
be exactly what I will have to do in the end.  I am seeking some sort of
add-in to Postfix that will take the incoming email domain and do a check of
some local cache acting thereafter according to the contents thereof.  If the
domain is not already tagged then the milter does a whois on the domain and
determines the registrar.  If the registrar is blacklisted in our
configuration then that domain is tagged, cached, the connection dropped and
further connections from the same domain are found in the cache and
effectively ignored.

Obviously, once the basics for such a milter are in place it is no great
stretch to check the registration date and tag those domains as well
regardless of registrar.  There seem to me no difficulty having uncached,
non-whitelisted, domains given a temporary refusal while the whois lookup
takes place, thus allowing reasonably spaced whois lookups.  If the whois
query is not returned in a timely manner (read blocked) then email from the
subject domain is refused on a temporary basis until the information is
obtained and a determination made.

I am fairly confident that in our circumstance the number of whois queries
will be rather small and the great majority of domains checked will prove to
be spam sources.  My enquiry here is aimed at establishing whether this is
already done and if not then the feasibility of doing it at all.  I am aware
of the Prefix WhoIs Milter project but that simply provides additional
headers.  I am looking for something a little more interventionist.  Of
course, if I have to do this myself then that would be a good place to start.

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: Milter to block registrars

[Eliezer Croitoru]

On 05/27/2014 11:33 PM, James B. Byrne wrote:

On Tue, May 27, 2014 15:32, Bennett Todd wrote:

>Two thoughts.
>
>I've received legitimate email from a registrar where I was listed as a
>contact for a domain. If no one uses an email address in your domain to
>register, that's not a problem.
Well you can use a domain blacklist which a addon will probe any domain 
you get emails from and verify their registrar and if found out then 
added to the domain blacklist.
Or you can get a daily\hourly report and report them to them main 
blacklists and by that block them and help the internet be a better 
place for emails.


But notice that a blacklisted domain might not like it.

Eliezer

using/logging client addr as part of SASL auth

[Ricardo Signes]

Hello!

I'm looking for a way to detect and distinguish different kinds of auth
failures.  Right now, I'm feeling a bit stuck by my inability to get all the
data I'd like in one place at the same time.

Right now, we're using SASL authentication with pwcheck.  pwcheck, of course,
only gets two data: username and password.  It can't take any action based on
the IP address of the remote.

Meanwhile, postfix's logs on failure don't appear to show me the username on
failed AUTH attempts.

I'd like to be able to distinguish the cases resulting from the intersections
of (one password over and over / many different passwords), (one username /
many usernames), (one IP address, many IP addresses).  With these data, I can
take better action to detect, classify, and react to bad actors.

I'm happy (I guess) to end up having to write code to make this happen, but I'm
not sure where I could do it.

-- 
rjbs


signature.asc
Description: Digital signature

Re: relay ip map

[Wietse Venema]

Alfredo Saldanha:
> Hi there,
> 
> Is possible to create a hash map file with IPs to allow relay in my outbound 
> server?

Yes this is possible.
http://www.postfix.org/postconf.5.html#mynetworks.

...You can also specify "/file/name" or "type:table" patterns. A
"/file/name" pattern is replaced by its contents; a "type:table"
lookup table is matched when a table entry matches a lookup string
(the lookup result is ignored).

Wietse

Re: using/logging client addr as part of SASL auth

[li...@rhsoft.net]

Am 27.05.2014 22:45, schrieb Ricardo Signes:
> I'm looking for a way to detect and distinguish different kinds of auth
> failures.  Right now, I'm feeling a bit stuck by my inability to get all the
> data I'd like in one place at the same time.
> 
> Right now, we're using SASL authentication with pwcheck.  pwcheck, of course,
> only gets two data: username and password.  It can't take any action based on
> the IP address of the remote.
> 
> Meanwhile, postfix's logs on failure don't appear to show me the username on
> failed AUTH attempts.
> 
> I'd like to be able to distinguish the cases resulting from the intersections
> of (one password over and over / many different passwords), (one username /
> many usernames), (one IP address, many IP addresses).  With these data, I can
> take better action to detect, classify, and react to bad actors.
> 
> I'm happy (I guess) to end up having to write code to make this happen, but 
> I'm
> not sure where I could do it

the problem ist that postfix has no idea of the SASL internals and should
not need to - in case of dovecot i asked a few days ago to log the username
because in case of using dovecot as SASL provider that's the only instance
which decodes the input and verify it against the user-db

sadly until now nobody cares except hints "turn debug on" which is no
solution in production to help users in case of password changesn and
forgot 2 out of 6 clients, especially for Apple users since that
crap needs to seperatly change the password for the outgoing server
while even MS Outlook 10 years ago offered a checkbox at setup
"use the same credentials as for POP3/IMAP"

Re: using/logging client addr as part of SASL auth

[Wietse Venema]

li...@rhsoft.net:
> the problem ist that postfix has no idea of the SASL internals and should
> not need to - in case of dovecot i asked a few days ago to log the username
> because in case of using dovecot as SASL provider that's the only instance
> which decodes the input and verify it against the user-db

Would not it be sufficient to trigger on repeated authentication
failures, regardless of the login name?

As Reindl observed, Postfix does not decode SASL protocols, it just
passes strings between the remote SMTP client and the local Dovecot
server or SASL implementation.

Wietse

Re: using/logging client addr as part of SASL auth

[li...@rhsoft.net]

Am 27.05.2014 23:04, schrieb Wietse Venema:
> li...@rhsoft.net:
>> the problem ist that postfix has no idea of the SASL internals and should
>> not need to - in case of dovecot i asked a few days ago to log the username
>> because in case of using dovecot as SASL provider that's the only instance
>> which decodes the input and verify it against the user-db
> 
> Would not it be sufficient to trigger on repeated authentication
> failures, regardless of the login name?

no - the problem is that i wanto to *help* users failing again and
again to send mail from mobile devices without realize that the
change of the POP3/IMAP password was not enough and need to do the
same for the outgoing server

in days of a lot of devices and carrier grade NAT filter the logs
for successful IMAP/POP3 logins from the same IP is just blind
guessinf

one may say it's the users problem - well i faced users clients
to send the same message again and agin every 5 minutes until
that damned iphone got stolen and so the log flood ended :-(


> As Reindl observed, Postfix does not decode SASL protocols, it just
> passes strings between the remote SMTP client and the local Dovecot
> server or SASL implementation.

sadly yes - *dovecot* should log that

RE: Milter to block registrars

[James B. Byrne]

On Tue, May 27, 2014 16:26, Marius Gologan wrote:
>
> Whois should definitely not be implemented in automated systems - read ToS
> of RIPE, ARIN, LACNIC etc.
> A special-made milter that will dig for details during the connection time
> is not applicable.
> A secondary benefit of greylist is IP rotation. That will provide you an
> insight about some networks , IP ranges and ISPs.
> Registrars or hosting providers are not behind attacks, but they play a key
> role in providing resources and delisting - notice the delisting rules of
> some popular RBLs for IP classes. Now are there, next day are gone despite
> their own retention policy.

In my case I have a reasonable doubt that the registrar involved is entirely
innocent.  In fact, on the balance of probabilities I rather think not. 
However, the technique used in these recent spam attacks is that the domains
are registered the same day, in some cases the same hour, that the UCE arrives
and they are discarded within hours of their first use.  It seems that most
greylist/blackhole lists are incapable of reacting in such a brief window.

>
> I would go with reputation (mine or a third-party - the decision depends on
> the messages volume) since some registrars are less tolerable than others,
> volume and percentage are important too.

I am not sure what this means so I have to ask you to explain it to me.  I
apologise in advance if I appear thick.

> For example, you don't want to block domains registered with godaddy just
> because they might have some spamming domains there.

I am not out to block every registrar, or even most, and hopefully not even a
considerable number.  Right now it is only one.  Based on recent experience I
would settle for a timely entry in DOB, but it is not reasonable to expect
them to add newly minted domain names within minutes of their registration.

>
> You can adjust the scoring in spamassassin for uribl.com if you want
> to be more aggressive. As a fast doable solution, I would prefer a
> custom meta rule (uribl.com & bayes_90+ & pyzor - maybe) and a
> shortcircut rule to reduce resources and time.

I have examined the messages and actually followed the links contained in
some.  What is happening is that the same fresh domain is used throughout the
UCE and when one follows the message links then javascript is used to redirect
one to the desired end address.  uribl is no more likely to have the URIs
contained in the messages than DOB and for the same reason.  The URIs simply
did not exist four to eight hours ago, were never used before and will not be
used again, at least not for UCE.  One at least has been re-purposed as a
watering-hole trap.


> Plus a script that will collect all those IPs/Domains and put them into
> postfix or rbldnsd to reject next connections more efficiently.

Yes, I suppose the easiest thing is to simply count the connections and after
N then block further receipts from these domains.  However, I have observed by
visual inspection of the maillog that the UCE originating domains are rotated
while sending so that one might have difficulty in picking a suitable time
period to match domain connections within.

>
> Geographic rules may help reducing spam, but not in all cases.
> Too many non-existing recipients is also a sign of spam. You can turn some
> of them into spam traps.
>

The domains that I bothered to trace had mail sent from servers in the Czech
Republic, Columbia, the USA, Canada, Taiwan, Vietnam, and Mexico.  I presume
that the dozens that I did not check originate from an equally diffuse
collection of places.

The non existent addresses is likely a fruitful line to pursue.  Is it
possible to configure Postfix as shipped to automatically add a connecting IP
address to a block list based upon the address that it is attempting delivery
to?  And then thereafter simply disregard connection attempts from the same
source?

Thanks,

-- 
***  E-Mail is NOT a SECURE channel  ***
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: using/logging client addr as part of SASL auth

[Ricardo Signes]

* Wietse Venema  [2014-05-27T17:04:32]
> li...@rhsoft.net:
> > the problem ist that postfix has no idea of the SASL internals and should
> > not need to - in case of dovecot i asked a few days ago to log the username
> > because in case of using dovecot as SASL provider that's the only instance
> > which decodes the input and verify it against the user-db
> 
> Would not it be sufficient to trigger on repeated authentication
> failures, regardless of the login name?

It's not ideal.  Here are some scenarios:

  a.  one IP, the same username,   many different passwords
  b.  one IP, different usernames, many different passwords
  c.  many IPs, the same username, many different passwords
  d.  one IP, the same username,   the same (wrong) password repeatedly

Scenarios a,b,c are much more likely to be attacks than (d), which looks like
somebody just turned on their old laptop without fixing its fetchmail job.

Scenario a and b are single-IP bad actors trying to perform a dictionary
attack, targeted or not.

Scenario c is potentially someone with a botnet trying to get a single target.

Taking action based on "repeatedly failed auth from ip X" is a start, but it's
not great.

I definitely understand the point about not wanting to deal with the SASL
internals.  Putting aside that question, do you have any suggestions or
thoughts about improving the way in which potential attacks could be classified
with currently available data?

-- 
rjbs


signature.asc
Description: Digital signature

RE: Milter to block registrars

[Bennett Todd]

Given the situation, perhaps you could set up a resolver that blocks, or
that's behind a packet filter that blocks, the IPs of the name servers
they're using. That would catch it at the NS lookup, and would be no extra
traffic, unlike whois.

Re: using/logging client addr as part of SASL auth

[Wietse Venema]

Ricardo Signes:
>   a.  one IP, the same username,   many different passwords
>   d.  one IP, the same username,   the same (wrong) password repeatedly

I suppose that one would log a password hhas, just to be sure.

> I definitely understand the point about not wanting to deal with the SASL
> internals.

It is not practical to implement every SASL protocol in Postfix.
Also, the more secure SASL protocols don't send a fixed password,
instead they use challenge-response. In that case there is no way
to find out whether you are looking at (a.) or (d.).

Postfix could log the base64 blobs that the client sends. Even
without decoding base64, this may be sufficient to see that someone
is using the same username and password repeatedly with AUTH PLAIN
or AUTH LOGIN, and you can base64 decode the blob to find out what
username may be involved.  But this effectively logs many plaintext
passwords to file.

> Putting aside that question, do you have any suggestions or thoughts
> about improving the way in which potential attacks could be
> classified with currently available data?

The general solution requires support in the authentication back-end,
be it Dovecot or the SASL library.

Wietse

Re: Milter to block registrars

[Patrick Ben Koetter]

* James B. Byrne :
> Without going into a lot of detail and without naming names I wish to know if,
> at the time of connection to Postfix, there exists any feasible means of
> determining the registrar used by the connecting domain?  As well, I would
> like to know is there any practical means of determining at the time of smtp
> connection by direct enquiry of a registrar when the connecting domain was
> registered and block all connections from all non-whitelisted domains
> registered within the past N days?

If they also run the NS or MX services, you might be able to block them using
check_sender_ns_access and/or check_sender_mx_access in Postfix.

p@rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 

RE: Milter to block registrars

[Marius Gologan]

There are RBLs for domains (aka DBL) that block recent domains (<= 5 or 7
days).
Indeed they need some time after "first-seen". Large RBL providers may rely
on their own old/large database. If the domain is not there, it must be new
(1). If they see multiple queries from different places (reliable), the
domain is sending mass mailing (2). Lookup individual sending IP to
determine if the domain is not hosted by a large hosting provider (3).
Lookup all sending IPs (4).
1+2+3 = (new) spamming domain (DBL).
1+2+3+4 = snow shoe, block CIDR (along with domain).

Unlike blacklist/whitelist, reputational list is based on percentage and
time frame.
You record not only bad domains, but you track also legit domains, for 1
month (time frame). The percentage between good and legit will be the
reputation of the registrar (1).
Once you start collecting and playing with these details, you will discover
more useful clues such as privacy-on/off (2) which can validate reputation
(3).

The project will take some effort and will not solve spam coming from
hijacked accounts hosted by innocent ISPs/ESPs - bayes is more useful here.
Some years ago I was tracking IPs that appeared nowhere. After days where
registered in South America (lacnic). The only way of protecting my network
in this particular case was to block connections from any unassigned IP.

As you say, "email is not a secure channel", but it can be tricky for all
parties. Personally, I prefer to let them deliver in quarantine and block
everything they have later, except 1 case where they use (or he uses) 1 IP
for each message per week totaling few thousands (hijacked MTA systems). I
admit, I'm a bit out of imagination and only bayes saves the day. Blocking
those IPs/Domains will be useless since they never occur second time.


-Original Message-
From: James B. Byrne [mailto:byrn...@harte-lyne.ca] 
Sent: Wednesday, May 28, 2014 12:14 AM
To: Marius Gologan
Cc: postfix-users-dig...@cloud9.net
Subject: RE: Milter to block registrars


On Tue, May 27, 2014 16:26, Marius Gologan wrote:
>
> Whois should definitely not be implemented in automated systems - read 
> ToS of RIPE, ARIN, LACNIC etc.
> A special-made milter that will dig for details during the connection 
> time is not applicable.
> A secondary benefit of greylist is IP rotation. That will provide you 
> an insight about some networks , IP ranges and ISPs.
> Registrars or hosting providers are not behind attacks, but they play 
> a key role in providing resources and delisting - notice the delisting 
> rules of some popular RBLs for IP classes. Now are there, next day are 
> gone despite their own retention policy.

In my case I have a reasonable doubt that the registrar involved is entirely
innocent.  In fact, on the balance of probabilities I rather think not. 
However, the technique used in these recent spam attacks is that the domains
are registered the same day, in some cases the same hour, that the UCE
arrives and they are discarded within hours of their first use.  It seems
that most greylist/blackhole lists are incapable of reacting in such a brief
window.

>
> I would go with reputation (mine or a third-party - the decision 
> depends on the messages volume) since some registrars are less 
> tolerable than others, volume and percentage are important too.

I am not sure what this means so I have to ask you to explain it to me.  I
apologise in advance if I appear thick.

> For example, you don't want to block domains registered with godaddy 
> just because they might have some spamming domains there.

I am not out to block every registrar, or even most, and hopefully not even
a considerable number.  Right now it is only one.  Based on recent
experience I would settle for a timely entry in DOB, but it is not
reasonable to expect them to add newly minted domain names within minutes of
their registration.

>
> You can adjust the scoring in spamassassin for uribl.com if you want 
> to be more aggressive. As a fast doable solution, I would prefer a 
> custom meta rule (uribl.com & bayes_90+ & pyzor - maybe) and a 
> shortcircut rule to reduce resources and time.

I have examined the messages and actually followed the links contained in
some.  What is happening is that the same fresh domain is used throughout
the UCE and when one follows the message links then javascript is used to
redirect one to the desired end address.  uribl is no more likely to have
the URIs contained in the messages than DOB and for the same reason.  The
URIs simply did not exist four to eight hours ago, were never used before
and will not be used again, at least not for UCE.  One at least has been
re-purposed as a watering-hole trap.


> Plus a script that will collect all those IPs/Domains and put them 
> into postfix or rbldnsd to reject next connections more efficiently.

Yes, I suppose the easiest thing is to simply count the connections and
after N then block further receipts from these domains.  However, I have
observed by vis

Re: using/logging client addr as part of SASL auth

[Ricardo Signes]

* Wietse Venema  [2014-05-27T17:48:03]
> Ricardo Signes:
> >   a.  one IP, the same username,   many different passwords
> >   d.  one IP, the same username,   the same (wrong) password repeatedly
> 
> I suppose that one would log a password hhas, just to be sure.

Yes, something like a truncated hash of the password salted with something
changed frequently and never stored.It only needs to detect
close-in-time "same password" with very low false positives.

> It is not practical to implement every SASL protocol in Postfix.
> Also, the more secure SASL protocols don't send a fixed password,
> instead they use challenge-response. In that case there is no way
> to find out whether you are looking at (a.) or (d.).

Indeed.  Fortunately (?) for me, I don't need to worry about that at this
point.

> Postfix could log the base64 blobs that the client sends.

Yes, I think that, as you suggest, this leads to a scary place.

> The general solution requires support in the authentication back-end,
> be it Dovecot or the SASL library.

I see now that libsasl v2's sasl_server_new takes a string in the form
"ipaddr:port" and that postfix's smtpd_sasl_activate seems to pass along the
actual remote client IP.  (Please tell me if I've grossly misread; I am not
familiar with Postfix's source.)  As long as we don't put an SMTP proxy in the
way, this suggests to me that I can probably do something *fairly* simple with
libsasl to get all the relevant data in one place.  I see a horrible, useful
hack in my future.

Thanks for your help.

-- 
rjbs


signature.asc
Description: Digital signature

disable smtpd_hard_error_limit

[tejas sarade]

Hello,

As per the Postfix documentation
"
*smtpd_hard_error_limit (default: normal: 20, overload: 1)*

The maximal number of errors a remote SMTP client is allowed to make
without delivering mail. The Postfix SMTP server disconnects when the limit
is exceeded. Normally the default limit is 20, but it changes under
overload to just 1. With Postfix 2.5 and earlier, the SMTP server always
allows up to 20 errors by default
"

I want to disable this behavior. Means no matter how many errors remote
client make, it should not disconnect the connection.

I know this is a bad idea. But I still want to do this.

Re: disable smtpd_hard_error_limit

[Viktor Dukhovni]

On Wed, May 28, 2014 at 10:20:56AM +0530, tejas sarade wrote:

> As per the Postfix documentation
> "
> *smtpd_hard_error_limit (default: normal: 20, overload: 1)*
> 
> The maximal number of errors a remote SMTP client is allowed to make
> without delivering mail. The Postfix SMTP server disconnects when the limit
> is exceeded. Normally the default limit is 20, but it changes under
> overload to just 1. With Postfix 2.5 and earlier, the SMTP server always
> allows up to 20 errors by default
> "
> 
> I want to disable this behavior. Means no matter how many errors remote
> client make, it should not disconnect the connection.

I am sure you can think of a number large enough to make it essentially
indistinguishable from infinity in this context.

-- 
Viktor.