Re: I've inherited a botnet target

[Ralf Hildebrandt]

* LuKreme :

> It's in 2.7 only, yes? I'm still running 2.6.

It's in the snapshots 

> Just add:
> 
> postscreen_dnsbl_sites zen.spamhous.org
> 
> To a 2.7 config?

No, you really have to read the README, since there are changes to
master.cf as well!

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: I've inherited a botnet target

[Ralf Hildebrandt]

* Nataraj :

> How does rate limiting work in conjunction with postscreen?

Just like without postscreen

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: disable bounce notification

[Giovanni Mancuso]

Noel Jones wrote:
> On 5/26/2010 11:55 AM, Giovanni Mancuso wrote:
>> Hi,
>>
>> I would disable in my postfix installation the sending of bounce mail.
>
> Solve the right problem; don't accept mail you can't deliver.
I can't do it, because my antispam server return 550 to my postfix that
is a MX record of my domain, but my postfix, can only receive connection
from 25, it doesn't do connection to port 25, because the firewall drop
this connection.

>
>   -- Noel Jones
>
>
>
>>
>> I try to change my master.cf in this way:
>>
>> bounce unix - n n - 0 pipe -vv
>> user=mail flags=Rq argv=/etc/postfix/bounce.sh
>>
>>
>> and the script bounce.sh is:
>>
>> # cat /etc/postfix/bounce.sh
>> #!/bin/bash
>> cat > /dev/null
>> exit 0
>>
>>
>> It works, but in my maillog i have:
>> May 26 17:50:19 mmt-l-fl11-prv postfix/pipe[23380]: bounce socket:
>> wanted attribute: flags
>> May 26 17:50:19 mmt-l-fl11-prv postfix/pipe[23380]:
>> vstream_buf_get_ready: fd 9 got 406
>> May 26 17:50:19 mmt-l-fl11-prv postfix/pipe[23380]: input attribute
>> name: nrequest
>> May 26 17:50:19 mmt-l-fl11-prv postfix/pipe[23380]: warning: unexpected
>> attribute nrequest in input from bounce socket
>> May 26 17:50:19 mmt-l-fl11-prv postfix/pipe[23380]: warning:
>> deliver_request_get: error receiving common attributes
>> May 26 17:50:19 mmt-l-fl11-prv postfix/pipe[23380]:
>> deliver_request_final: send: "" -1
>>
>> Can you point me where is the problem?
>>
>> And, Is there another way to disable bounce notification?
>

illegal address syntax

[Jonathan Tripathy]

Hi Everyone,

I'm currently in the middle of watching a customer's mail.log file. He 
is trying to send an email to a lot of people at once (Something like 
5000), however the logs don't reflect this. Instead I'm seeing:


May 27 10:32:41 server1 postfix/smtpd[8144]: connect from 
office1.domain.local[10.86.1.101]
May 27 10:32:43 server1 postfix/smtpd[8144]: warning: Illegal address 
syntax from office1.domain.local[10.86.1.101] in RCPT command: 

May 27 10:32:44 server1 postfix/smtpd[8144]: warning: Illegal address 
syntax from office1.domain.local[10.86.1.101] in RCPT command: 

May 27 10:32:55 server1 postfix/smtpd[8144]: too many errors after RCPT 
from office1.domain.local[10.86.1.101]
May 27 10:37:55 server1 postfix/smtpd[8144]: disconnect from 
office1.domain.local[10.86.1.101]


The above is happening over and over again (minute or so) with no sign 
of the other emails being sent. Presumably, the client (Outlook 2003) 
keeps retrying..


As you can see, the client is trying to send an email to 2 email address 
with a + in it, which postfix doesn't seem to like. This may be the 
case, and may be ok, however my concern is that why aren't I seeing any 
emails being sent to the other 4998 valid addresses? Is there anything I 
can do to force postfix use those addresses?


Thanks

Jonathan

Re: illegal address syntax

[Ralf Hildebrandt]

* Jonathan Tripathy :
> Hi Everyone,
> 
> I'm currently in the middle of watching a customer's mail.log file.
> He is trying to send an email to a lot of people at once (Something
> like 5000), however the logs don't reflect this. Instead I'm seeing:
> 
> May 27 10:32:41 server1 postfix/smtpd[8144]: connect from
> office1.domain.local[10.86.1.101]
> May 27 10:32:43 server1 postfix/smtpd[8144]: warning: Illegal address
> syntax from office1.domain.local[10.86.1.101] in RCPT command:
> 
> May 27 10:32:44 server1 postfix/smtpd[8144]: warning: Illegal address
> syntax from office1.domain.local[10.86.1.101] in RCPT command:
> 
> May 27 10:32:55 server1 postfix/smtpd[8144]: too many errors after
> RCPT from office1.domain.local[10.86.1.101]
> May 27 10:37:55 server1 postfix/smtpd[8144]: disconnect from
> office1.domain.local[10.86.1.101]
> 
> The above is happening over and over again (minute or so) with no
> sign of the other emails being sent. Presumably, the client (Outlook
> 2003) keeps retrying..

Korrekt. The mail never gets sent

> As you can see, the client is trying to send an email to 2 email
> address with a + in it, which postfix doesn't seem to like.

Yes.

> This may be the case, and may be ok, however my concern is that why
> aren't I seeing any emails being sent to the other 4998 valid
> addresses? Is there anything I can do to force postfix use those
> addresses?

too many errors after...

raise the soft_error_limit and/or the hard_error_limit

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: illegal address syntax

[Jonathan Tripathy]

On 27/05/10 10:41, Jonathan Tripathy wrote:

Hi Everyone,

I'm currently in the middle of watching a customer's mail.log file. He 
is trying to send an email to a lot of people at once (Something like 
5000), however the logs don't reflect this. Instead I'm seeing:


May 27 10:32:41 server1 postfix/smtpd[8144]: connect from 
office1.domain.local[10.86.1.101]
May 27 10:32:43 server1 postfix/smtpd[8144]: warning: Illegal address 
syntax from office1.domain.local[10.86.1.101] in RCPT command: 

May 27 10:32:44 server1 postfix/smtpd[8144]: warning: Illegal address 
syntax from office1.domain.local[10.86.1.101] in RCPT command: 

May 27 10:32:55 server1 postfix/smtpd[8144]: too many errors after 
RCPT from office1.domain.local[10.86.1.101]
May 27 10:37:55 server1 postfix/smtpd[8144]: disconnect from 
office1.domain.local[10.86.1.101]


The above is happening over and over again (minute or so) with no sign 
of the other emails being sent. Presumably, the client (Outlook 2003) 
keeps retrying..


As you can see, the client is trying to send an email to 2 email 
address with a + in it, which postfix doesn't seem to like. This may 
be the case, and may be ok, however my concern is that why aren't I 
seeing any emails being sent to the other 4998 valid addresses? Is 
there anything I can do to force postfix use those addresses?


Thanks

Jonathan


Even after removing those 2 address from the list, we are still getting 
the "too many errors after RCPT from office1.domain.local[10.86.1.101]" 
(Of course, the 2 email addresses aren't mentioned anymore)

Re: illegal address syntax

[Jonathan Tripathy]

too many errors after...

raise the soft_error_limit and/or the hard_error_limit

   


Ah! So my postfix server has a limit then. Where can I put these 
settings? In main.cf ?

Re: illegal address syntax

[Ralf Hildebrandt]

* Jonathan Tripathy :
> 
> >too many errors after...
> >
> >raise the soft_error_limit and/or the hard_error_limit
> >
> 
> Ah! So my postfix server has a limit then. Where can I put these
> settings? In main.cf ?

Yes, like almost all settings...

smtpd_hard_error_limit = 1000
smtpd_soft_error_limit = 1000

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: illegal address syntax

[Ralf Hildebrandt]

* Jonathan Tripathy :

> Even after removing those 2 address from the list, we are still
> getting the "too many errors after RCPT from
> office1.domain.local[10.86.1.101]" (Of course, the 2 email addresses
> aren't mentioned anymore)

And what's it complaining about now (BTW, that's why one uses mailing
list manager like mailman!)?
-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Re: illegal address syntax

[Jonathan Tripathy]

On 27/05/10 11:11, Ralf Hildebrandt wrote:

* Jonathan Tripathy:
   
 

too many errors after...

raise the soft_error_limit and/or the hard_error_limit

   

Ah! So my postfix server has a limit then. Where can I put these
settings? In main.cf ?
 

Yes, like almost all settings...

smtpd_hard_error_limit = 1000
smtpd_soft_error_limit = 1000

   


Ok, I changed the above 2 settings to be 1 in my main.cf file, 
however it didn't change anything (Still showed too many errors). But 
what I did do, is change smtpd_recipient_limit to 10,000 and no 
everything seems to be working ok...

Re: user unknown, not getting mapped

[Charles Marcus]

On 2010-05-26 9:50 PM, Sahil Tandon wrote:
> Do not, as suggested by another poster, simply requeue ALL messages
> -- unless, of course, that is what you really intend.

Ooops, thanks for catching that Sahil. I have a fairly low volume
server, so my queue is essentially always empty - so I can safely
postsuper ALL without consequence. I forget that some people actually
run 'real' mail servers that often/always have large queues. ;)

-- 

Best regards,

Charles

Error with the command XXXX

[Pascal Maes]

Hello,


I see sometimes the following error in the logfile :

May 27 13:04:43 smtp-1 postfix/smtpd[28724]: too many errors after UNKNOWN from 
mail.everbridge.net[63.236.8.147]
May 27 12:32:42 smtp-1 postfix/smtpd[20935]: too many errors after UNKNOWN from 
paradis.cirad.fr[193.51.113.1]


and I wonder why.

For 193.51.113.1, I have set the debugging options and I get the following 
results :

May 27 02:32:36 smtp-1 postfix/smtpd[7464]: connect from 
paradis.cirad.fr[193.51.113.1]
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostname: paradis.cirad.fr ~? 
127.0.0.0/8
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostaddr: 193.51.113.1 ~? 
127.0.0.0/8
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostname: paradis.cirad.fr ~? 
10.0.0.0/8
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostaddr: 193.51.113.1 ~? 
10.0.0.0/8
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostname: paradis.cirad.fr ~? 
130.104.0.0/16
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostaddr: 193.51.113.1 ~? 
130.104.0.0/16
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostname: paradis.cirad.fr ~? 
192.168.128.0/17
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostaddr: 193.51.113.1 ~? 
192.168.128.0/17
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostname: paradis.cirad.fr ~? 
193.190.89.0/24
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_hostaddr: 193.51.113.1 ~? 
193.190.89.0/24
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_list_match: paradis.cirad.fr: 
no match
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: match_list_match: 193.51.113.1: no 
match
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: send attr request = connect
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: send attr ident = smtp:193.51.113.1
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: vstream_fflush_some: fd 59 flush 41
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: vstream_buf_get_ready: fd 59 got 25
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: private/anvil: wanted attribute: 
status
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute name: status
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute value: 0
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: private/anvil: wanted attribute: 
count
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute name: count
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute value: 1
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: private/anvil: wanted attribute: 
rate
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute name: rate
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute value: 1
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: private/anvil: wanted attribute: 
(list terminator)
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: input attribute name: (end)
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: report connect to all milters
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter_macro_lookup: "j"
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter_macro_lookup: result 
"smtp1.sgsi.ucl.ac.be"
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter_macro_lookup: "{daemon_name}"
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter_macro_lookup: result 
"smtp1.sgsi.ucl.ac.be"
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter_macro_lookup: "v"
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter_macro_lookup: result 
"Postfix 2.7.0"
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: non-protocol 
events for protocol version 6: 
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: transport=unix 
endpoint=/var/run/clamav/milter-clamav.socket
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: my_version=0x6
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: my_actions=0x1ff 
SMFIF_ADDHDRS SMFIF_CHGBODY SMFIF_ADDRCPT SMFIF_DELRCPT SMFIF_CHGHDRS 
SMFIF_QUARANTINE SMFIF_CHGFROM SMFIF_ADDRCPT_PAR SMFIF_SETSYMLIST
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: my_events=0x1f 
SMFIP_NOCONNECT SMFIP_NOHELO SMFIP_NOMAIL SMFIP_NORCPT SMFIP_NOBODY 
SMFIP_NOHDRS SMFIP_NOEOH SMFIP_NR_HDR SMFIP_NOUNKNOWN SMFIP_NODATA SMFIP_SKIP 
SMFIP_RCPT_REJ SMFIP_NR_CONN SMFIP_NR_HELO SMFIP_NR_MAIL SMFIP_NR_RCPT 
SMFIP_NR_DATA SMFIP_NR_UNKN SMFIP_NR_EOH SMFIP_NR_BODY SMFIP_HDR_LEADSPC
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: vstream_fflush_some: fd 13 flush 17
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: vstream_buf_get_ready: fd 13 got 17
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: milter 
unix:/var/run/clamav/milter-clamav.socket version 6
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: events 
SMFIP_NOHELO SMFIP_NOEOH SMFIP_NOUNKNOWN SMFIP_NODATA
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_connect: requests 
SMFIF_ADDHDRS SMFIF_CHGHDRS SMFIF_QUARANTINE
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: milter8_conn_event: milter 
unix:/var/run/clamav/milter-clamav.socket: connect paradis.cirad.fr/193.51.113.1
May 27 02:32:36 smtp-1 postfix/smtpd[7464]: event: SMFIC_CONNECT; macros: 
j=smtp1.sgsi.ucl.ac.be {daemon_

Re: disable bounce notification

[Charles Marcus]

On 2010-05-27 5:19 AM, Giovanni Mancuso wrote:
> Noel Jones wrote:
>> On 5/26/2010 11:55 AM, Giovanni Mancuso wrote:
>>> I would disable in my postfix installation the sending of bounce
>>> mail.

>> Solve the right problem; don't accept mail you can't deliver.

> I can't do it,

Yes, you can, you just need to learn how.

> because my antispam server return 550 to my postfix that is a MX
> record of my domain, but my postfix, can only receive connection from
> 25, it doesn't do connection to port 25, because the firewall drop 
> this connection.

Never reject mail once you've accepted it for final delivery. Period.
Anything else is bad design.

The problem apparently is you have a content (antispam) filter that is
rejecting mail *after* it has been accepted for final delivery. Don't do
that. Period.

Either change it to a before queue content filter - which can be a
problem on high volume systems - or don't reject it from your anti-spam
filter, tag+deliver it.

-- 

Best regards,

Charles

Re: Error with the command XXXX

[Wietse Venema]

Pascal Maes:
> May 27 02:32:36 smtp-1 postfix/smtpd[7464]: > paradis.cirad.fr[193.51.113.1]: 
> 220 smtp1.sgsi.ucl.ac.be ESMTP
> smtpd_banner = $myhostname ESMTP
> May 27 02:32:36 smtp-1 postfix/smtpd[7464]: < paradis.cirad.fr[193.51.113.1]: 
>  paradis.cirad.fr
> May 27 02:32:36 smtp-1 postfix/smtpd[7464]: > paradis.cirad.fr[193.51.113.1]: 
> 502 5.5.2 Error: command not recognized

Turn off SMTP protocol f-up mode in the CISCO.

Wietse

postscreen questions

[Andy Dills]

I've been investigating postscreen, as we've been address probed/bombed 
for years, as we have a few domains that are very old (well, early 90s) 
that had a lot of users back in the dialup days. Our approach was to just 
throw hardware at the problem, and we've had a whole cluster of servers 
just sending out 550s all day long for years now.

We don't do any RBL checks at the postfix level; we have amavisd-new 
handle all of that via spamassassin. I'm hesitant to allow a single 
blacklist to determine the fate of mail acceptance, especially when we 
have a very low false negative rate with amavisd/SA. Essentially, we'd 
rather throw hardware at the problem than potentially reject legit mail.

My primary question is, would we see significant improvement by using 
postscreen if we don't use RBLs?

Also, would postscreen_cache_map work with a mysql backend?

Thanks,
Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

recipient_delimiter and check_recipient_access

[Emmanuel Seyman]

Hello, all.

I'm using a mailrelay and an internal server setup.
The mailrelay receives mail from the internet, runs a number of checks +
spamassassin + clamav then passes mail to the internal mail server.

One of the checks enforced on the mailrelay is
check_recipient_access hash:/etc/postfix/users where /etc/postfix/users
contains :

 OK
 OK
 OK
 OK
 OK

 REJECT

This ensures that mail for inexistant users is blocked as soon as possible
and it's worked well for months.

I now want to activate recipient_delimiter bu I've realized that it's
incompatible with the recipient check. Is there any way to have the best
of both worlds? 

Emmanuel

Re: postscreen questions

[Robert Schetterer]

Am 27.05.2010 15:34, schrieb Andy Dills:
> 
> I've been investigating postscreen, as we've been address probed/bombed 
> for years, as we have a few domains that are very old (well, early 90s) 
> that had a lot of users back in the dialup days. Our approach was to just 
> throw hardware at the problem, and we've had a whole cluster of servers 
> just sending out 550s all day long for years now.

same here, old short domains, openrelays in early times
but checked to handle it with one machine, but of course yours might be
more spammy at all
> 
> We don't do any RBL checks at the postfix level; 

why do you not use selective rbl checks, only for dynip etc, as well as
greylisting, there are a lot good cheap tricks with restictions that
should help

and/or perhaps use recent with iptables and/or fail2ban

we have amavisd-new
> handle all of that via spamassassin. I'm hesitant to allow a single 
> blacklist to determine the fate of mail acceptance, especially when we 
> have a very low false negative rate with amavisd/SA. Essentially, we'd 
> rather throw hardware at the problem than potentially reject legit mail.

amavis should not gamble a lot with spam/virus until if you have good
checks before it
i have one support ticket a week i.e.
by 3000 Mailboxes, mostly problems of the sender, extrem rare rbl
related, nothing that cant be handeled easy

> 
> My primary question is, would we see significant improvement by using 
> postscreen if we don't use RBLs?

as far i know postscreen should help anyway
but you should measure aud investigate your logs if a cheap/short 550
is more usefull sometimes

> 
> Also, would postscreen_cache_map work with a mysql backend?

dont think so, but gurus should know exactly

> 
> Thanks,
> Andy
> 
> ---
> Andy Dills
> Xecunet, Inc.
> www.xecu.net
> 301-682-9972
> ---

after all dont expect spammers/bots will give up only
cause you have new antispam features integrated
you may clean up your logs and/or need less resources
but at my spam domains , spam traffic was never
related to what antispam feature i ever integrated
it was always in waves

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: I've inherited a botnet target

[Noel Jones]

On 5/26/2010 8:21 PM, LuKreme wrote:

On 26-May-2010, at 17:01, Noel Jones wrote:


On 5/26/2010 5:34 PM, LuKreme wrote:



postscreen is currently available in the postfix 2.8 snapshots.  Instructions 
for activating postscreen are included in the RELEASE_NOTES.  eg. 
http://postfix.energybeam.com/source/experimental/postfix-2.8-20100323.RELEASE_NOTES


Is it possible to run postscreen from 2.8 with 2.7 or would I need to run a 2.8 
snapshot?



Postscreen requires postfix 2.8.  The snapshots are production 
quality; the feature set is subject to change before the 
version is declared "stable".


  -- Noel Jones

Re: postscreen questions

[Wietse Venema]

Andy Dills:
> 
> I've been investigating postscreen, as we've been address probed/bombed 
> for years, as we have a few domains that are very old (well, early 90s) 
> that had a lot of users back in the dialup days. Our approach was to just 
> throw hardware at the problem, and we've had a whole cluster of servers 
> just sending out 550s all day long for years now.
> 
> We don't do any RBL checks at the postfix level; we have amavisd-new 
> handle all of that via spamassassin. I'm hesitant to allow a single 
> blacklist to determine the fate of mail acceptance, especially when we 
> have a very low false negative rate with amavisd/SA. Essentially, we'd 
> rather throw hardware at the problem than potentially reject legit mail.
> 
> My primary question is, would we see significant improvement by using 
> postscreen if we don't use RBLs?

In my experience, the "pregreet" check kills off 50% of the zombies.
Of course malware will "improve" and I expect to add deeper protocol
checks (command pipelining, greylist) in anticipation.

> Also, would postscreen_cache_map work with a mysql backend?

postscreen needs very low latency (I put in explicit tests for
this).  Also, postscreen requires read, write, iterate support
which is implemented only for file-based databases.

If table access requires 10ms, then postscreen can handle only 100
connection requests per second. You would be better off not using
postscreen and instead turning up the number of smtpd processes.

Wietse

Re: user unknown, not getting mapped

[Phil Howard]

On Wed, May 26, 2010 at 16:52, Charles Marcus  wrote:
> On 2010-05-26 4:12 PM, Phil Howard wrote:
>> Is there a way to get it to be remapped now that it is in the
>> delivery queue? Or should I just create a mailbox for f...@example.com
>> and mv the file over to b...@example.com?
>
> Not sure if it would help, but maybe:
>
> postsuper -r ALL
>
> man postsuper

I ended up doing a symlink trick, plus faked password entries, to get
Dovecot deliver to go ahead and accept the delivery and put it in the
intended mailbox.  But I will read this man page for future needs.

Re: recipient_delimiter and check_recipient_access

[Noel Jones]

On 5/27/2010 8:47 AM, Emmanuel Seyman wrote:


Hello, all.

I'm using a mailrelay and an internal server setup.
The mailrelay receives mail from the internet, runs a number of checks +
spamassassin + clamav then passes mail to the internal mail server.

One of the checks enforced on the mailrelay is
check_recipient_access hash:/etc/postfix/users where /etc/postfix/users
contains :

  OK
  OK
  OK
  OK
  OK

  REJECT

This ensures that mail for inexistant users is blocked as soon as possible
and it's worked well for months.

I now want to activate recipient_delimiter bu I've realized that it's
incompatible with the recipient check. Is there any way to have the best
of both worlds?


Yes, man 5 access, look for the "email address extension" section.


  -- Noel Jones

Re: IDN domain name support

[Alejandro Cabrera Obed]

Dear all, I've just made a test from Gmail and my Thunderbird mail
client sending a mail to a non-real IDN mail user:

alejan...@años.com.ar

- My Thunderbird says: "An error ocurred while sending mail. Tha mail
servers responded: 5.1.3 Bad recipient address syntax" (THIS IS A
SERVER RESPONSE)

- The Gmail webmail says: "One o more mail address in "To:" box is not
recognized" (THIS IS A CLIENT RESPONSE)

So, I think the IDN domain name support is not complete nowadays,
neither by mail servers nor by mail clients. So it's not convenient
the IDN mail implementation in this bad situation.

What do you think about this matter ???

Really thanks

2010/5/26 Wietse Venema :
> Alejandro Cabrera Obed:
>> Wietse, thanks...but in Postfix I have to work with the ?o?o.com.ar
>> domain name or with the xn--oo-yjab.gov.ar punycode domain name ???
>
> Read carefully.
>
> The MAIL CLIENT must tranform non-ASCII domain names before
> sending MAIL FROM or RCPT TO commands.
>
>        Wietse
>



-- 
Alejandro Cabrera Obed
aco1...@gmail.com
www.alejandrocabrera.com.ar

Re: IDN domain name support

[Brian Evans - Postfix List]

On 5/27/2010 2:29 PM, Alejandro Cabrera Obed wrote:
> Dear all, I've just made a test from Gmail and my Thunderbird mail
> client sending a mail to a non-real IDN mail user:
>
> alejan...@años.com.ar
>
> - My Thunderbird says: "An error ocurred while sending mail. Tha mail
> servers responded: 5.1.3 Bad recipient address syntax" (THIS IS A
> SERVER RESPONSE)
>   

This is due to a (very old) CLIENT bug, [1]

The server is just complaining about bad CLIENT syntax.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=127399

> - The Gmail webmail says: "One o more mail address in "To:" box is not
> recognized" (THIS IS A CLIENT RESPONSE)
>
> So, I think the IDN domain name support is not complete nowadays,
> neither by mail servers nor by mail clients. So it's not convenient
> the IDN mail implementation in this bad situation.
>
> What do you think about this matter ???
>
> Really thanks
>
> 2010/5/26 Wietse Venema :
>   
>> Alejandro Cabrera Obed:
>> 
>>> Wietse, thanks...but in Postfix I have to work with the ?o?o.com.ar
>>> domain name or with the xn--oo-yjab.gov.ar punycode domain name ???
>>>   
>> Read carefully.
>>
>> The MAIL CLIENT must tranform non-ASCII domain names before
>> sending MAIL FROM or RCPT TO commands.
>>
>>Wietse
>>
>> 
>
>
>   

Re: IDN domain name support

[Alejandro Cabrera Obed]

OK, this is in case of my Thunderbird Debian lenn package, but what
about the Gmail syntax error warning ??? In Hotmail is the same, it
tells me that the recipient address just must have 1-9, a-z and @
charactersin this case with my IDN domain I wiil remain isolate of
the Hotmail, Yahoo, Gmail world and it's not good !!!

Any comment ???

2010/5/27 Brian Evans - Postfix List :
> On 5/27/2010 2:29 PM, Alejandro Cabrera Obed wrote:
>> Dear all, I've just made a test from Gmail and my Thunderbird mail
>> client sending a mail to a non-real IDN mail user:
>>
>> alejan...@años.com.ar
>>
>> - My Thunderbird says: "An error ocurred while sending mail. Tha mail
>> servers responded: 5.1.3 Bad recipient address syntax" (THIS IS A
>> SERVER RESPONSE)
>>
>
> This is due to a (very old) CLIENT bug, [1]
>
> The server is just complaining about bad CLIENT syntax.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=127399
>
>> - The Gmail webmail says: "One o more mail address in "To:" box is not
>> recognized" (THIS IS A CLIENT RESPONSE)
>>
>> So, I think the IDN domain name support is not complete nowadays,
>> neither by mail servers nor by mail clients. So it's not convenient
>> the IDN mail implementation in this bad situation.
>>
>> What do you think about this matter ???
>>
>> Really thanks
>>
>> 2010/5/26 Wietse Venema :
>>
>>> Alejandro Cabrera Obed:
>>>
 Wietse, thanks...but in Postfix I have to work with the ?o?o.com.ar
 domain name or with the xn--oo-yjab.gov.ar punycode domain name ???

>>> Read carefully.
>>>
>>> The MAIL CLIENT must tranform non-ASCII domain names before
>>> sending MAIL FROM or RCPT TO commands.
>>>
>>>        Wietse
>>>
>>>
>>
>>
>>
>
>



-- 
Alejandro Cabrera Obed
aco1...@gmail.com
www.alejandrocabrera.com.ar

Re: IDN domain name support

[Per Jessen]

Alejandro Cabrera Obed wrote:

> Dear all, I've just made a test from Gmail and my Thunderbird mail
> client sending a mail to a non-real IDN mail user:
> 
> alejan...@años.com.ar
> 
> - My Thunderbird says: "An error ocurred while sending mail. Tha mail
> servers responded: 5.1.3 Bad recipient address syntax" (THIS IS A
> SERVER RESPONSE)
> 
> - The Gmail webmail says: "One o more mail address in "To:" box is not
> recognized" (THIS IS A CLIENT RESPONSE)
> 
> So, I think the IDN domain name support is not complete nowadays,
> neither by mail servers nor by mail clients. So it's not convenient
> the IDN mail implementation in this bad situation.
> 
> What do you think about this matter ???

I think you're wrong - my thunderbird and my postfix does fine with
mails to and from @ënidan.ch  (a test domain I set about two years
ago). 


/Per Jessen, Zürich

Re: IDN domain name support

[Victor Duchovni]

On Thu, May 27, 2010 at 04:01:41PM -0300, Alejandro Cabrera Obed wrote:

> OK, this is in case of my Thunderbird Debian lenn package, but what
> about the Gmail syntax error warning ??? In Hotmail is the same, it
> tells me that the recipient address just must have 1-9, a-z and @
> charactersin this case with my IDN domain I wiil remain isolate of
> the Hotmail, Yahoo, Gmail world and it's not good !!!

Please waste no further time on this list. Postfix works with IDN. If
many clients still don't, that is NOT a Postfix issue. The clients
MUST (if they support IDN domains) send punycode encoded domains to
the SMTP server.

-- 
Viktor.

Re: IDN domain name support

[Per Jessen]

Per Jessen wrote:

>> So, I think the IDN domain name support is not complete nowadays,
>> neither by mail servers nor by mail clients. So it's not convenient
>> the IDN mail implementation in this bad situation.
>> 
>> What do you think about this matter ???
> 
> I think you're wrong - my thunderbird and my postfix does fine with
> mails to and from @ënidan.ch  (a test domain I set about two years
> ago).

Correction - thunderbird doesn't work with IDNs.  TB 3.0 is supposed to
though.


/Per Jessen, Zürich

Re: postscreen questions

[Nataraj]

Andy Dills wrote:
I've been investigating postscreen, as we've been address probed/bombed 
for years, as we have a few domains that are very old (well, early 90s) 
that had a lot of users back in the dialup days. Our approach was to just 
throw hardware at the problem, and we've had a whole cluster of servers 
just sending out 550s all day long for years now.


We don't do any RBL checks at the postfix level; we have amavisd-new 
handle all of that via spamassassin. I'm hesitant to allow a single 
blacklist to determine the fate of mail acceptance, especially when we 
have a very low false negative rate with amavisd/SA. Essentially, we'd 
rather throw hardware at the problem than potentially reject legit mail.


My primary question is, would we see significant improvement by using 
postscreen if we don't use RBLs?


Also, would postscreen_cache_map work with a mysql backend?

Thanks,
Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---
  
Using things like amavisd and spamassasin besides being very costly in 
terms of performance, is far more vulnerable to security exploits than 
rejecting as many connections as possible at an earlier time.  I have 
used the various checks for valid domain names, helo names, etc, in 
conjunction with the RBL's to minimize scanning with spamassasin.   I 
use restriction classes to define more and less conservative policys for 
different domains and even specific users when necessary.


smtpd_restriction_classes = restrictive, permissive

restrictive =
   reject_rbl_client zen.spamhaus.org
   reject_rbl_client dul.dnsbl.sorbs.net
   reject_rbl_client bl.spamcop.net

permissive =
   reject_rbl_client pbl.spamhaus.org
   reject_rbl_client dul.dnsbl.sorbs.net


  check_recipient_access hash:/etc/postfix/smtpd_recipient_access

smtpd_recipient_access contains:
mydomain.com restrictive
# I get the abuse mail and don't want to see alot of spam
ab...@otherdomain.com   restrictive
otherdomain.org  permissive
127.0.0.1   OK


The permissive class is very conservative and should cause practically 
no false positives.  Even my restrictive class includes rbls known to 
have extremely low false positive rates.  Spamhaus is known to be one of 
the most accurate rbl's with an excellent hit rate and low false 
positives.  If you have a large site, check their web pages, since they 
do charge for high volume query rates and will block your access if you 
exceed the free limit.


Nataraj

Re: IDN domain name support

[Pat]

>> Wietse, thanks...but in Postfix I have to work with the ?o?o.com.ar
>> domain name or with the xn--oo-yjab.gov.ar punycode domain name ???
>
> The MAIL CLIENT must tranform non-ASCII domain names before
> sending MAIL FROM or RCPT TO commands.

ICANN did not really consider the security and portability of IDNs before
permitting them.  The reasons for this are many, and speak poorly to ICANN's
management structure.  It is important to remember that ICANN's action does not
mean that end-users are prepared to accept mail from such domains, or that 
doing so
would be secure, much less that operating systems, libraries, and applications 
are
capable of dealing with IDNs safely.

Whether IDNs will ever be portable is a matter of debate.  Right now they are in
early-alpha status i.e., not ready for production.  This might be OK for some 
DNS
and SMTP implementations but for most production systems they pose too high of a
risk.  The increase in complexity of each OS, lib, and app required to 
accommodate
IDNs is non-trivial.  Widespread implementation would degrade security in and of
itself (because of the relationship between code size and security among other
factors).

Speaking only for myself, for the foreseeable future we are not interested in
experimental code and do not want to use a version of bind or postfix that 
cannot
be compiled to refuse IDNs.

Pat

Re: postscreen questions

[LuKreme]

On 27-May-2010, at 07:34, Andy Dills wrote:
> 
> I've been investigating postscreen, as we've been address probed/bombed 
> for years, as we have a few domains that are very old (well, early 90s) 
> that had a lot of users back in the dialup days. Our approach was to just 
> throw hardware at the problem, and we've had a whole cluster of servers 
> just sending out 550s all day long for years now.
> 
> We don't do any RBL checks at the postfix level;

That's just … silly

> we have amavisd-new 
> handle all of that via spamassassin. I'm hesitant to allow a single 
> blacklist to determine the fate of mail acceptance, especially when we 
> have a very low false negative rate with amavisd/SA. Essentially, we'd 
> rather throw hardware at the problem than potentially reject legit mail.

Really? How much legit mail hits zen's rbl (hint, the number rhymes with 
"hero").


-- 
'You don't think you've had enough, do you?' he said.  I KNOW WHEN I'VE
HAD ENOUGH.  'Everyone says that, though.  I KNOW WHEN EVERYONE'S HAD
ENOUGH. --Moving Pictures

Re: IDN domain name support

[LuKreme]

On 27-May-2010, at 13:36, Pat wrote:
> 
> we are not interested in
> experimental code and do not want to use a version of bind or postfix that 
> cannot
> be compiled to refuse IDNs.

If you refuse properly delegated IDNs then you are broken, pure and simple.

This is WHY punycode exists, as it requires no rewriting (or very little) of 
libraries to be UTF-8 clean.


-- 
There's nothing to do, so you just stay in bed [ah, poor thing] Why live
in the world when you can live in your head?

Re: IDN domain name support

[Victor Duchovni]

On Thu, May 27, 2010 at 03:36:19PM -0400, Pat wrote:

> ICANN did not really consider the security and portability of IDNs
> before permitting them.  The reasons for this are many, and speak
> poorly to ICANN's management structure.  It is important to remember
> that ICANN's action does not mean that end-users are prepared to accept
> mail from such domains, or that doing so would be secure, much less
> that operating systems, libraries, and applications are
> capable of dealing with IDNs safely.

However true any of the above may be, it is not Postfix related.

> Whether IDNs will ever be portable is a matter of debate.  Right now
> they are in early-alpha status i.e., not ready for production.  This
> might be OK for some DNS and SMTP implementations but for most production
> systems they pose too high of a risk.

The only place that IDNs are in any way interesting is in user-agents,
since that's where xn--foo-bar gets turned into something that a user
who can read the relevant glyphs can understand. Infrastructure (as
opposed to user-facing client software) is IDN agnostic, because IDN
domain names are just like any other ASCII domain name.

> Speaking only for myself, for the foreseeable future we are not interested in
> experimental code and do not want to use a version of bind or postfix
> that cannot be compiled to refuse IDNs.

There is no code in Postfix to support IDN, and nothing to re-compile.
IDN domains are just like non-IDN domains, and work out of the box.
If you absolutely want to reject IDN dns labels, just adjust your
access tables:

sender_access.pcre:
/@(\S+\.)*?xn--/REJECT No room for IDN domains on my soapbox

-- 
Viktor.

Re: which port to use for SSL/TLS?

[Greg A. Woods]

At Tue, 25 May 2010 16:00:36 -0400, Phil Howard  wrote:
Subject: Re: which port to use for SSL/TLS?
> 
> At this point I'm just not going to support SMTP wrapped/tunneled over
> SSL/TLS ... on any port.  But just in case something comes up where I
> have to support it, I do have the config for it in comments with port
> 465.  They won't get that until after they've heard "show me the RFC"
> and "Microsoft doesn't follow real standards" a couple times.

This might seem odd to some for me to say, but I really don't understand
why you're trying so vainly to be such a stickler for the so-called
"standards" in this case.

IANA's "port numbers" are more a Best Common Practice than a literal
standard.  You're free to provide whatever service you so wish to
provide on any port you please.  The published port assignments,
especially those in the 0-1023 range, i.e. the Well Known Ports, are
simply a guideline to help you to inter-operate with "unknown callers".
If your users are all known to you then they will all know which port to
use through prior arrangement.  By definition one could conclude that
all users of a service requiring authentication and authorization are in
fact "known callers".

Finally, since running SMTP through SSL was previously defined and
assigned a port number, then supporting legacy applications using this
protocol and port number is well within the boundaries of valid use.

The only really valid reason for _not_ providing SMTP through SSL, (aka
"ssmtp" or "smtps") on port 465 would be if you really had to support
the newly assigned "urd" (URL Rendesvous Directory for SSM) protocol for
_unknown_ callers also on port 465, and also on the exact same IP
address (or perhaps through the same NAT-based firewall if for some
stupid reason you've put your servers behind a NAT on some non-public IP
addresses).


> But IMAP and POP are enabled on a wrapped/tunneled SSL/TLS port (993
> and 995), since a standard does exist (but I'm not telling anyone but
> the other admin about it ... I'm promoting STARTTLS/STLS for
> everything).

Are you sure your soap-box is the most secure one to promote?

The only real reason why SMTPS was "deprecated" was solely because of
politics.  There was never any technical reason to deprecate SMTPS.  It
was done as a result of someone having the fool-headed idea to think
that since it is _possible_ to initiate TLS from within the SMTP
transaction, then that should be the _only_ way to do it.

Note that the original RFC 2487 even goes so far to suggest that
STARTTLS is less secure than SMTPS by noting an obvious MitM attack (and
suggesting only a relatively ludicrous work-around).  That RFC's author
gave the following contradictory excuse to IANA via e-mail in order to
cause the unilateral deprecation of SMTPS:  "The email community has
reached rough concensus that widespread use of such a port will be
harmful to the performance, interoperability and security of SMTP."

Note there are even further MitM weaknesses in the original STARTTLS
protocol as well, all of which are avoided entirely by SMTPS.
Indeed, SMTPS threatens the success of STARTTLS because it is more
secure than using STARTTLS.

So, one must ask one's self if STARTTLS was truly the best option for
SMTP, when why was it not so for every other protocol that could have
been similarly extended from within, including HTTP, IMAP, NNTP, FTP,
TELNET, IRC, and so on?  The whole idea of trying to support TLS as an
add-on or extension to an existing protocol and to do so by using an
"optional" in-band request, is entirely antithetical to the ideal of
using TLS to protect the _entire_ encapsulated protocol.

Finally remember that the deprecation of SMTPS was never done officially
or via any published standard.  It was done simply by fiat when Paul
Hoffman asked IANA on his own to deprecate SMTPS prior to the final
publication of his STARTTLS RFC 2487.  The language suggesting the
deprecation of SMTPS and reassignment of port 465 was then removed from
the STARTTLS draft and there was no opportunity for further discussion
through the RFC process.

Politics.

-- 
Greg A. Woods

+1 416 218-0098VE3TCP  RoboHack 
Planix, Inc.   Secrets of the Weird 


pgp2RPXRImcxn.pgp
Description: PGP signature

change return-path to custom value

[Razvan Cosma]

 Hi everyone,
I am trying to get message bounces/delays piped into a script while keeping
the user-visible From: header intact. To do this, I have asked the senders
to relay through me and include a header of the form X-bounces-to:
scriptal...@mydomain.com. In the postfix relay host I added
main.cf:
 header_checks = regexp:/etc/postfix/header_checks
header_checks:
 /^Return-Path: (.*)/REPLACE X-Original-Return-Path: $1
 /^X-bounces-to: (.*)/REPLACE Return-Path: $1
The log does say
 postfix/cleanup: replace: header X-bounces-to:
scriptal...@mydomain.comfrom somehost[1.2.3.4]; from=<
z...@domain1.com> to= proto=SMTP: Return-Path:
scriptal...@mydomain.com
which sounds a bit odd - is this a concatenation of several informations
from the message headers or some error on my part?

The messages do go out with the wrong return-path - the address used in the
MAIL FROM: line, in this case z...@domain1.com. My question would be: does
cleanup(8) do another replace of the headers just before the message leaves
the system? If so, can it be disabled?

Re: Spampd proxy bypassed by some mails

[mouss]

Jan-Kaspar Münnich a écrit :
> Hello,
> 
> I've setup Postfix 2.7.0 to relay all mails to the local proxy spampd:
> 
> smtp  inet  n   -   n   -   25  smtpd
> -o smtpd_proxy_filter=127.0.0.1:10025
> -o smtpd_proxy_options=speed_adjust
> 127.0.0.1:10026 inet n  -   n   -   -   smtpd
> -o smtpd_authorized_xforward_hosts=127.0.0.0/8
> -o smtpd_client_restrictions=
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> -o smtpd_data_restrictions=
> -o mynetworks=127.0.0.0/8
> -o receive_override_options=no_unknown_recipient_checks
> -o smtpd_client_connection_count_limit=25
> 
> This works well for ~10.000 mails a day, but not for one kind of spam that 
> occured first two weeks ago. It is always very similar (one line, just 
> varying URL and spam bot): http://pastebin.com/4arTzeRu
> 
> These mails are just delivered to the mailbox, without any other log entry. 
> Unfortunately it's not really possible to run Postfix in debug mode, since I 
> can't reproduce the problem and would have to wait for the next occurance.
> 
> It's not a big problem since there are max. 5 of these spams getting through 
> on the whole server per day. But I really want to investigate it and would be 
> happy if anybody had an idea.
> 
> Jan-Kaspar

check your spampd: as there any cases where it would pass mail without
checking it Example: wrong whitelisting mechanism. a common error in
spamassassin is to use whitelist_from (which is easily abused by sender
forgery).

didn't check all your samples, but as for hinet, if you "have no hope
from them", then firewall them:

# cat /etc/pf.conf
...
discard = "block drop quick"
...
table  persist file "/etc/pf/banned.net"
...
$discard from  label "banned"

# cat /etc/pf/banned.net
...
#59.112.0.0 - 59.127.255.255
59.112.0.0/12
#61.220.0.0 - 61.231.255.255
61.220.0.0/14
61.224.0.0/14
61.228.0.0/14
#111.240.0.0 - 111.255.255.255
111.240.0.0/12
#114.32.0.0 - 114.47.255.255
114.32.0.0/12
#118.160.0.0 - 118.167.255.255
118.160.0.0/13
#118.168.0.0 - 118.171.255.255
118.168.0.0/14
#122.120.0.0 - 122.127.255.255
122.120.0.0/13
#218.160.0.0 - 218.175.255.255
218.160.0.0/12
#220.128.0.0 - 220.143.255.255
220.128.0.0/12

Re: change return-path to custom value

[mouss]

Razvan Cosma a écrit :
>  Hi everyone,
> I am trying to get message bounces/delays piped into a script while
> keeping the user-visible From: header intact. To do this, I have asked
> the senders to relay through me and include a header of the form
> X-bounces-to: scriptal...@mydomain.com
> . In the postfix relay host I added
> main.cf :
>  header_checks = regexp:/etc/postfix/header_checks
> header_checks:
>  /^Return-Path: (.*)/REPLACE X-Original-Return-Path: $1
>  /^X-bounces-to: (.*)/REPLACE Return-Path: $1
> The log does say
>  postfix/cleanup: replace: header X-bounces-to: scriptal...@mydomain.com
>  from somehost[1.2.3.4];
> from=mailto:z...@domain1.com>> to= > proto=SMTP: Return-Path:
> scriptal...@mydomain.com 
> which sounds a bit odd - is this a concatenation of several informations
> from the message headers or some error on my part?
> 
> The messages do go out with the wrong return-path - the address used in
> the MAIL FROM: line, in this case z...@domain1.com
> . My question would be: does cleanup(8) do
> another replace of the headers just before the message leaves the
> system? If so, can it be disabled?
> 

You must understand the difference between the "envelope" and the
"headers". The MAIL FROM command specifies the _envelope_ sender. The
fact that this gets written into the Return-Path header is a good thing,
but it happens at delivery time (and it is optional. see the manpage of
"pipe"...).


to play with the sender address, use smtp generic maps. but better set
the correct sender address at the time the message is sent. users can do
"sendmail -f $sender...". This is better than relying on headers. and it
follows an old principle: fix problems near the source.

Re: change return-path to custom value

[Wietse Venema]

Razvan Cosma:
>  /^Return-Path: (.*)/REPLACE X-Original-Return-Path: $1
>  /^X-bounces-to: (.*)/REPLACE Return-Path: $1

The Return-Path: header DOES NOT CONTROL delivery of bounce messages.

Instead, bounce messages are sent to the envelope sender address
(the address in the MAIL FROM command).

Wietse

Re: Spampd proxy bypassed by some mails

[Jan-Kaspar Münnich]

On 28.05.2010, at 24:12, mouss wrote:

> check your spampd: as there any cases where it would pass mail without
> checking it Example: wrong whitelisting mechanism. a common error in
> spamassassin is to use whitelist_from (which is easily abused by sender
> forgery).

I'm sure it can't be a misconfiguration of spampd or Spamassassin, since 
Postfix just doesn't relay these mails to spampd, so the error must be at 
Posfix:

May 26 14:04:48 mail postfix/smtpd[18487]: connect from 
220-143-62-59.dynamic.hinet.net[220.143.62.59]
May 26 14:04:49 mail postfix/smtpd[18487]: setting up TLS connection from 
220-143-62-59.dynamic.hinet.net[220.143.62.59]
May 26 14:04:50 mail postfix/smtpd[18487]: Anonymous TLS connection established 
from 220-143-62-59.dynamic.hinet.net[220.143.62.59]: TLSv1 with cipher RC4-MD5 
(128/128 bits)
May 26 14:04:51 mail postfix/smtpd[18487]: CB46FD60008: 
client=220-143-62-59.dynamic.hinet.net[220.143.62.59]
May 26 14:04:53 mail postfix/cleanup[18188]: CB46FD60008: message-id=<>
May 26 14:04:53 mail postfix/qmgr[18055]: CB46FD60008: 
from=, size=717, nrcpt=1 (queue active)
May 26 14:04:53 mail postfix/virtual[18464]: CB46FD60008: to=, 
orig_to=, relay=virtual, delay=2.1, 
delays=2.1/0/0/0.01, dsn=2.0.0, status=sent (delivered to maildir)
May 26 14:04:53 mail postfix/qmgr[18055]: CB46FD60008: removed
May 26 14:04:54 mail postfix/smtpd[18487]: lost connection after RSET from 
220-143-62-59.dynamic.hinet.net[220.143.62.59]
May 26 14:04:54 mail postfix/smtpd[18487]: disconnect from 
220-143-62-59.dynamic.hinet.net[220.143.62.59]

> didn't check all your samples, but as for hinet, if you "have no hope
> from them", then firewall them:

Sure, I could block them with Postfix, a RBL would be enough. But I wonder why 
they are not relayed properly (It really happens only at exactly these messages 
[http://pastebin.com/4arTzeRu], less than at 1 of 100.000). After several hours 
of research there are only two possibilities: Either I made a weird mistake and 
have overseen something or there is a bug somewhere.

Jan-Kaspar

Re: Spampd proxy bypassed by some mails

[Wietse Venema]

Jan-Kaspar M?nnich:
> Hello,
> 
> I've setup Postfix 2.7.0 to relay all mails to the local proxy spampd:
> 
> smtp  inet  n   -   n   -   25  smtpd
> -o smtpd_proxy_filter=127.0.0.1:10025
> -o smtpd_proxy_options=speed_adjust
> 127.0.0.1:10026 inet n  -   n   -   -   smtpd
> -o smtpd_authorized_xforward_hosts=127.0.0.0/8
> -o smtpd_client_restrictions=
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> -o smtpd_data_restrictions=
> -o mynetworks=127.0.0.0/8
> -o receive_override_options=no_unknown_recipient_checks
> -o smtpd_client_connection_count_limit=25
> 
> This works well for ~10.000 mails a day, but not for one kind of
> spam that occured first two weeks ago. It is always very similar
> (one line, just varying URL and spam bot): http://pastebin.com/4arTzeRu

What is the output of

# grep smtpd /etc/postfix/master.cf
# find / -name master.cf

The pastebin logging does not prove that spam came in on this port 25.

Wietse

Re: Spampd proxy bypassed by some mails

[Jan-Kaspar Münnich]

On 28.05.2010, at 02:45, Wietse Venema wrote:

> The pastebin logging does not prove that spam came in on this port 25.

Thanks a lot, that was the hint!

I had recently misconfigured port 587. Now I changed it to:

587   inet  n   -   n   -   -   smtpd -o 
smtpd_client_restrictions=permit_sasl_authenticated,reject

That should be safe...

Jan-Kaspar