date:20110411

On Sun, Apr 10, 2011 at 12:46:03AM +1000, Voytek Eymont wrote:

> Apr 10 00:37:13 palm postfix/smtp[12024]: setting up TLS connection to
> gmail-smtp-in.l.google.com[7
> 4.125.127.27]:25
> 
> Apr 10 00:37:13 palm postfix/smtp[12024]: certificate verification failed
> for gmail-smtp-in.l.googl
> e.com[74.125.127.27]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax
> Secure Certificate Authority
> Apr 10 00:37:13 palm postfix/smtp[12024]: Untrusted TLS connection
> established to gmail-smtp-in.l.g
> oogle.com[74.125.127.27]:25: TLSv1 with cipher RC4-SHA (128/128 bits)

The Equifax root CA is not in your CAfile or installed (and "c_rehashed")
in your CApath/ directory.

-- 
Viktor.

Re: selective greylisting with a long delay

2011-04-11 Thread lst_hoe02


Zitat von "pf at alt-ctrl-del.org" :

Has anyone implemented or experimented with selectively greylisting  
specific networks, with a long delay? Let's say 4 hours...

If so, what are your results?

Background:
1. Greylisting seems to have lost much of its value, and I stopped  
using it about a year ago.
2. By using and monitoring the logs for hits against the fresh15  
list and scrutinizing .info domains, I have identified and blocked  
several dozen networks that seem to cater to snowshoe type spammers.  
This has worked out very well. I block all mail from their networks,  
and I get zero complaints (so far) of false positives. So I'm  
confident that the networks and ISPs I have blocked, are black hat  
networks and ISPs.


But there are a few edge cases that I'm not comfortable with  
blocking. These are usually large and established ISPs (two of which  
recently merged) that seem to have the same practices as the bad  
guys. But they host legit sites too. Even if 99% of the email from  
these networks is spam, I can't block that other 1%. All I can do is  
try my best to filter out the 99% of bad mail.


While monitoring my logs and watching these spammers move to the  
next IP every couple of hours, I notice that their sending IP  
usually gets listed in at least one RBL within about three hours of  
their first appearance in my logs. But by that time, they have  
usually moved to the next IP.


My thought on auto combating this is to use a CIDR list to kick  
these networks (and only these networks) over to a greylist policy  
that delays these emails for 4+ hours. By then, most of the bad IPs  
would be listed in one or more RBL and be blocked.


So, has anyone else already done something like this?


We have by default a somewhat long greylisting period (~40 minutes)  
and have experimented with even much longer periods some time ago. By  
raising the greylisting time above ~1hour there was no improvement and  
the "error" rate caused by misconfigured sender was increasing. I  
would guess that your legitim 1% sender in the spam networks would  
fall in the category of "misconfigured sender", because they don't  
care being included in the spam net. Because of this i doubt you could  
improve your filtering by very long greylisting period because you  
will cut of most of the remaining 1% anyway.


Regards

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Restricting ETRN?

On Fri, Apr 08, 2011 at 11:44:12PM -0500, Noel Jones wrote:

> On 4/8/2011 11:29 PM, email builder wrote:
>>
>> Or is this of no concern and/or does the junk command limit take care of 
>> it?
>
> If you have no use for ETRN just set
> smtpd_etrn_restrictions = reject
> or maybe better
> smtpd_etrn_restrictions = static:502
> and then forget about it.
>
> ETRN is not a particularly interesting attack/abuse vector with postfix.  
> Don't spend much time worrying about it.

The most effective way to disable ETRN is to set:

# Empty disables ETRN and eliminates fast-flush cache overhead.
fast_flush_domains =

The default is:

fast_flush_domains = $relay_domains

You should then set "smtpd_etrn_restrictions = reject", but there is little
harm at that point in leaving it on.

-- 
Viktor.

Re: use of smtp(d)_tls_CAfile with opportunistic TLS?

On Fri, Apr 08, 2011 at 11:09:00PM -0700, email builder wrote:

> I'm wondering about the usefulness of smtp(d)_tls_CAfile(path) when using 
> opportunistic encryption in both incoming and outgoing connections. The 
> TLS_README suggests that certificate and key files be left empty for 
> opportunistic smtp processes, but it doesn't talk specifically about 
> smtp_tls_CAfile(path).

For the SMTP server, you should NOT leave the cert file empty, as many
clients won't support aNULL ciphers. Rather, you need to set a self-signed
cert, if one of the usual CAs is not suitable.

For the SMTP server, since you probably won't ask for client certs, you
never need a CAfile or CApath.

For the SMTP client, indeed, generally, your key and cert should be set
empty. On the other hand, it is a good idea in most cases to have a CAfile
and/or CApath with a few trusted roots.

> Am I correct to infer that both smtp(d)_tls_CAfile settings only serve
> a purpose when you want to verify client/server certificates?
> If that's the case, why does the example at the bottom of TLS_README
> use both the CAfile settings with only opportunistic encryption?

This reduces log noise, and improves the audit trail.

> Our system seems to work without any CAfile/CApath settings under 
> opportunistic 
> encryption both incoming and outgoing. Is there a performance or security 
> difference between using them or not?

You should probably throw in a few trusted root CAs.

-- 
Viktor.

Re: migrating to new server ?

On Mon, Apr 11, 2011 at 04:07:57PM +1000, li...@sbt.net.au wrote:

> I'm migrating virtual mail domain/users to new Postfix server,
> new server setup and working, I'm altering MX to point to the new server;
> 
> I want the 'old' server to forward any new traffic over to the new server,
> last time what I used was static entry in main.cf like:
> 
> transport_maps = static:smtp:new.server.tld

The same can be achieved with:

default_transport = relay:new.example.com
relay_transport = relay:new.example.com
local_transport = relay:new.example.com
virtual_transport = relay:new.example.com

> that doesn't seem to be doing anything for me this time..?
> what do I need ?

It should work, but you provide no context or evidence. Did you
perform a "postfix reload"? The transport_maps setting is read
by "trivial-rewrite" just when it starts...

-- 
Viktor.

Re: rate limit per day

2011-04-11 Thread Simone Caruso

On 11/04/2011 10:09, Tom Kinghorn wrote:

>  Good morning List.
> 
> Is it possible to rate limit based on individual network ranges?

try http://postfwd.org/

-- 
Simone Caruso
IT Consultant

Re: smptd_client_restriction


On 4/11/2011 1:08 AM, mejaz wrote:

Hello,

Many thanks for your feedback it works for me after replacing
“hash” with “cidr” but after that whenever I was trying to
send emails to outside domains it says relay access denied
although the trusted IPs are listed in my network file.

Please help

Ejaz



Please don't top post.

Please show us "postconf -n" output, postfix logging of the 
unwanted behavior, and why you think that IP is in mynetworks.



  -- Noel Jones

stop sending email when concrete recipient detected

2011-04-11 Thread Jiri Vitek

Hi folks,

what is the best solution for discarding email to be sended/trasnfered
to all recipients when there is one concrete addres in to, cc bcc
fields.

i need that for functional testing of our e-shop, where we testing in
production environment. And we don't want to spam our clients with
"order created", "order completed" and other information mails.

so any tips how to achive this behavior are welcome.

thanks J.Vitek

Problem with how postfix chooses MX'es

2011-04-11 Thread Administrator Systemu


 Hello all!

I'm looking at logs of my postfix-2.6.6 and wonder how postfix chooses 
which MX it'll connect.

There is some "cool" configured domain simplusnet.pl:

simplusnet.pl.300INSOAplusmx1.polkomtel.com.pl. 
postmaster.plusgsm.pl. 2010122205 28800 7200 1209600 86400

simplusnet.pl.300INMX20 mx2.plusnet.pl.
simplusnet.pl.300INMX50 mx3.plusnet.pl.
simplusnet.pl.300INMX10 mx1.plusnet.pl.

mx1 & mx3 resolve to the same IP address, and permanently refuses 
connections to smtp port.

Works only mx2. And now going back to logs:

Apr 11 00:15:27 [postfix/smtpd] 77ECE33058: client=localhost[127.0.0.1]
Apr 11 00:15:27 [postfix/cleanup] 77ECE33058: 
message-id=<20110410221527.6C0C4330CE@...>
Apr 11 00:15:27 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 00:15:27 [postfix/smtp] 6C0C4330CE: to=<...@simplusnet.pl>, 
relay=127.0.0.1[127.0.0.1]:10025, delay=0.41, delays=0.32/0/0.04/0.06, 
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 77ECE33058)
Apr 11 00:15:27 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=0.07, delays=0.06/0/0.02/0, dsn=4.4.1, status=deferred 
(connect to mx3.plusnet.pl[212.2.120.79]:25: Connection refused)
Apr 11 00:24:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 00:24:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=550, delays=550/0.01/0.02/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 00:34:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 00:34:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=1150, delays=1150/0.02/0.01/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 00:54:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 00:54:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=2350, delays=2350/0/0.01/0, dsn=4.4.1, status=deferred 
(connect to mx3.plusnet.pl[212.2.120.79]:25: Connection refused)
Apr 11 01:34:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 01:34:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=4750, delays=4750/0.02/0.06/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 02:44:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 02:44:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=8950, delays=8950/0.01/0.01/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 03:54:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 03:54:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=13150, delays=13150/0.01/0.05/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 05:04:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 05:04:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=17350, delays=17350/0.01/0.02/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 05:04:37 [postfix/bounce] 77ECE33058: sender delay notification: 
B5FA4330CD
Apr 11 06:14:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 06:14:38 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=21551, delays=21550/0.01/0.05/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 07:24:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 07:24:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=25750, delays=25750/0.01/0.07/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 08:34:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 08:34:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=29950, delays=29950/0.01/0.06/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 09:44:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 09:44:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=34150, delays=34150/0.04/0.08/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection 
refused)
Apr 11 10:54:37 [postfix/qmgr] 77ECE33058: from=<...@...>, size=1229, 
nrcpt=1 (queue active)
Apr 11 10:54:38 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
relay=none, delay=38351, delays=38350/0.06/0.07/0, dsn=4.4.1, 
status=deferred (connect to mx3.plusnet.pl[212.2.12

Re: Address Rewrite Problem


On 4/10/2011 11:55 PM, Nasser Heidari wrote:

Anyone has any idea ?

Thanks for Your answer, Here is my postconf -n output:




Please don't top-post.

Please show us "postconf -n" output and non-comment entries 
from master.cf, along with logging demonstrating the problem.



  -- Noel Jones

Which is the best lookup table for postfix

2011-04-11 Thread kshitij mali

HI all ,

Which the best lookup for postfix databases from the following one :
mysql
ldap
hash-db
cdb

I want to migrate from qmail to postfix which would be having 1378 email
account



Regards,
Kshitij

Re: stop sending email when concrete recipient detected


On 4/11/2011 7:05 AM, Jiri Vitek wrote:

Hi folks,

what is the best solution for discarding email to be sended/trasnfered
to all recipients when there is one concrete addres in to, cc bcc
fields.

i need that for functional testing of our e-shop, where we testing in
production environment. And we don't want to spam our clients with
"order created", "order completed" and other information mails.

so any tips how to achive this behavior are welcome.

thanks J.Vitek




If the mail is submitted via SMTP, a check_recipient_access 
table matching the test recipient with either DISCARD or 
REDIRECT will affect all recipients of the message.


# main.cf
smtpd_delay_reject = yes
smtpd_sender_restrictions =
  check_recipient_access hash:/etc/postfix/test_recipient

# test_recipient
tar...@example.com  REDIRECT develo...@example.net



  -- Noel Jones

Re: Problem with how postfix chooses MX'es

On Mon, Apr 11, 2011 at 02:06:51PM +0200, Administrator Systemu wrote:

>  Hello all!
>
> I'm looking at logs of my postfix-2.6.6 and wonder how postfix chooses 
> which MX it'll connect.

Random DNS order, as perturbed by demand-caching of sessions. Log parsers
should look at lines without "conn_use=," when counting MX host
frequency, and should avoid counting multi-recipient messages as multiple
uses of the same MX.

> There is some "cool" configured domain simplusnet.pl:
>
> simplusnet.pl.300INMX10 mx1.plusnet.pl.
> simplusnet.pl.300INMX20 mx2.plusnet.pl.
> simplusnet.pl.300INMX50 mx3.plusnet.pl.

Mail deliveries will try mx1, but if that tempfails, mx2 or perhaps
mx3 may be tried in turn.

> mx1 & mx3 resolve to the same IP address, and permanently refuses 
> connections to smtp port.
>
> Works only mx2. And now going back to logs:
>
> Apr 11 00:15:27 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
> relay=none, delay=0.07, delays=0.06/0/0.02/0, dsn=4.4.1, status=deferred 
> (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection refused)

The connection to mx2 failed.

> Apr 11 00:24:37 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
> relay=none, delay=550, delays=550/0.01/0.02/0, dsn=4.4.1, status=deferred 
> (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection refused)

The connection to mx2 failed...

> Apr 11 13:14:48 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>, 
> relay=mx2.plusnet.pl[212.2.120.80]:25, delay=46761, 
> delays=46750/0.02/0.16/10, dsn=2.0.0, status=sent (250 OK 
> id=1Q9F4n-Hj-LU)

Finally, after almost a day of trying, the connection to mx2 worked.

> Heh after 15 tries and 13 hours mail is delivered. Why postfix uses mx3 so 
> many times?

Because mx2 is unreachable most of the time.

> And I have deliveries that not succeeded at all, because postfix was 
> connecting only to mx3 till delivery expired.

This is not the case. You are not looing at all pertinent log entries.

-- 
Viktor.

Re: Address Rewrite Problem

On Mon, Apr 11, 2011 at 07:07:49AM -0500, Noel Jones wrote:

> On 4/10/2011 11:55 PM, Nasser Heidari wrote:
>> Anyone has any idea ?
>>
>> Thanks for Your answer, Here is my postconf -n output:
>>
>>
>
> Please don't top-post.
>
> Please show us "postconf -n" output and non-comment entries from master.cf, 
> along with logging demonstrating the problem.

The OP has not yet asked a meaningful question. Just showing bunches
of configuration information with little indication of what the OP would
like help with won't help much.

-- 
Viktor.

Re: Which is the best lookup table for postfix

On Mon, Apr 11, 2011 at 05:39:09PM +0530, kshitij mali wrote:

> HI all ,
> 
> Which the best lookup for postfix databases from the following one :
>
> mysql
> ldap
> hash-db
> cdb

Use cdb when you want simple read-only, indexed files.
Use btree for Postfix dynamic caches (TLS session cache, verify database, ...)
Use LDAP when you need to query a corporate LDAP directory.
Use MySQL when you manage user accounts and mailboxes in MySQL.

-- 
Viktor.

Re: Problem with how postfix chooses MX'es

2011-04-11 Thread Administrator Systemu


 W dniu 11.04.2011 14:14, Victor Duchovni pisze:

Mail deliveries will try mx1, but if that tempfails, mx2 or perhaps
mx3 may be tried in turn.

mx1&  mx3 resolve to the same IP address, and permanently refuses
connections to smtp port.

Works only mx2. And now going back to logs:

Apr 11 00:15:27 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>,
relay=none, delay=0.07, delays=0.06/0/0.02/0, dsn=4.4.1, status=deferred
(connect to mx3.plusnet.pl[212.2.120.79]:25: Connection refused)

The connection to mx2 failed.


Do you mean that if there is "connect to 
mx3.plusnet.pl[212.2.120.79]:25: Connection refused",
it is evidence that postfix was trying before to connect to mx1 (which 
abvoiusly fails) and then mx2

(and it failed also)? o.0


Because mx2 is unreachable most of the time.


Haven't considered it, will watch to it closely...


This is not the case. You are not looing at all pertinent log entries.


Maybe, or you're smoking some weird stuff ;-)

Cheers,

--

Administrator Systemu
Fundacja "Opoka"
tel. 322308944

Re: Problem with how postfix chooses MX'es

Administrator Systemu:
[ Charset ISO-8859-1 unsupported, converting... ]
>   W dniu 11.04.2011 14:14, Victor Duchovni pisze:
> > Mail deliveries will try mx1, but if that tempfails, mx2 or perhaps
> > mx3 may be tried in turn.
> >> mx1&  mx3 resolve to the same IP address, and permanently refuses
> >> connections to smtp port.
> >>
> >> Works only mx2. And now going back to logs:
> >>
> >> Apr 11 00:15:27 [postfix/smtp] 77ECE33058: to=<...@simplusnet.pl>,
> >> relay=none, delay=0.07, delays=0.06/0/0.02/0, dsn=4.4.1, status=deferred
> >> (connect to mx3.plusnet.pl[212.2.120.79]:25: Connection refused)
> > The connection to mx2 failed.
> 
> Do you mean that if there is "connect to 
> mx3.plusnet.pl[212.2.120.79]:25: Connection refused",
> it is evidence that postfix was trying before to connect to mx1 (which 
> abvoiusly fails) and then mx2
> (and it failed also)? o.0
> 
> > Because mx2 is unreachable most of the time.
> 
> Haven't considered it, will watch to it closely...
> 
> > This is not the case. You are not looing at all pertinent log entries.
> 
> Maybe, or you're smoking some weird stuff ;-)

Please report output of:

grep 212.2.120.80 /the/maillog/file

Thanks.

Wietse

RE: smptd_client_restriction

2011-04-11 Thread Ejaz

Thanks a lot Jones. 

 

 

I am using /etc/postfix/mynetworks where I can list "trusted" network
addresses (IPADDRESS) is it? 

 

 

 

 

Postconf -n output

 

bounce_queue_lifetime = 1d

command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

debug_peer_level = 2

header_checks = regexp:/etc/postfix/header_checks

html_directory = no

inet_interfaces = all

mail_owner = postfix

mailq_path = /usr/bin/mailq

manpage_directory = /usr/local/man

maximal_queue_lifetime = 1d

message_size_limit = 20971520

mydomain = cyberia.net.sa

myhostname = mailgate5.cyberia.net.sa

newaliases_path = /usr/bin/newaliases

queue_directory = /var/spool/postfix

readme_directory = no

relay_domains = hash:/etc/postfix/relay_domains

sample_directory = /etc/postfix

sendmail_path = /usr/sbin/sendmail

setgid_group = postdrop

smtpd_banner = smtp.cyberia.net.sa

smtpd_client_restrictions = check_client_access hash:/etc/postfix/access,
check_client_access cidr:/etc/postfix/mynetworks, reject_rbl_client
bl.spamcop.vnet,zen.spamhaus.org

transport_maps = hash:/etc/postfix/transport

unknown_local_recipient_reject_code = 550

 

 

following Logs appear in /var/log/maillog

 

 

Apr 10 11:21:02 smtp2 postfix/smtpd[25385]: NOQUEUE: reject: RCPT from
unknown[212.119.65.13]: 554 5.7.1 : Relay access
denied; from= to= proto=ESMTP
helo=

 

Ejaz 

 

 

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones
Sent: Monday, April 11, 2011 3:05 PM
To: postfix-users@postfix.org
Subject: Re: smptd_client_restriction

 

On 4/11/2011 1:08 AM, mejaz wrote:

> Hello,

> 

> Many thanks for your feedback it works for me after replacing

> "hash" with "cidr" but after that whenever I was trying to

> send emails to outside domains it says relay access denied

> although the trusted IPs are listed in my network file.

> 

> Please help

> 

> Ejaz

 

 

Please don't top post.

 

Please show us "postconf -n" output, postfix logging of the 

unwanted behavior, and why you think that IP is in mynetworks.

 

 

   -- Noel Jones

 

 

-- 

This message has been scanned for viruses and

dangerous content by MailScanner, and is

believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

HowTo detect full quota on border MTA

2011-04-11 Thread Jiří Hlinka

Hello,
I've got border MTA (postfix + antispam) and MDA (postfix + dovecot) where
emails are delivered to. Users on MDA are limited by dovecot-based quota.

How can I pass information about "this user's quota is reached, do not
receive email for him and reject it with relevant 5xx message" to the border
MTA so I can reject emails for particular users with quota reached already
on a border MTA and dont cause a backscatters?

And one sub-question :) - how does postfix on MDA finds that particular user
has full mailbox and rejects emails for him? Does it count a file-system
mailbox size on every SMTP connection or does it have this information from
dovecout (ie via database or so)?

Thanks.

Best regards,
Jorge

Re: Address Rewrite Problem

2011-04-11 Thread DTNX/NGMX Postmaster

On 9 apr 2011, at 18:54, Nasser Heidari wrote:

> We have an Exchange for our local Emails and Exchange uses Postfix as
> Smarthost. 
> Address Rewriting is Working properly for Emails from Exchange to
> Outside network, but For Emails from Exchange to Postfix Virtually
> hosted Domains or Postfix Local Mailbox's the rules doesn't Affect ! 

If Exchange is not sending using the correct address, I would suggest solving 
this within Exchange. Add additional SMTP addresses to accounts within your 
Active Directory, and pick the right one as the primary address, which will 
then be used by Exchange for all outgoing mail. No rewriting logic required.

If that doesn't solve your issue, be more specific. See the previous responses 
by Noel and Victor.

Cya,
Jona

email delivery delay : fatal: shared lock active

2011-04-11 Thread Zozime Rakotondrazafy

Hello there,


We have been facing this problem for few weeks and could not find the right 
solution yet... One of our customers' system is experiencing a persistent email 
delivery delay (either for local or oustide recipients) and after making 
multiple changes to postfix settings, we keep on having the same error messages 
in the log: "fatal: shared lock active".


The system is a postfix/mailscanner/ldap box. We noticed that the problem comes 
from messages with more than one recipients.

Below is a trace of one message experiencing the delay problem.

Thank you for your help,

Zozime
-

Mar 30 07:51:30 mailserver MailScanner[11375]: New Batch: Scanning 1 messages, 
4005 bytes 
Mar 30 07:51:30 mailserver MailScanner[11375]: Requeue: C884C37B49.AE6DE to 
9978637B4A 

Mar 30 07:51:30 mailserver postfix/qmgr[27441]: 9978637B4A: 
from=, size=3153, nrcpt=3 (queue active)

Mar 30 07:51:30 mailserver postfix/local[24516]: fatal: shared lock 
active/9978637B4A: Resource temporarily unavailable
Mar 30 07:51:30 mailserver postfix/local[24519]: 9978637B4A: 
to=, relay=local, delay=0.26, 

delays=0.22/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to maildir)
Mar 30 07:51:30 mailserver postfix/local[26515]: 9978637B4A: 
to=, relay=local, delay=0.27, 

delays=0.22/0.01/0/0.04, dsn=2.0.0, status=sent (delivered to maildir)
Mar 30 07:51:31 mailserver postfix/qmgr[27441]: warning: private/local socket: 
malformed response
Mar 30 07:51:31 mailserver postfix/qmgr[27441]: warning: transport local 
failure -- see a previous warning/fatal/panic 

logfile record for the problem description
Mar 30 07:51:31 mailserver postfix/master[14638]: warning: process 
/usr/libexec/postfix/local pid 24516 exit status 1
Mar 30 07:51:31 mailserver postfix/error[26127]: 9978637B4A: 
to=, relay=none, delay=1.2, 

delays=0.22/1/0/0, dsn=4.3.0, status=deferred (unknown mail transport error)

Mar 30 07:58:38 mailserver postfix/qmgr[27441]: 9978637B4A: 
from=, size=3153, nrcpt=3 (queue active)

Mar 30 07:58:38 mailserver postfix/error[28929]: 9978637B4A: 
to=, relay=none, delay=429, 

delays=429/0.01/0/0, dsn=4.3.0, status=deferred (unknown mail transport error)

Mar 30 08:08:38 mailserver postfix/qmgr[27441]: 9978637B4A: 
from=, size=3153, nrcpt=3 (queue active)

Mar 30 08:28:38 mailserver postfix/qmgr[27441]: 9978637B4A: 
from=, size=3153, nrcpt=3 (queue active)

Mar 30 08:28:38 mailserver postfix/error[8535]: 9978637B4A: 
to=, relay=none, delay=2229, 

delays=2229/0.01/0/0, dsn=4.3.0, status=deferred (unknown mail transport error)

Mar 30 09:08:38 mailserver postfix/qmgr[27441]: 9978637B4A: 
from=, size=3153, nrcpt=3 (queue active)

Mar 30 09:08:38 mailserver postfix/error[25603]: 9978637B4A: 
to=, relay=none, delay=4629, 

delays=4629/0.01/0/0, dsn=4.3.0, status=deferred (unknown mail transport error)

Mar 30 09:26:13 mailserver postfix/qmgr[27441]: 9978637B4A: 
from=, size=3153, nrcpt=3 (queue active)

Mar 30 09:26:13 mailserver postfix/local[1821]: 9978637B4A: 
to=, relay=local, delay=5683, 

delays=5683/0.06/0/0.06, dsn=2.0.0, status=sent (delivered to maildir)

Mar 30 09:26:13 mailserver postfix/qmgr[27441]: 9978637B4A: removed

Re: email delivery delay : fatal: shared lock active

Zozime Rakotondrazafy:
> Hello there,
> 
> 
> We have been facing this problem for few weeks and could not find
> the right solution yet... One of our customers' system is experiencing
> a persistent email delivery delay (either for local or oustide
> recipients) and after making multiple changes to postfix settings,
> we keep on having the same error messages in the log: "fatal:
> shared lock active".

No, the error message is:

fatal: shared lock active/9978637B4A

Where active/9978637B4A is the relative pathname of the queue file.

> Mar 30 07:51:30 mailserver postfix/local[24516]: fatal: shared lock 
> active/9978637B4A: Resource temporarily unavailable
> Mar 30 07:51:30 mailserver postfix/local[24519]: 9978637B4A: 
> to=, relay=local, delay=0.26, 
> Mar 30 07:51:30 mailserver postfix/local[26515]: 9978637B4A: 
> to=, relay=local, delay=0.27, 

Process 26515 got a shared lock, process 24516 got no lock, and
process 24519 got a shared lock.

Check your kernel parameters.  Perhaps your OS has a very limited
number of locks available. This may be the result of very cheap
shared hosting.

Wietse

Re: qmgr warning


Wietse Venema wrote:

Randy Ramsdell:

Ralf Hildebrandt wrote:

* Ralf Hildebrandt :

* Randy Ramsdell :

Apr  8 10:10:30 atlbl6 postfix/qmgr[11959]: warning: connect to transport 
private/retry: Connection refused

grep retry /etc/postfix/master.cf

what do you see?

# grep retry /etc/postfix/master.cf
retry unix  -   -   -   -   -   error
should be the result

Thanks. That was it. It appears the upgrade dealing with the config 
files were not complete.


I recommend that you use  "postfix upgrade-configuration set-permissions"
just to be sure that there are no more surprises later.

Wietse


Argh, I ran postfix upgrade-configuration but not set-permissions. When 
I do add the set-permissions argument, there is an error for README_FILES.


postfix upgrade-configuration set-permissions
chown: cannot access `/usr/share/doc/packages/postfix/README_FILES': No 
such file or directory


locate README_FILES
/usr/share/doc/packages/postfix-doc/README_FILES/
...

rpm -qvf /usr/share/doc/packages/postfix-doc/README_FILES/
postfix-doc-2.7.2-12.3.noarch

Opensuse postfix-doc rpm writes the files to 
/usr/share/doc/packages/postfix-doc/README_FILES/. So the the rpm 
maintainer broke postfix a little. I suppose I could ln to 
/usr/share/doc/packages/postfix/README_FILES.


Does the command stop if it has errors or continue so that I can trust 
that this is the only permissions that were not changed?


Thanks,
RCR

Re: Sender access issue

2011-04-11 Thread Alex

Hi,

>> Apr 11 03:32:07 alex postfix/smtpd[2278]: NOQUEUE: reject: RCPT from
>> ut-tul-1.tul.getthere.net[151.193.164.249]: 450 4.1.8
>> : Sender address rejected: Domain not
>> found; from=  to=
>> proto=ESMTP helo=
>>
>> Would adding "st...@wl0.tul.getthere.net OK" to my sender_access map
>> permit this message to be delivered, even though the
>> wl0.tul.getthere.net domain doesn't exist? It doesn't seem to work. Is
>> there a better way to do this (outside of having them create a proper
>> DNS entry, of course)?
>
> Yes, that's the right format for a check_sender_access map.
>
> Sounds as if the mail is being rejected by reject_unknown_sender_domain.
>  Your check_sender_access whitelist needs to be before
>  reject_unknown_sender_domain in the same smtpd_*_restrictions section.

Okay, I've even put the sender_access map first and it is still
rejected. Below is the output from postconf:

alias_maps = hash:/etc/postfix/aliases
alternate_config_directories = /etc/postfix_f
bounce_queue_lifetime = $maximal_queue_lifetime
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = $myhostname, gambit.$mydomain
local_recipient_maps =
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
maximal_queue_lifetime = 50d
mydestination = $myhostname, localhost.$mydomain, gambit.$mydomain
mydomain = mydomain.com
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /etc/postfix/README_FILES
receive_override_options = no_address_mappings
relay_domains = $mydestination, mydomain1.com
sample_directory = /etc/postfix/samples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/sender_checks,reject_non_fqdn_sender,
reject_non_fqdn_recipient,reject_unknown_sender_domain,
reject_unknown_recipient_domain,reject_unauth_pipelining,
  permit_mynetworks,permit_sasl_authenticated,
reject_invalid_hostname,reject_non_fqdn_hostname,
reject_unauth_destination,check_recipient_access
pcre:/etc/postfix/recip_map,check_recipient_access
pcre:/etc/postfix/relay_recips_access,check_helo_access
hash:/etc/postfix/helo_checks,check_sender_access
hash:/etc/postfix/sender_checks,check_sender_access
hash:/etc/postfix/disallow_my_domain,check_client_access
hash:/etc/postfix/client_access,check_client_access
pcre:/etc/postfix/client_checks.pcre, reject_rbl_client
zen.spamhaus.org, reject_rbl_client bl.spamcop.net,permit
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /etc/postfix/sasl:/usr/lib/sasl2:/etc/sasl2
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = cyrus
smtpd_sender_restrictions = permit_sasl_authenticated,
permit_mynetworks,  reject_non_fqdn_sender,
reject_unknown_sender_domain,   reject_unauth_pipelining,   permit
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550

Thanks,
Alex

Re: qmgr warning

On Mon, Apr 11, 2011 at 10:02:47AM -0400, Randy Ramsdell wrote:

> Argh, I ran postfix upgrade-configuration but not set-permissions. When I 
> do add the set-permissions argument, there is an error for README_FILES.
>
> postfix upgrade-configuration set-permissions
> chown: cannot access `/usr/share/doc/packages/postfix/README_FILES': No 
> such file or directory
>
> locate README_FILES
> /usr/share/doc/packages/postfix-doc/README_FILES/
> ...
>
> rpm -qvf /usr/share/doc/packages/postfix-doc/README_FILES/
> postfix-doc-2.7.2-12.3.noarch
>
> Opensuse postfix-doc rpm writes the files to 
> /usr/share/doc/packages/postfix-doc/README_FILES/. So the the rpm 
> maintainer broke postfix a little. I suppose I could ln to 
> /usr/share/doc/packages/postfix/README_FILES.

No, just change "readme_directory" in /etc/postfix/main.cf. Also
update any other "installation parameters" that moved.

-- 
Viktor.

Re: Sender access issue

On Mon, Apr 11, 2011 at 10:18:34AM -0400, Alex wrote:

> > Sounds as if the mail is being rejected by reject_unknown_sender_domain.
> > ?Your check_sender_access whitelist needs to be before
> > ?reject_unknown_sender_domain in the same smtpd_*_restrictions section.
> 
> Okay, I've even put the sender_access map first and it is still
> rejected. Below is the output from postconf:

NEVER put sender whitelists first in smtpd_recipient_restrictions,
do put them after "reject_unauth_destination", but before any
sender-specific restrictions that require a whitelist.

> smtpd_recipient_restrictions =
>   # DO NOT DO THIS: Open Relay!
>   check_sender_access hash:/etc/postfix/sender_checks,
>   reject_non_fqdn_sender,
>   reject_non_fqdn_recipient,
>   reject_unknown_sender_domain,
>   reject_unknown_recipient_domain,
>   reject_unauth_pipelining,
>   permit_mynetworks,
>   permit_sasl_authenticated,
>   reject_invalid_hostname,
>   reject_non_fqdn_hostname,
>   reject_unauth_destination,
>   check_recipient_access pcre:/etc/postfix/recip_map,
>   check_recipient_access pcre:/etc/postfix/relay_recips_access,
>   check_helo_access hash:/etc/postfix/helo_checks,
>   check_sender_access hash:/etc/postfix/sender_checks,
>   check_sender_access hash:/etc/postfix/disallow_my_domain,
>   check_client_access hash:/etc/postfix/client_access,
>   check_client_access pcre:/etc/postfix/client_checks.pcre,
>   reject_rbl_client zen.spamhaus.org,
>   reject_rbl_client bl.spamcop.net,
>   permit
>
> smtpd_sender_restrictions =
>   permit_sasl_authenticated,
>   permit_mynetworks,
>   reject_non_fqdn_sender,
>   reject_unknown_sender_domain,
>   reject_unauth_pipelining,
>   permit

Remove the sender checks from the recipient restrictions, and apply
the whitelist in the sender checks.

-- 
Viktor.

Re: smptd_client_restriction


On 4/11/2011 7:37 AM, Ejaz wrote:

Thanks a lot Jones.

I am using /etc/postfix/mynetworks where I can list "trusted"
network addresses (IPADDRESS) is it?

*_Postconf –n output_*

bounce_queue_lifetime = 1d

command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

debug_peer_level = 2

header_checks = regexp:/etc/postfix/header_checks

html_directory = no

inet_interfaces = all

mail_owner = postfix

mailq_path = /usr/bin/mailq

manpage_directory = /usr/local/man

maximal_queue_lifetime = 1d

message_size_limit = 20971520

mydomain = cyberia.net.sa

myhostname = mailgate5.cyberia.net.sa

newaliases_path = /usr/bin/newaliases



mynetworks isn't listed here.


  -- Noel Jones

Re: stop sending email when concrete recipient detected

2011-04-11 Thread Jiri Vitek

that work like a charm. 

Thank you Noel

On Mon, 2011-04-11 at 07:14 -0500, Noel Jones wrote:
> On 4/11/2011 7:05 AM, Jiri Vitek wrote:
> > Hi folks,
> >
> > what is the best solution for discarding email to be sended/trasnfered
> > to all recipients when there is one concrete addres in to, cc bcc
> > fields.
> >
> > i need that for functional testing of our e-shop, where we testing in
> > production environment. And we don't want to spam our clients with
> > "order created", "order completed" and other information mails.
> >
> > so any tips how to achive this behavior are welcome.
> >
> > thanks J.Vitek
> >
> 
> 
> If the mail is submitted via SMTP, a check_recipient_access 
> table matching the test recipient with either DISCARD or 
> REDIRECT will affect all recipients of the message.
> 
> # main.cf
> smtpd_delay_reject = yes
> smtpd_sender_restrictions =
>check_recipient_access hash:/etc/postfix/test_recipient
> 
> # test_recipient
> tar...@example.com  REDIRECT develo...@example.net
> 
> 
> 
>-- Noel Jones

Re: qmgr warning


Victor Duchovni wrote:

On Mon, Apr 11, 2011 at 10:02:47AM -0400, Randy Ramsdell wrote:

Argh, I ran postfix upgrade-configuration but not set-permissions. When I 
do add the set-permissions argument, there is an error for README_FILES.


postfix upgrade-configuration set-permissions
chown: cannot access `/usr/share/doc/packages/postfix/README_FILES': No 
such file or directory


locate README_FILES
/usr/share/doc/packages/postfix-doc/README_FILES/
...

rpm -qvf /usr/share/doc/packages/postfix-doc/README_FILES/
postfix-doc-2.7.2-12.3.noarch

Opensuse postfix-doc rpm writes the files to 
/usr/share/doc/packages/postfix-doc/README_FILES/. So the the rpm 
maintainer broke postfix a little. I suppose I could ln to 
/usr/share/doc/packages/postfix/README_FILES.


No, just change "readme_directory" in /etc/postfix/main.cf. Also
update any other "installation parameters" that moved.



Okay this exits on each error.  I mean, it is functional however, each 
run continues to add additional problems. I fix one, the script exits 
for another problem, I fix the next, the script exits for another 
problem, etc...


Now I am on dict_mysql.so. So I stalled postfix-mysql, now exiting for 
pqsql.


Is there a way to edit a configuration so the program skips certain 
features? An argument maybe?


RCR

Re: qmgr warning

On Mon, Apr 11, 2011 at 10:54:57AM -0400, Randy Ramsdell wrote:

> Now I am on dict_mysql.so. So I stalled postfix-mysql, now exiting for 
> pqsql.
>
> Is there a way to edit a configuration so the program skips certain 
> features?

No, you need to fix all the problems. It seems that Postfix you are
installing is very different from the previously installed version,
I don't know whether Debian supports the upgrade path you have chosen,
and whether they upgrade the configuration files in the process or not.
In any case you're on the bleeding edge. It may be simplest to re-install
Postfix, then apply your customizations.

-- 
Viktor.

Re: qmgr warning


Victor Duchovni wrote:

On Mon, Apr 11, 2011 at 10:54:57AM -0400, Randy Ramsdell wrote:

Now I am on dict_mysql.so. So I stalled postfix-mysql, now exiting for 
pqsql.


Is there a way to edit a configuration so the program skips certain 
features?


No, you need to fix all the problems. It seems that Postfix you are
installing is very different from the previously installed version,
I don't know whether Debian supports the upgrade path you have chosen,
and whether they upgrade the configuration files in the process or not.
In any case you're on the bleeding edge. It may be simplest to re-install
Postfix, then apply your customizations.



It really is only related to the README, now pgsql ( opensuse has a 
seperate rpm for pgsql ) and mysql ( opensuse has a separate package for 
mysql ). It is all logical, but I don't want to install these rpm's 
because we don't use them. I will install postfix-pgsql and see if that 
is the last issue.

Message id not encircled with '<' and '>'. Bug in postfix logs?

2011-04-11 Thread Javier Amor Garcia


Hello,
 in my mail.log I have lines where the message-id is not encircled with 
'<' and '>'. This has broke my parsing scripts.


It seems that it only happens in the cleanup process. The messages-id 
hadn't domain portions.


In about one month, I had seen two examples of this problem.  I will 
show them just straight from the mail.log file:


mail.log.2:940:Mar 20 18:00:52 kif postfix/cleanup[15700]: 0097C3D8F3: 
message-id=5eade3eb1528ac2f59104cba582ef5e9


mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790: 
message-id=468a9c3f8b21b9d8fe7af2181f4ddd99


This is a bug?


Cheers,
  Javier

Re: Message id not encircled with '<' and '>'. Bug in postfix logs?

On Mon, Apr 11, 2011 at 05:17:22PM +0200, Javier Amor Garcia wrote:

> Hello,
>  in my mail.log I have lines where the message-id is not encircled with '<' 
> and '>'. This has broke my parsing scripts.
>
> It seems that it only happens in the cleanup process. The messages-id 
> hadn't domain portions.
>
> In about one month, I had seen two examples of this problem.  I will show 
> them just straight from the mail.log file:
>
> mail.log.2:940:Mar 20 18:00:52 kif postfix/cleanup[15700]: 0097C3D8F3: 
> message-id=5eade3eb1528ac2f59104cba582ef5e9
>
> mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790: 
> message-id=468a9c3f8b21b9d8fe7af2181f4ddd99
>
> This is a bug?

Postfix logs the content of the message-id header. Some messages are
more equal than others.

-- 
Viktor.

Re: Message id not encircled with '<' and '>'. Bug in postfix logs?

2011-04-11 Thread lst_hoe02


Zitat von Victor Duchovni :


On Mon, Apr 11, 2011 at 05:17:22PM +0200, Javier Amor Garcia wrote:


Hello,
 in my mail.log I have lines where the message-id is not encircled with '<'
and '>'. This has broke my parsing scripts.

It seems that it only happens in the cleanup process. The messages-id
hadn't domain portions.

In about one month, I had seen two examples of this problem.  I will show
them just straight from the mail.log file:

mail.log.2:940:Mar 20 18:00:52 kif postfix/cleanup[15700]: 0097C3D8F3:
message-id=5eade3eb1528ac2f59104cba582ef5e9

mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790:
message-id=468a9c3f8b21b9d8fe7af2181f4ddd99

This is a bug?


Postfix logs the content of the message-id header. Some messages are
more equal than others.


So it is a case of "shit in, shit out"??

Regards

Andreas






smime.p7s
Description: S/MIME Cryptographic Signature

Re: Message id not encircled with '<' and '>'. Bug in postfix logs?

On Mon, Apr 11, 2011 at 05:34:46PM +0200, lst_ho...@kwsoft.de wrote:

>> Postfix logs the content of the message-id header. Some messages are
>> more equal than others.
>
> So it is a case of "shit in, shit out"??

Postfix logs the content of the Message-Id header as received. To
determine whether a particular Message-Id header is valid, consult RFC
822/2822/5322, if not, complain to the sender. BOfH users can "IGNORE"
non-conformant Message-Id headers, and Postfix may (if suitably configure)
generate a new one that is conformant.

-- 
Viktor.

Re: qmgr warning


Randy Ramsdell wrote:

Victor Duchovni wrote:

On Mon, Apr 11, 2011 at 10:54:57AM -0400, Randy Ramsdell wrote:

Now I am on dict_mysql.so. So I stalled postfix-mysql, now exiting 
for pqsql.


Is there a way to edit a configuration so the program skips certain 
features?


No, you need to fix all the problems. It seems that Postfix you are
installing is very different from the previously installed version,
I don't know whether Debian supports the upgrade path you have chosen,
and whether they upgrade the configuration files in the process or not.
In any case you're on the bleeding edge. It may be simplest to re-install
Postfix, then apply your customizations.



It really is only related to the README, now pgsql ( opensuse has a 
seperate rpm for pgsql ) and mysql ( opensuse has a separate package for 
mysql ). It is all logical, but I don't want to install these rpm's 
because we don't use them. I will install postfix-pgsql and see if that 
is the last issue.


Okay every single man page, and there are MANY, is also causing an 
error. This are all related to opensuse's postfix-docs rpm which does 
not create sym links to the gzipped page.
The script looks for EX. postcat.1 which is postcat.1.gz . I also had to 
fix the man page location in main.cf. So far I am creating sym links to 
all these. argh. what a pita. I don't blame Posftix maintainers but 
rather the rpm creator. This isn't the first time opensuse rpm's are 
written poorly, but I am also not sure why the postfix upgrade command 
does not consider a gzipped file.


Why not wildcard the man page search? If the script sees anvil.8.gz, 
wouldn't that be enough confirmation that a reasonable assumption could 
be made that this is in fact the manpage for anvil.8?


Reinstalling will not fix the main page thing of course.

Re: Performance or delivery problems caused by "sleep"?

2011-04-11 Thread Steve Jenkins

On Friday, April 8, 2011, Stan Hoeppner  wrote:
> email builder put forth on 4/8/2011 10:14 PM:
>> Hello,
>>
>> I'm thinking about trying the example suggested in the documentation for
>> "sleep":
>>
>>
>> /etc/postfix/main.cf:
>> smtpd_client_restrictions =
>>         sleep 1, reject_unauth_pipelining
>> smtpd_delay_reject = no
>
> To achieve what goal?  Stopping bot spam?  There are much better methods
> available today.
>
>> In general, I try to order smtpd_*_restrictions with the least costly first, 
>> so
>
> Good habit.
>
>> this would be an exception.  Has "sleep" shown to be:
>>
>>   * effective?
>>   * cause performance issues?
>>   * cause any delivery problems?
>
> AIUI, this will delay every smtpd connection by 1 second.  Since each
> smtpd process can only process one transaction at a time, on a busy
> server you'll end up with lots of smtpd processes eating resources, and
> possibly mail delays if you reach the process limit of 100--incoming
> connections must wait for an smtpd to become available.  As to the
> effectiveness of sleep in combating bot spam, I have no idea as I've
> never tried it.
>
>> Or is this merely a poor-man's greylisting?
>
> In essence, yes.
>
>> Am I better off with a policy
>> server that can selectively implement a greylisting delay?
>
> No, you're better off using postscreen and or
> http://www.hardwarefreak.com/fqrdns.pcre instead of greylisting, which
> has its own set of performance and resource problems.
>
>> I'm using version 2.3.3
>
> You *need* to upgrade.  2.3.3 is ancient and no longer supported.  You
> need 2.8 to get access to postscreen.  fqrdns.pcre will work with any
> version containing pcre support.  I'm making an educated guess that
> you're using CentOS 5.5.  I believe the following is a binary rpm for
> rhel5 x86-64 (CentOS 5), which should be the package you need assuming
> you're running 64bit CentOS.
>
> http://ftp.wl0.org/official/2.8/RPMS-rhel5-x86_64/postfix-2.8.2-1.rhel5.x86_64.rpm
>
> This rpm is labeled "experimental" by Simon likely simply because it
> hasn't seen wide use yet.  If you want 2.8 and postscreen, this is
> likely the quickest way to get there.  Or you can download the source
> from postfix.org and build it yourself.

If you don't have a 64-bit system and/or want to upgrade using the
Postfix source, very easy instructions are here:

http://stevejenkins.com/blog/2011/01/building-postfix-2-8-on-rhel5-centos-5-from-source/

SteveJ

Re: qmgr warning

On Mon, Apr 11, 2011 at 11:49:00AM -0400, Randy Ramsdell wrote:

> Okay every single man page, and there are MANY, is also causing an error. 
> This are all related to opensuse's postfix-docs rpm which does not create 
> sym links to the gzipped page.

If they change the names of the installed files, they MUST change the
contents of the "postfix-files" included with the package. Failure to
do so is a broken package, complain loudly to the package maintainers.

> Why not wildcard the man page search? If the script sees anvil.8.gz, 
> wouldn't that be enough confirmation that a reasonable assumption could be 
> made that this is in fact the manpage for anvil.8?
>
> Reinstalling will not fix the main page thing of course.

Your binary package is borked, don't use it.

-- 
Viktor.

Re: What are the right users & groups to use for spampd & clamav when used with PostFix?

Hello Daniel

On Sun, 10 Apr 2011 22:19 -0400, "Daniel Bromberg" 
wrote:
> It's not that there's a magic formula, but ideally you just want to 
> apply the principle of Least Privilege and reason it out from there.

That was a good explanation.  I had been thinking that since PostFix is
designed to be the most secure of the bunch that using the 'postfix'
user for everything might have made some sense.

Your comments and some more reading showed me that I got it completely
backwards.

Thanks a bunch.

Jeremy Alsten

Re: Message id not encircled with '<' and '>'. Bug in postfix logs?

Javier Amor Garcia:
> mail.log.2:41222:Mar 24 12:49:45 kif postfix/cleanup[808]: EFA813D790: 
> message-id=468a9c3f8b21b9d8fe7af2181f4ddd99
> 
> This is a bug?

The system that created the Message-ID header does not comply
with the Internet email RFCs (RFC 5322 in this case).

If you were expecting that Postfix will turn random garbage
into RFC-compliant email, then that is not the case.

Wietse

SASL

2011-04-11 Thread Tolga


Hi,

I've been trying to follow http://www.postfix.org/SASL_README.html and 
trying to get it working, but I keep getting relay access denied. As far 
as I know, SASL AUTH works (I've tested). Can you help me? Below is my 
postconf -n output and relevant log.


postconf -n:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man/man1/
myhostname = mail.bilgisayarciniz.org
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = vmail
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
virtual_gid_maps = static:1001
virtual_mailbox_base = /srv/vmail
virtual_mailbox_domains = mysql:/etc/postfix/mysql-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
virtual_minimum_uid = 1
virtual_uid_maps = static:1001

mail.log:
[snip]
Apr 11 16:25:39 216235 postfix/smtpd[24241]: connect from 
unknown[193.255.135.1]
Apr 11 16:25:40 216235 postfix/smtpd[24241]: NOQUEUE: reject: RCPT from 
unknown[193.255.135.1]: 554 5.7.1 : Relay 
access denied; from= 
to= proto=ESMTP helo=
Apr 11 16:25:42 216235 postfix/smtpd[24241]: disconnect from 
unknown[193.255.135.1]


Regards,

Re: SASL

Tolga:
> mail.log:
> [snip]
> Apr 11 16:25:39 216235 postfix/smtpd[24241]: connect from 
> unknown[193.255.135.1]
> Apr 11 16:25:40 216235 postfix/smtpd[24241]: NOQUEUE: reject: RCPT from 
> unknown[193.255.135.1]: 554 5.7.1 : Relay 
> access denied; from= 
> to= proto=ESMTP helo=
> Apr 11 16:25:42 216235 postfix/smtpd[24241]: disconnect from 
> unknown[193.255.135.1]

As root, turn on debug logging for 193.255.135.1:

# postconf -e debug_peer_list=193.255.135.1
# postfix reload

Then, try again, and see if the client sends the "AUTH" command.
If it doesn't, then that is your problem.

PS The AUTH PLAIN and AUTH LOGIN commands don't encrypt the password
(it's just BASE64 encoded), so you don't want to post that.

Wietse

Re: qmgr warning


Victor Duchovni wrote:

On Mon, Apr 11, 2011 at 11:49:00AM -0400, Randy Ramsdell wrote:

Okay every single man page, and there are MANY, is also causing an error. 
This are all related to opensuse's postfix-docs rpm which does not create 
sym links to the gzipped page.


If they change the names of the installed files, they MUST change the
contents of the "postfix-files" included with the package. Failure to
do so is a broken package, complain loudly to the package maintainers.



Correction: The man pages are from the postfix rpm.

They did not change the man page names. It is common to use 
$manpage.1.gz. They simply compress the man page. I had to create links 
like postmap.1 ---> postmap.1.gz. Every manpage for every piece of 
software is in the for $manpage.1.gz. Agreed that the package maintainer 
could have created these links.


Why not wildcard the man page search? If the script sees anvil.8.gz, 
wouldn't that be enough confirmation that a reasonable assumption could be 
made that this is in fact the manpage for anvil.8?


Reinstalling will not fix the main page thing of course.


Your binary package is borked, don't use it.


What binary? I cannot maintain my own postfix rpms from opensuse. We 
need the security notification and patches. I suppose I could create our 
specific postfix rpms, but who has time.


Given it is an Opensuse problem, I still don't see why the postfix 
set-permissions cannot, use postmap.1* vs postmap.1 .

Re: qmgr warning

On Mon, Apr 11, 2011 at 12:43:38PM -0400, Randy Ramsdell wrote:

> Victor Duchovni wrote:
>> On Mon, Apr 11, 2011 at 11:49:00AM -0400, Randy Ramsdell wrote:
>>> Okay every single man page, and there are MANY, is also causing an error. 
>>> This are all related to opensuse's postfix-docs rpm which does not create 
>>> sym links to the gzipped page.
>> If they change the names of the installed files, they MUST change the
>> contents of the "postfix-files" included with the package. Failure to
>> do so is a broken package, complain loudly to the package maintainers.
>
> Correction: The man pages are from the postfix rpm.
>
> They did not change the man page names. It is common to use $manpage.1.gz. 

Yes, but if they ship manpage.gz files, then the "postfix-files" file
MUST list those and not files they don't ship. If you change the list
of delivered files, change the package manifest. It does not get much
easier...

> They simply compress the man page. I had to create links like postmap.1 
> ---> postmap.1.gz. Every manpage for every piece of software is in the for 
> $manpage.1.gz. Agreed that the package maintainer could have created these 
> links.

Or updated "postfix-files", if the links are not needed for the "man"
command to work.

>> Your binary package is borked, don't use it.
>
> Given it is an Opensuse problem, I still don't see why the postfix 
> set-permissions cannot, use postmap.1* vs postmap.1 .

That would be wrong. The manifest is supposed to be correct. Changing
the permissions of some random file is a really bad idea.

-- 
Viktor.

How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

Hello again.

I got postscreen working with content filtering and passing good mail
through.  I'm able to receive and send mail, and headers all look like
it seems they should. It's good to feel some progress even if just first
steps.

I learned that we really should have both a primary and a backup MX
assigned, and that they should be different IPs.

I have the spare IP, I assigned it to the backup, and set up the DNS for
it all.

As far as I can tell, there's no technical problem with having my one
server listen at both IP addresses.  May not be the best idea for the
long term, and we may need to set up a server on a second physical host
somewhere else.  I'll get to that later.

So now I have two IP addresses, each with its own hostname, and I want
to get the one server set up.  From what I'm reading you have to be
careful to get the right "response", banner and/or greeting, from the
right server.

It looks like I first get "teaser" banners set up for postscreen for
each of the MXs in master.cf with

 XX.XX.XX.1:smtp inet n - n - 1 postscreen
  -o postscreen_greet_banner="mail1.DOMAIN.COM ESMTP Postfix"
  -o smtpd_proxy_filter=127.0.0.1:10025
  -o smtpd_client_connection_count_limit=10
  -o smtpd_proxy_options=speed_adjust

 XX.XX.XX.2:smtp inet n - n - 1 postscreen
  -o postscreen_greet_banner="mail2.DOMAIN.COM ESMTP Postfix"
  -o smtpd_proxy_filter=127.0.0.1:10025
  -o smtpd_client_connection_count_limit=10
  -o smtpd_proxy_options=speed_adjust

 smtpd  pass  -   -   n   -   -   smtpd
 dnsblogunix  -   -   n   -   0   dnsblog
 tlsproxy   unix  -   -   n   -   0   tlsproxy
 ...


What I don't get is how I then get the right banner responses through
the next-step content filter (example for spampd based on
http://www.postfix.org/SMTPD_PROXY_README.html#config) to the "after
filter" SMTP server,

 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

I' don't think the postscreen_greet_banner gets "passed through", does
it?

I can sure put a smtpd banner option statement in there, but I believe I
need 2 banners, one for each MX server IP, primary and backup.

Is the right way here to launch TWO postscreen instances, TWO spampd
proxy instances, and TWO "after filter" instances, so that I have TWO
separate chains, each one with a greeting or banner of its own?

Jeremy Alsten

Re: SASL


On 4/11/2011 11:30 AM, Tolga wrote:

Hi,

I've been trying to follow
http://www.postfix.org/SASL_README.html and trying to get it
working, but I keep getting relay access denied. As far as I
know, SASL AUTH works (I've tested). Can you help me? Below is
my postconf -n output and relevant log.

postconf -n:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/lib/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man/man1/
myhostname = mail.bilgisayarciniz.org
mynetworks = 127.0.0.0/8
mynetworks_style = host
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = vmail
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot


You'll need something like

smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination

unless you've put modifications in master.cf you didn't show us.


tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = mysql:/etc/postfix/mysql-aliases.cf
virtual_gid_maps = static:1001
virtual_mailbox_base = /srv/vmail
virtual_mailbox_domains = mysql:/etc/postfix/mysql-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
virtual_minimum_uid = 1
virtual_uid_maps = static:1001




If your server passed the testing as outlined in 
http://www.postfix.org/SASL_README.html#server_test, then AUTH 
is likely working correctly.  Make sure you test from the same 
IP as the mail client (or some other external IP) to make sure 
there isn't some firewall issue.




mail.log:
[snip]
Apr 11 16:25:39 216235 postfix/smtpd[24241]: connect from
unknown[193.255.135.1]
Apr 11 16:25:40 216235 postfix/smtpd[24241]: NOQUEUE: reject:
RCPT from unknown[193.255.135.1]: 554 5.7.1
: Relay access denied;
from= to=
proto=ESMTP helo=
Apr 11 16:25:42 216235 postfix/smtpd[24241]: disconnect from
unknown[193.255.135.1]


There is no indication here that the client tried to login.
Postfix logs show "sasl_username=..." on successful login, or 
"authentication failed" on failure.  If neither is shown, then 
the client didn't attempt AUTH.




  -- Noel Jones

Re: qmgr warning


Victor Duchovni wrote:

On Mon, Apr 11, 2011 at 12:43:38PM -0400, Randy Ramsdell wrote:


Victor Duchovni wrote:

On Mon, Apr 11, 2011 at 11:49:00AM -0400, Randy Ramsdell wrote:
Okay every single man page, and there are MANY, is also causing an error. 
This are all related to opensuse's postfix-docs rpm which does not create 
sym links to the gzipped page.

If they change the names of the installed files, they MUST change the
contents of the "postfix-files" included with the package. Failure to
do so is a broken package, complain loudly to the package maintainers.

Correction: The man pages are from the postfix rpm.

They did not change the man page names. It is common to use $manpage.1.gz. 


Yes, but if they ship manpage.gz files, then the "postfix-files" file
MUST list those and not files they don't ship. If you change the list
of delivered files, change the package manifest. It does not get much
easier...



What is the "postfix-files" that list say postmap.1 vs. postmap.1.gz? 
Are you conveying that the postfix set-permissions uses some file that 
lists what man pages to look for?


They simply compress the man page. I had to create links like postmap.1 
---> postmap.1.gz. Every manpage for every piece of software is in the for 
$manpage.1.gz. Agreed that the package maintainer could have created these 
links.


Or updated "postfix-files", if the links are not needed for the "man"
command to work.


Of course the link is not needed.




Your binary package is borked, don't use it.
Given it is an Opensuse problem, I still don't see why the postfix 
set-permissions cannot, use postmap.1* vs postmap.1 .


That would be wrong. The manifest is supposed to be correct. Changing
the permissions of some random file is a really bad idea.



What manifest are you referring to? Is this an official file that I 
should look into or something you reference simply as a reference? I 
agree that the exact name is preferable, but postmap.1 vs. postmap.1.gz
? In fact every manpage on this server is of the form 
$manpage.$number.gz and strace shows "man" loading zlib libraries. So it 
is a builtin.

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

First, you can't run multiple postscreen daemons with the same
postscreen_cache_map setting, as that will corrupt the database.
I'm adding a check for this.

Second, to make postscreen listen on more than once address, list
all addresses in main.cf:

inet_interfaces = 1.2.3.4 1.2.3.5 127.0.0.1

Or perhaps easier:

inet_interfaces = all

which is the default.

Wietse

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

2011-04-11 Thread Michael Orlitzky

On 04/11/11 12:49, jeremy.als...@imap-mail.com wrote:
> 
> I learned that we really should have both a primary and a backup MX
> assigned, and that they should be different IPs.
> 

I'm going question this wisdom with the hope that it might save you some
pain. Why would it be better to have two MXes, especially if they're the
same box?

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

Hello Wietse

On Mon, 11 Apr 2011 13:16 -0400, "Wietse Venema" 
wrote:
> First, you can't run multiple postscreen daemons with the same
> postscreen_cache_map setting, as that will corrupt the database.
> I'm adding a check for this.
> 
> Second, to make postscreen listen on more than once address, list
> all addresses in main.cf:
> 
> inet_interfaces = 1.2.3.4 1.2.3.5 127.0.0.1

This step is nice and clear.  It's managed to confuse me more about my
original question, about getting the greetings and banners right.

I think I see now where "inet_interfaces = xx.xx.xx.1 xx.xx.xx.2
127.0.0.1" comes from,

"First, configure the host to listen on both primary and backup MX
addresses. Use the appropriate ifconfig command for the local operating
system, or update the appropriate configuration files and "refresh" the
network protocol stack.

Then, configure postscreen(8) to deny the temporary whitelist status on
the backup MX address(es). An example for Wietse's server is:

/etc/postfix/main.cf:
postscreen_whitelist_interfaces = !168.100.189.8 static:all
"

But it sounds like you're saying I should use only one postscreen daemon
defined in master.cf.  Is that right?

How do I do that and get different greetings on each IP it listens on?

Do I set the postscreen 'teaser' banner "=(empty)", and just specify the
smtpd_banner for each host?

I really just want one server, with one set of filter rules, but want it
to look to the outside like I have the two hosts.  Can I do it this way?
 If the answer's yes, I guess I got to get those banners right.

Thanks again.

Jeremy Alsten

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

jeremy.als...@imap-mail.com:
> How do I do that and get different greetings on each IP it listens on?

You do not need different banners on different IP addresses
when you implement the following:

MAIL EXCHANGER POLICY TESTS
   When  a  remote  SMTP  client  is  not  on  the  permanent access list,
   postscreen(8) can implement a  number  of  whitelist  tests  before  it
   grants  the  client  a  temporary whitelist status to talk to a Postfix
   SMTP server process.

   By listening on both primary and backup MX addresses, postscreen(8) can
   deny  the  temporary  whitelist  status to clients that connect only to
   backup MX hosts.

   postscreen_whitelist_interfaces (static:all)
  A list of local postscreen(8) server IP addresses where  a  non-
  whitelisted  SMTP  client  can  obtain postscreen(8)'s temporary
  whitelist status to talk to a Postfix SMTP server process.

If the above required different banners on different IP addresses,
then surely I would have mentioned this.

If the above required TWO postscreen daemons running on the same
host, then surely I would have mentioned this.

I could write thousands of lines of documentation about all the
things that you don't need to do.

Or you could just take the hint: if the docs don't say something
is required, then it really is not required.

Wietse

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

Hi Michael

On Mon, 11 Apr 2011 13:41 -0400, "Michael Orlitzky"
 wrote:
> On 04/11/11 12:49, jeremy.als...@imap-mail.com wrote:
> > 
> > I learned that we really should have both a primary and a backup MX
> > assigned, and that they should be different IPs.
> > 
> 
> I'm going question this wisdom with the hope that it might save you some
> pain. Why would it be better to have two MXes, especially if they're the
> same box?

There's no wisdom here, just what I've been told -- use a minimum of 2.

All of the examples that I see have at least two MX records.

One of the fellas at the user group who told us about PostFix wast
talking about best -practices and put up a slide about this

Symantec Brightmail Gateway (SBG) - Best Practices: New Deployments.
http://www.symantec.com/business/support/index?page=content&id=TECH122730&key=53991&actp=LIST

that says " You must have at least two MX records and then proper A and
PTR record for each host that will handle email."

If that's wrong, then like you said that saves me some pain.

Now that you mentioned it, I'm just looking at the SMTP RFC I found to
see if it says anything about it.

Thanks.

Jeremy Alsten

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

On Mon, 11 Apr 2011 14:02 -0400, "Wietse Venema" 
wrote:
> If the above required different banners on different IP addresses,
> then surely I would have mentioned this.
> 
> If the above required TWO postscreen daemons running on the same
> host, then surely I would have mentioned this.
> 
> I could write thousands of lines of documentation about all the
> things that you don't need to do.
> 
> Or you could just take the hint: if the docs don't say something
> is required, then it really is not required.

I'm sorry I thought this list was for new users too.

Everybody says take one step at a time.  Which I'm doing. I've been
doing as much reading as I can, and find a bunch of stuff confusing.  So
I try to ask nicely and thank folks for their time.

If you're gonna get ornery because I'm not as smart as an expert about
all this stuff this then I should really take the other hint too, and go
bark up a different tree.

Thanks again to everybody who was nice & helpful.  Good bye.

Jeremy Alsten

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

2011-04-11 Thread Michael Orlitzky

On 04/11/11 14:02, jeremy.als...@imap-mail.com wrote:
> Hi Michael
> 
> On Mon, 11 Apr 2011 13:41 -0400, "Michael Orlitzky"
>  wrote:
>> On 04/11/11 12:49, jeremy.als...@imap-mail.com wrote:
>>>
>>> I learned that we really should have both a primary and a backup MX
>>> assigned, and that they should be different IPs.
>>>
>>
>> I'm going question this wisdom with the hope that it might save you some
>> pain. Why would it be better to have two MXes, especially if they're the
>> same box?
> 
> There's no wisdom here, just what I've been told -- use a minimum of 2.
> 
> All of the examples that I see have at least two MX records.
> 
> One of the fellas at the user group who told us about PostFix wast
> talking about best -practices and put up a slide about this
> 
> Symantec Brightmail Gateway (SBG) - Best Practices: New Deployments.
> http://www.symantec.com/business/support/index?page=content&id=TECH122730&key=53991&actp=LIST
> 
> that says " You must have at least two MX records and then proper A and
> PTR record for each host that will handle email."
> 
> If that's wrong, then like you said that saves me some pain.
> 
> Now that you mentioned it, I'm just looking at the SMTP RFC I found to
> see if it says anything about it.

Unless anyone here would like to contradict me, ignore all that and just
use one.

The SBG document doesn't provide any rationale for me to argue against,
but I can't think of any reason why two would be better than one if they
both point to the same place.

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

jeremy.als...@imap-mail.com:
> 
> On Mon, 11 Apr 2011 14:02 -0400, "Wietse Venema" 
> wrote:
> > If the above required different banners on different IP addresses,
> > then surely I would have mentioned this.
> > 
> > If the above required TWO postscreen daemons running on the same
> > host, then surely I would have mentioned this.
> > 
> > I could write thousands of lines of documentation about all the
> > things that you don't need to do.
> > 
> > Or you could just take the hint: if the docs don't say something
> > is required, then it really is not required.
> 
> I'm sorry I thought this list was for new users too.
> 
> Everybody says take one step at a time.  Which I'm doing. I've been
> doing as much reading as I can, and find a bunch of stuff confusing.  So
> I try to ask nicely and thank folks for their time.
> 
> If you're gonna get ornery because I'm not as smart as an expert about
> all this stuff this then I should really take the other hint too, and go
> bark up a different tree.

I'm not trying to be rude (though I could be more diplomatic). It's
just sad to see someone spend so much effort on non-problems (chasing
mirages in the desert, as I called it recently).

If the goal is really implementing postscreen's MX policy enforcement,
then that definitely needs to wait until you have run a basic Postfix
installation for several weeks if not months.

Wietse

Re: qmgr warning

2011-04-11 Thread Dennis Guhl

On Mon, Apr 11, 2011 at 01:04:46PM -0400, Randy Ramsdell wrote:

[..]

> What is the "postfix-files" that list say postmap.1 vs.

If you take a peek at postfix.1 you will see a section FILES. There
you can find the files referenced in this man page, including the
postfix-files:

 $daemon_directory/postfix-files, file/directory permissions

With

 # postconf daemon_directory

you can find the path for $daemon_directory.

> postmap.1.gz? Are you conveying that the postfix set-permissions
> uses some file that lists what man pages to look for?

Dennis

[..]

Re: qmgr warning


Dennis Guhl wrote:

On Mon, Apr 11, 2011 at 01:04:46PM -0400, Randy Ramsdell wrote:

[..]


What is the "postfix-files" that list say postmap.1 vs.


If you take a peek at postfix.1 you will see a section FILES. There
you can find the files referenced in this man page, including the
postfix-files:

 $daemon_directory/postfix-files, file/directory permissions

With

 # postconf daemon_directory

you can find the path for $daemon_directory.


postmap.1.gz? Are you conveying that the postfix set-permissions
uses some file that lists what man pages to look for?


Dennis

[..]


Okay thanks for the glue. Odd though 
https://bugzilla.novell.com/show_bug.cgi?id=684302 shows that 
postfix-files is not part of the distribution yet is referenced. Maybe 
Matthias Andree's second comment regarding 11.4 does not need to include 
postfix-files since it is referenced using postfix set-permissions with 
Version: 2.7.2-12.3.

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

2011-04-11 Thread Rod Dorman

On Monday, April 11, 2011, 14:02:37, jeremy.als...@imap-mail.com wrote:
>   ...
> There's no wisdom here, just what I've been told -- use a minimum of 2.
> All of the examples that I see have at least two MX records.
> One of the fellas at the user group who told us about PostFix wast
> talking about best -practices and put up a slide about this
> Symantec Brightmail Gateway (SBG) - Best Practices: New Deployments.
> http://www.symantec.com/business/support/index?page=content&id=TECH122730&key=53991&actp=LIST
> that says " You must have at least two MX records and then proper A and
> PTR record for each host that will handle email."

The  intent  behind  this  suggestion  is redundancy so when one is down
because  of  hardware/network  issues  or  you're performing maintenance
there will be another box that can accept the mail.

If you only have one physical box you've severely limited that concept.

-- 
r...@polylogics.com "The avalanche has already started, it is too
Rod Dorman  late for the pebbles to vote." - Ambassador Kosh

Re: How to manage 2 banners/greetings through postscreen, content filter, and after-filter SMTP on 1 server?

2011-04-11 Thread Michael Orlitzky

On 04/11/11 15:29, Rod Dorman wrote:
> On Monday, April 11, 2011, 14:02:37, jeremy.als...@imap-mail.com wrote:
>>   ...
>> There's no wisdom here, just what I've been told -- use a minimum of 2.
>> All of the examples that I see have at least two MX records.
>> One of the fellas at the user group who told us about PostFix wast
>> talking about best -practices and put up a slide about this
>> Symantec Brightmail Gateway (SBG) - Best Practices: New Deployments.
>> http://www.symantec.com/business/support/index?page=content&id=TECH122730&key=53991&actp=LIST
>> that says " You must have at least two MX records and then proper A and
>> PTR record for each host that will handle email."
> 
> The  intent  behind  this  suggestion  is redundancy so when one is down
> because  of  hardware/network  issues  or  you're performing maintenance
> there will be another box that can accept the mail.
> 
> If you only have one physical box you've severely limited that concept.
> 

Our one MX can never be "down," only "interactive greylisting."

Re: SASL

2011-04-11 Thread Tolga




11-04-2011 19:41, Wietse Venema yazmış:

Tolga:

mail.log:
[snip]
Apr 11 16:25:39 216235 postfix/smtpd[24241]: connect from
unknown[193.255.135.1]
Apr 11 16:25:40 216235 postfix/smtpd[24241]: NOQUEUE: reject: RCPT from
unknown[193.255.135.1]: 554 5.7.1: Relay
access denied; from=
to=  proto=ESMTP helo=
Apr 11 16:25:42 216235 postfix/smtpd[24241]: disconnect from
unknown[193.255.135.1]

As root, turn on debug logging for 193.255.135.1:

# postconf -e debug_peer_list=193.255.135.1
# postfix reload

Then, try again, and see if the client sends the "AUTH" command.
If it doesn't, then that is your problem.

PS The AUTH PLAIN and AUTH LOGIN commands don't encrypt the password
(it's just BASE64 encoded), so you don't want to post that.

Wietse
Apr 11 20:11:18 216235 postfix/smtpd[25666]: warning: 212.253.85.253: 
address not listed for hostname kunduz.org
Apr 11 20:11:18 216235 postfix/smtpd[25666]: connect from 
unknown[212.253.85.253]
Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_hostname: unknown ~? 
127.0.0.0/8
Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_hostaddr: 
212.253.85.253 ~? 127.0.0.0/8
Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_list_match: unknown: 
no match
Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_list_match: 
212.253.85.253: no match

Apr 11 20:11:18 216235 postfix/smtpd[25666]: send attr request = connect
Apr 11 20:11:18 216235 postfix/smtpd[25666]: send attr ident = 
submission:212.253.85.253
Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
attribute: status

Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: status
Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute value: 0
Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
attribute: count

Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: count
Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute value: 1
Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
attribute: rate

Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: rate
Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute value: 1
Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
attribute: (list terminator)

Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: (end)
Apr 11 20:11:18 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
220 mail.bilgisayarciniz.org ESMTP Postfix (2.7.0)
Apr 11 20:11:18 216235 postfix/smtpd[25666]: 
xsasl_dovecot_server_create: SASL service=smtp, realm=(null)

Apr 11 20:11:18 216235 postfix/smtpd[25666]: name_mask: noanonymous
Apr 11 20:11:18 216235 postfix/smtpd[25666]: 
xsasl_dovecot_server_mech_filter: keep mechanism: PLAIN

Apr 11 20:11:18 216235 postfix/smtpd[25666]: watchdog_pat: 0xb895e020
Apr 11 20:11:19 216235 postfix/smtpd[25666]: < unknown[212.253.85.253]: 
EHLO [192.168.2.2]
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-mail.bilgisayarciniz.org
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-PIPELINING
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-SIZE 1024
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-VRFY
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-ETRN
Apr 11 20:11:19 216235 postfix/smtpd[25666]: match_list_match: unknown: 
no match
Apr 11 20:11:19 216235 postfix/smtpd[25666]: match_list_match: 
212.253.85.253: no match
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-AUTH PLAIN
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-ENHANCEDSTATUSCODES
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250-8BITMIME
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
250 DSN

Apr 11 20:11:19 216235 postfix/smtpd[25666]: watchdog_pat: 0xb895e020
Apr 11 20:11:19 216235 postfix/smtpd[25666]: < unknown[212.253.85.253]: 
AUTH PLAIN AGJpbGdpQGJpbGdpc2F5YXJjaW5pei5vcmcAYmlsZ2k5ODc=
Apr 11 20:11:19 216235 postfix/smtpd[25666]: xsasl_dovecot_server_first: 
sasl_method PLAIN, init_response 
AGJpbGdpQGJpbGdpc2F5YXJjaW5pei5vcmcAYmlsZ2k5ODc=
Apr 11 20:11:19 216235 postfix/smtpd[25666]: xsasl_dovecot_handle_reply: 
auth reply: OK?2?user=bi...@bilgisayarciniz.org
Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
235 2.7.0 Authentication successful

Apr 11 20:11:19 216235 postfix/smtpd[25666]: watchdog_pat: 0xb895e020
Apr 11 20:11:19 216235 postfix/smtpd[25666]: < unknown[212.253.85.253]: 
MAIL FROM: SIZE=427
Apr 11 20:11:19 216235 postfix/smtpd[25666]: extract_addr: input: 

Apr 11 20:11:19 216235 postfix/smtpd[25666]: smtpd_check_addr: 
addr=bi...@bilgisayarciniz.org
Apr 11 20:11:19 216235 postfix/smtpd[25666]: ctable_locate: move 
existing entry key bi...@bilgisayarciniz.org
Apr 11 20:11:19 216235 postfix/smtpd[25666]: extract_addr: in: 
, result: bi...@bilgisayarciniz.org
Apr 11 20:1

Re: SASL

2011-04-11 Thread Tolga




11-04-2011 19:59, Noel Jones yazmış:

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination 


It worked, thanks a lot Noel :)
Regards,
Tolga

Re: Message id not encircled with '<' and '>'. Bug in postfix logs?

2011-04-11 Thread Javier Amor Garcia


Thanks for the answer. Things are clearer now.




message-id=468a9c3f8b21b9d8fe7af2181f4ddd99

This is a bug?


Postfix logs the content of the message-id header. Some messages are
more equal than others.

Re: SASL

2011-04-11 Thread Steve

 Original-Nachricht 
> Datum: Mon, 11 Apr 2011 23:14:10 +0300
> Von: Tolga 
> An: Postfix users 
> Betreff: Re: SASL

> 
> 
> 11-04-2011 19:41, Wietse Venema yazmış:
> > Tolga:
> >> mail.log:
> >> [snip]
> >> Apr 11 16:25:39 216235 postfix/smtpd[24241]: connect from
> >> unknown[193.255.135.1]
> >> Apr 11 16:25:40 216235 postfix/smtpd[24241]: NOQUEUE: reject: RCPT from
> >> unknown[193.255.135.1]: 554 5.7.1: Relay
> >> access denied; from=
> >> to=  proto=ESMTP
> helo=
> >> Apr 11 16:25:42 216235 postfix/smtpd[24241]: disconnect from
> >> unknown[193.255.135.1]
> > As root, turn on debug logging for 193.255.135.1:
> >
> > # postconf -e debug_peer_list=193.255.135.1
> > # postfix reload
> >
> > Then, try again, and see if the client sends the "AUTH" command.
> > If it doesn't, then that is your problem.
> >
> > PS The AUTH PLAIN and AUTH LOGIN commands don't encrypt the password
> > (it's just BASE64 encoded), so you don't want to post that.
> >
You should listen to such kind of advices. To illustrate that it is easy to 
decode your password, here the whole thing in clear text:

username: bi...@bilgisayarciniz.org
password: bilgi987


Please go and change that!


> > Wietse
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: warning: 212.253.85.253: 
> address not listed for hostname kunduz.org
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: connect from 
> unknown[212.253.85.253]
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_hostname: unknown ~? 
> 127.0.0.0/8
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_hostaddr: 
> 212.253.85.253 ~? 127.0.0.0/8
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_list_match: unknown: 
> no match
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: match_list_match: 
> 212.253.85.253: no match
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: send attr request = connect
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: send attr ident = 
> submission:212.253.85.253
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
> attribute: status
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: status
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute value: 0
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
> attribute: count
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: count
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute value: 1
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
> attribute: rate
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: rate
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute value: 1
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: private/anvil: wanted 
> attribute: (list terminator)
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: input attribute name: (end)
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 220 mail.bilgisayarciniz.org ESMTP Postfix (2.7.0)
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: 
> xsasl_dovecot_server_create: SASL service=smtp, realm=(null)
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: name_mask: noanonymous
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: 
> xsasl_dovecot_server_mech_filter: keep mechanism: PLAIN
> Apr 11 20:11:18 216235 postfix/smtpd[25666]: watchdog_pat: 0xb895e020
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: < unknown[212.253.85.253]: 
> EHLO [192.168.2.2]
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-mail.bilgisayarciniz.org
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-PIPELINING
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-SIZE 1024
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-VRFY
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-ETRN
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: match_list_match: unknown: 
> no match
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: match_list_match: 
> 212.253.85.253: no match
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-AUTH PLAIN
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-ENHANCEDSTATUSCODES
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250-8BITMIME
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]: 
> 250 DSN
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: watchdog_pat: 0xb895e020
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: < unknown[212.253.85.253]: 
> AUTH PLAIN AGJpbGdpQGJpbGdpc2F5YXJjaW5pei5vcmcAYmlsZ2k5ODc=
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: xsasl_dovecot_server_first: 
> sasl_method PLAIN, init_response 
> AGJpbGdpQGJpbGdpc2F5YXJjaW5pei5vcmcAYmlsZ2k5ODc=
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: xsasl_dovecot_handle_reply: 
> auth reply: OK?2?user=bi...@bilgisayarciniz.org
> Apr 11 20:11:19 216235 postfix/smtpd[25666]: > unknown[212.253.85.253]

Re: selective greylisting with a long delay

pf at alt-ctrl-del.org put forth on 4/10/2011 10:33 PM:

> My thought on auto combating this is to use a CIDR list to kick these
> networks (and only these networks) over to a greylist policy that delays
> these emails for 4+ hours. By then, most of the bad IPs would be listed
> in one or more RBL and be blocked.
> 
> So, has anyone else already done something like this?

Why bother with this complex greylisting setup?  Simply hammer the big
blocks with a CIDR entry and whitelist individual IPs in the range from
which you need legit mail.  If such IPs are used to send both snowshoe
spam and ham, that's a human shield tactic, and deserves permanent
blocking, FOREVER.  If anyone complains, lay the full skinny on them as
to why.  I.e. lay the blame at the proper feet, and direct complaints at
the guilty.

Life is too short to waste _your_ valuable time playing whack-a-mole
with spammers, isn't it?  We don't live in a totally "collateral damage
free" world.  People must get used to this.

-- 
Stan

SASL Authentication and debugging..

2011-04-11 Thread Simon Brereton

Hi

Probably not the best place for this, but hopefully someone will tell me what 
I'm doing wrong anyway..

I've gotten the TLS up and working.  And SASL auth seemed to be working.  I 
installed saslfinger and everything was fine there.  But when trying to locally 
inject mail on the submission port, I get:

Apr 11 20:31:10 jonty postfix/smtpd[28787]: setting up TLS connection from 
localhost[127.0.0.1]
Apr 11 20:31:10 jonty postfix/smtpd[28787]: Anonymous TLS connection 
established from localhost[127.0.0.1]: TLSv1 with cipher DHE-RSA-AES256-SHA 
(256/256 bits)
Apr 11 20:31:10 jonty postfix/smtpd[28787]: warning: localhost[127.0.0.1]: SASL 
LOGIN authentication failed: authentication failure
Apr 11 20:31:10 jonty postfix/smtpd[28787]: disconnect from localhost[127.0.0.1]

I turned the verbosity up in smtpd.conf to try and diagnose this, and it does 
nothing (which I guess is my biggest issue).

  1 # Global Parameters
  2 log_level: 7
  3 pwcheck_method: auxprop
  4 #pwcheck_method: saslauthd
  5 mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5
  6 #mech_list: PLAIN LOGIN
  7 allow_plaintext: true
  8 # saslauthd Parameters
  9 #saslauthd_path: /var/state/saslauthd/mux
 10 saslauthd_path: /var/spool/postfix/var/run/saslauthd/mux
 11 # Auxiliary Plugin Paramters
 12 auxprop_plugin: sql
 13 sql_engine: mysql
 14 #sql_hostnames: 127.0.0.1
 15 sql_hostnames: localhost
 16 sql_user: postfix
 17 sql_passwd: 804LCi
 18 sql_database: Mail
 19 sql_select: select Password from MailAccounts where Username = '%u@%r';
 20 # or Username = '%u@%r' or (Username = '%u' and ForwardAdd = '') or 
Username = '%u.%r';
 21 sql_usessl: no

Saslfinger -s says:


-- active SMTP AUTH and TLS parameters for smtpd --
broken_sasl_auth_clients = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /root/certauth/cacert.pem
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/mail.cert
smtpd_tls_key_file = /etc/postfix/ssl/mail.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes

How can I increase the SASL logging to debug this?

Thanks.

Simon

Re: selective greylisting with a long delay

2011-04-11 Thread Jerry

On Mon, 11 Apr 2011 15:43:09 -0500
Stan Hoeppner  articulated:

> pf at alt-ctrl-del.org put forth on 4/10/2011 10:33 PM:
> 
> > My thought on auto combating this is to use a CIDR list to kick
> > these networks (and only these networks) over to a greylist policy
> > that delays these emails for 4+ hours. By then, most of the bad IPs
> > would be listed in one or more RBL and be blocked.
> > 
> > So, has anyone else already done something like this?
> 
> Why bother with this complex greylisting setup?  Simply hammer the big
> blocks with a CIDR entry and whitelist individual IPs in the range
> from which you need legit mail.  If such IPs are used to send both
> snowshoe spam and ham, that's a human shield tactic, and deserves
> permanent blocking, FOREVER.  If anyone complains, lay the full
> skinny on them as to why.  I.e. lay the blame at the proper feet, and
> direct complaints at the guilty.
> 
> Life is too short to waste _your_ valuable time playing whack-a-mole
> with spammers, isn't it?  We don't live in a totally "collateral
> damage free" world.  People must get used to this.

Unless of course you get hit with a law suit.

-- 
Jerry ✌
postfix-u...@seibercom.net
_
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Filtering spam received from multiple users

2011-04-11 Thread Jose Hales-Garcia


Hello,

I've recently been getting spam that has the first received header filled in 
with multiple users.  This is an example.

Received: from  79.14.233.16 (account ,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
 HELO domain)
by domain (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 107437582 for ; Mon, 11 Apr 2011 10:19:10 
+0100

My first idea for handling these messages is writing a filter in header_checks 
using regexp.  Is this the best approach to take using Postfix 2.4.3?

Below are my main.cf settings that I think are relevant.

Jose

header_checks = regexp:/etc/postfix/header_checks
strict_rfc821_envelopes = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_sender_restrictions =
smtpd_helo_restrictions =
  permit_mynetworks,
  reject_non_fqdn_helo_hostname,
  reject_invalid_helo_hostname,
  check_helo_access hash:/etc/postfix/helo_access,
  permit
smtpd_client_restrictions =
smtpd_recipient_restrictions =
  permit_mynetworks,
  permit_sasl_authenticated,
  reject_unauth_destination,
  reject_non_fqdn_hostname,
  reject_invalid_hostname,
  reject_unauth_pipelining,
  reject_non_fqdn_sender,
  reject_unknown_sender_domain,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  check_client_access hash:/etc/postfix/client_access,
  check_sender_access hash:/etc/postfix/sender_access,
  check_recipient_access hash:/etc/postfix/recipient_access,
  reject_rbl_client zen.spamhaus.org,
  permit

/etc/postfix/helo_access
domain  REJECT  fraudulent identity
mailserver.domain   REJECT  fraudulent identity
mailserver.ip_addr  REJECT  fraudulent identity
...
Jose Hales-Garcia
UCLA Department of Statistics
jose.halesgar...@stat.ucla.edu

minor postscreen cleanup logging issue

2011-04-11 Thread Peter Schultze


Hello,

using postfix 2.8.2 under Solaris 10 with
postscreen_cache_map = dbm:$data_directory/verify_cache

it appears that cache cleanup logging gives erratic numbers of retained entries,
ranging between 1875 and as high as 727916:

Apr  3 11:32:25  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=1875 dropped=59 entries
Apr  3 23:32:58  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=468417 dropped=693 entries
Apr  4 11:33:13  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=238015 dropped=1087 entries
Apr  4 23:33:43  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=404255 dropped=207 entries
Apr  5 11:34:08  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=357344 dropped=1094 entries
Apr  5 23:34:09  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=10043 dropped=278 entries
Apr  6 11:34:24  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=235581 dropped=1393 entries
Apr  6 23:34:52  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=389771 dropped=839 entries
Apr  7 11:35:41  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=668060 dropped=546 entries
Apr  7 23:36:23  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=569135 dropped=903 entries
Apr  8 11:36:41  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=259013 dropped=1148 entries
Apr  8 23:36:59  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=252607 dropped=832 entries
Apr  9 11:37:08  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=117216 dropped=677 entries
Apr  9 23:38:02  postfix/postscreen[760]: [ID 197553 mail.info] cache 
/var/lib/postfix/verify_cache full cleanup: retained=727916 dropped=492 entries


The actual number of cache entries on this system is around 25000:

# postmap -s /var/lib/postfix/verify_cache | wc -l
   24436

Otherwise postscreen is working well, so if this is a bug it would only be 
minor.

--
Peter Schultze

Re: selective greylisting with a long delay

2011-04-11 Thread John Peach

On Mon, 11 Apr 2011 17:39:43 -0400
Jerry  wrote:

> On Mon, 11 Apr 2011 15:43:09 -0500
> Stan Hoeppner  articulated:
> 
> > pf at alt-ctrl-del.org put forth on 4/10/2011 10:33 PM:
> > 
> > > My thought on auto combating this is to use a CIDR list to kick
> > > these networks (and only these networks) over to a greylist policy
> > > that delays these emails for 4+ hours. By then, most of the bad IPs
> > > would be listed in one or more RBL and be blocked.
> > > 
> > > So, has anyone else already done something like this?
> > 
> > Why bother with this complex greylisting setup?  Simply hammer the big
> > blocks with a CIDR entry and whitelist individual IPs in the range
> > from which you need legit mail.  If such IPs are used to send both
> > snowshoe spam and ham, that's a human shield tactic, and deserves
> > permanent blocking, FOREVER.  If anyone complains, lay the full
> > skinny on them as to why.  I.e. lay the blame at the proper feet, and
> > direct complaints at the guilty.
> > 
> > Life is too short to waste _your_ valuable time playing whack-a-mole
> > with spammers, isn't it?  We don't live in a totally "collateral
> > damage free" world.  People must get used to this.
> 
> Unless of course you get hit with a law suit.

My server, my rules.
>

Re: selective greylisting with a long delay

Jerry put forth on 4/11/2011 4:39 PM:
> On Mon, 11 Apr 2011 15:43:09 -0500
> Stan Hoeppner  articulated:
> 
>> pf at alt-ctrl-del.org put forth on 4/10/2011 10:33 PM:
>>
>>> My thought on auto combating this is to use a CIDR list to kick
>>> these networks (and only these networks) over to a greylist policy
>>> that delays these emails for 4+ hours. By then, most of the bad IPs
>>> would be listed in one or more RBL and be blocked.
>>>
>>> So, has anyone else already done something like this?
>>
>> Why bother with this complex greylisting setup?  Simply hammer the big
>> blocks with a CIDR entry and whitelist individual IPs in the range
>> from which you need legit mail.  If such IPs are used to send both
>> snowshoe spam and ham, that's a human shield tactic, and deserves
>> permanent blocking, FOREVER.  If anyone complains, lay the full
>> skinny on them as to why.  I.e. lay the blame at the proper feet, and
>> direct complaints at the guilty.
>>
>> Life is too short to waste _your_ valuable time playing whack-a-mole
>> with spammers, isn't it?  We don't live in a totally "collateral
>> damage free" world.  People must get used to this.
> 
> Unless of course you get hit with a law suit.

Anyone can file suit against anyone in the US for anything.  These are
classified as "frivolous" lawsuits, and most are tossed after the
initial dismissal request by the defense attorney, if not simply
rejected by the court clerk for not meeting some basic requirement.

Have you heard of a case of an SMTP sender suing an SMTP receiver for
message rejection, and winning the case?  Something like this would echo
through the tech press, and I've heard nothing.

AFAIK, "my server, my rules" is the "law of the land" in this regard.
There is no actual law (in the US) that covers SMTP mail, with the
exception of CAN-SPAM.  AFAIK, CAN-SPAM places no such burden on receivers.

-- 
Stan

Re: Filtering spam received from multiple users

Jose Hales-Garcia put forth on 4/11/2011 4:47 PM:
> 
> Hello,
> 
> I've recently been getting spam that has the first received header filled in 
> with multiple users.  This is an example.
> 
> Received: from  79.14.233.16 (account ,
>   ,

>HELO domain)
>   by domain (CommuniGate Pro SMTP 5.2.3)
>   with ESMTPA id 107437582 for ; Mon, 11 Apr 2011 10:19:10 
> +0100
> 
> My first idea for handling these messages is writing a filter in 
> header_checks using regexp.  Is this the best approach to take using Postfix 
> 2.4.3?

Probably not.  Provide the full header and we may be able to give you
better options.

If this is bot spam or snowshoe spam, there are much better ways to deal
with it, but we need to see the source IP.  If it's phish from a
compromised gorilla, webmail, or other account, it's more difficult, and
header_checks may be appropriate.  With what you've posted thus far,
it's impossible to give a definitive answer.

-- 
Stan

Re: selective greylisting with a long delay

Stan Hoeppner:
> Have you heard of a case of an SMTP sender suing an SMTP receiver for
> message rejection, and winning the case?

http://www.spamhaus.org/organization/statement.lasso?ref=3

They sued, and the US judge awarded them US$11.7 million for damages.

Wietse

Re: minor postscreen cleanup logging issue

Peter Schultze:
> Hello,
> 
> using postfix 2.8.2 under Solaris 10 with
> postscreen_cache_map = dbm:$data_directory/verify_cache
> 
> it appears that cache cleanup logging gives erratic numbers of retained 
> entries,
> ranging between 1875 and as high as 727916:
> 
> Apr  3 11:32:25  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=1875 dropped=59 entries
> Apr  3 23:32:58  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=468417 dropped=693 
> entries
> Apr  4 11:33:13  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=238015 dropped=1087 
> entries
> Apr  4 23:33:43  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=404255 dropped=207 
> entries
> Apr  5 11:34:08  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=357344 dropped=1094 
> entries
> Apr  5 23:34:09  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=10043 dropped=278 entries
> Apr  6 11:34:24  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=235581 dropped=1393 
> entries
> Apr  6 23:34:52  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=389771 dropped=839 
> entries
> Apr  7 11:35:41  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=668060 dropped=546 
> entries
> Apr  7 23:36:23  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=569135 dropped=903 
> entries
> Apr  8 11:36:41  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=259013 dropped=1148 
> entries
> Apr  8 23:36:59  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=252607 dropped=832 
> entries
> Apr  9 11:37:08  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=117216 dropped=677 
> entries
> Apr  9 23:38:02  postfix/postscreen[760]: [ID 197553 mail.info] cache 
> /var/lib/postfix/verify_cache full cleanup: retained=727916 dropped=492 
> entries
> 
> 
> The actual number of cache entries on this system is around 25000:
> 
> # postmap -s /var/lib/postfix/verify_cache | wc -l
> 24436
> 
> Otherwise postscreen is working well, so if this is a bug it would only be 
> minor.
> 

The cache manager (dict_cache.c) uses the same first/next iterator
as "postmap -s".

The difference is that "postmap -s" makes a continuous pass, while
cache manager cleanup is interleaved with routine database lookup
and updates.  I suspect that the DBM iterator does not handle this
usage pattern and just thrashes around in the database.

A more serious problem is that DBM tables can only have a limited
number of entries in the same hash bucket, after that, all updates
fail with a hard error (this is a known problem with NIS databases).

For all these reasons the default cache database type is btree not
dbm.  It has a more robust iterator, and it does not die when you
have many entries in the database.

You change the default at your own risk.

Wietse

Re: selective greylisting with a long delay

2011-04-11 Thread Daniel Bromberg


On 4/11/2011 7:07 PM, Wietse Venema wrote:

Stan Hoeppner:

Have you heard of a case of an SMTP sender suing an SMTP receiver for
message rejection, and winning the case?

http://www.spamhaus.org/organization/statement.lasso?ref=3

They sued, and the US judge awarded them US$11.7 million for damages.

Wietse
It's worth nothing though that SpamHaus treated it as a farce, and while 
it certainly cost legal billing time, the judgement itself has zero 
weight. Emphasis mine below. Maybe with other countries the situation is 
different? [Off topic warning to self and others...]


"The obtaining of a US default judgment against a UK organization did 
not however have the expected outcome for the spammer, **as default 
judgments from US courts are not recognized in the United Kingdom**...
"Spamhaus is however concerned at how far a US court will go before 
asking itself if it has jurisdiction or evidence to back up an 
allegation of jurisdiction before issuing orders to foreign entities, 
and is intending to appeal the absurd Illinois ruling in order to stamp 
out further attempts by spammers to abuse the US court system in this way."


-DB

Re: selective greylisting with a long delay

Wietse Venema put forth on 4/11/2011 6:07 PM:
> Stan Hoeppner:
>> Have you heard of a case of an SMTP sender suing an SMTP receiver for
>> message rejection, and winning the case?
> 
> http://www.spamhaus.org/organization/statement.lasso?ref=3
> 
> They sued, and the US judge awarded them US$11.7 million for damages.

I can't believe you quoted this case as an example meeting the criteria
of the scenario above.  It's not even close, and it's a horrible example
of any spam legal case.

In the infamous e360 vs. Spamhaus case, a US spammer sued a foreign
DNSBL operator (not an SMTP receiver rejecting his messages), and won by
default in absentia, by gaming the US court system into assuming
jurisdiction over a foreign entity.  The judge stupidly obliged the
plaintiff by never verifying jurisdiction, and entered a default
judgment when Spamhaus withdrew from the case after the judge's refusal
to examine jurisdiction.

Again, a horrible case to use as an example, and especially when it
doesn't fit the scenario being discussed.

-- 
Stan

Re: selective greylisting with a long delay

2011-04-11 Thread pf at alt-ctrl-del.org

"Stan Hoeppner" Monday, April 11, 2011 4:43 PM

pf at alt-ctrl-del.org put forth on 4/10/2011 10:33 PM:

My thought on auto combating this is to use a CIDR list to kick these
networks (and only these networks) over to a greylist policy that delays
these emails for 4+ hours. By then, most of the bad IPs would be listed
in one or more RBL and be blocked.

So, has anyone else already done something like this?

Why bother with this complex greylisting setup? Simply hammer the big
blocks with a CIDR entry and whitelist individual IPs in the range from
which you need legit mail. If such IPs are used to send both snowshoe
spam and ham, that's a human shield tactic, and deserves permanent
blocking, FOREVER. If anyone complains, lay the full skinny on them as
to why. I.e. lay the blame at the proper feet, and direct complaints at
the guilty.

Life is too short to waste _your_ valuable time playing whack-a-mole
with spammers, isn't it? We don't live in a totally "collateral damage
free" world. People must get used to this.

Just because most of the emails are spam, doesn't mean that most of their customers are spammers. After all, the
spammers are sending a lot more mail than legit sites do.

If the ISP has multiple /15's and /16's, I think that blocking all of their IPs then exempting specific IPs would take
too much time and effort. I would just be playing a different version of whack-a-mole and constantly be adding new
exempted IPs. My goal is to automate anything I can, and not replace one problem with another.

I don't think it would be particularly complex...
smtpd_restriction_classes = long_grey
long_grey = check_policy_service unix:private/greylist
smtpd_client_restrictions = ...,check_client_access
cidr:/etc/postfix/grey.cidr,...
xx.xx.0.0/15 long_grey
xx.xx.0.0/16 long_grey
0.0.0.0/0 DUNNO

But another user on the list has already said that greylist wait times of a couple hours caused more problems than they
solved in his experience.

Re: Filtering spam received from multiple users

2011-04-11 Thread Jose Hales-Garcia


On Apr 11, 2011, at 3:44 PM, Stan Hoeppner wrote:

>> My first idea for handling these messages is writing a filter in 
>> header_checks using regexp.  Is this the best approach to take using Postfix 
>> 2.4.3?
> 
> Probably not.  Provide the full header and we may be able to give you
> better options.

I've put it below (from the latest one to arrive).

Jose
...
Jose Hales-Garcia
UCLA Department of Statistics

Return-Path: <1004045u44630...@bridgestone.co.jp>
Received: from murder ([unix socket])
 by mda.domain (Cyrus v2.2.12-OS X 10.4.8) with LMTPA;
 Mon, 11 Apr 2011 12:18:46 -0700
X-Sieve: CMU Sieve 2.2
Received: from smtp.domain (mta.domain [mta.ip_addr])
by mda.domain (Postfix) with ESMTP id B30E42BE1FD4;
Mon, 11 Apr 2011 12:18:46 -0700 (PDT)
Received: by smtp.domain (Postfix)
id 317173CDC36A; Mon, 11 Apr 2011 12:29:30 -0700 (PDT)
Delivered-To: user9@domain
Received: from localhost (localhost [127.0.0.1])
by smtp.domain (Postfix) with ESMTP id 16C4A3CDC360;
Mon, 11 Apr 2011 12:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at domain
X-Spam-Flag: NO
X-Spam-Score: 2.526
X-Spam-Level: **
X-Spam-Status: No, score=2.526 tagged_above=-1000 required=6.31
tests=[BAYES_00=-2.599, SORTED_RECIPS=1.125, UNPARSEABLE_RELAY=4]
Received: from smtp.domain ([127.0.0.1])
by localhost (mta.domain [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id vLLDg48PM5PE; Mon, 11 Apr 2011 12:29:29 -0700 (PDT)
Received: from [190.221.28.39] (unknown [190.221.28.39])
by smtp.domain (Postfix) with ESMTP id 46B763CDC359;
Mon, 11 Apr 2011 12:29:29 -0700 (PDT)
Received: from  190.221.28.39 (account ,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
 HELO domain)
by domain (CommuniGate Pro SMTP 5.2.3)
with ESMTPA id 620648953 for ; Mon, 11 Apr 2011 16:29:28 
-0300
From: , ,
, ,
, , ,
, ,
, , ,
, ,
, ,
, ,
, 
To: , ,
, ,
, , ,
, ,
, , ,
, ,
, ,
, ,
, 
Subject: Newsletter Mon, 11 Apr 2011 16:29:28 -0300
Date: Mon, 11 Apr 2011 16:29:28 -0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-2"
Content-Transfer-Encoding: 7bit
X-Mailer: hljkn_86
Message-ID: <7186695846.145ivfav436...@pswasejg.gfjeafxwjq.net>

RE: smptd_client_restriction

2011-04-11 Thread mejaz


mynetworks isn't listed here.

Thank you so much for you help. 

Sorry may some lines were not copied properly in my previous Email. Here is
the ouput of postconf -n and you will find mynetworks in second last line. 


bounce_queue_lifetime = 1d
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
maximal_queue_lifetime = 1d
message_size_limit = 20971520
mydomain = cyberia.net.sa
myhostname = mailgate5.cyberia.net.sa
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
relay_domains = hash:/etc/postfix/relay_domains
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_banner = smtp.cyberia.net.sa
smtpd_client_restrictions = check_client_access hash:/etc/postfix/access,
check_client_access cidr:/etc/postfix/mynetworks, reject_rbl_client
bl.spamcop.vnet,zen.spamhaus.org
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550

ejaz 

-Original Message-
From: owner-postfix-us...@postfix.org
[mailto:owner-postfix-us...@postfix.org] On Behalf Of Noel Jones
Sent: Monday, April 11, 2011 5:41 PM
To: postfix-users@postfix.org
Subject: Re: smptd_client_restriction

On 4/11/2011 7:37 AM, Ejaz wrote:
> Thanks a lot Jones.
>
> I am using /etc/postfix/mynetworks where I can list "trusted"
> network addresses (IPADDRESS) is it?
>
> *_Postconf -n output_*
>
> bounce_queue_lifetime = 1d
>
> command_directory = /usr/sbin
>
> config_directory = /etc/postfix
>
> daemon_directory = /usr/libexec/postfix
>
> debug_peer_level = 2
>
> header_checks = regexp:/etc/postfix/header_checks
>
> html_directory = no
>
> inet_interfaces = all
>
> mail_owner = postfix
>
> mailq_path = /usr/bin/mailq
>
> manpage_directory = /usr/local/man
>
> maximal_queue_lifetime = 1d
>
> message_size_limit = 20971520
>
> mydomain = cyberia.net.sa
>
> myhostname = mailgate5.cyberia.net.sa
>
> newaliases_path = /usr/bin/newaliases


mynetworks isn't listed here.


   -- Noel Jones


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Nulls not being stripped from incoming mail

2011-04-11 Thread Rich Wales

I'm running Postfix 2.8.1 and Cyrus 2.3.16 on an Ubuntu 10.04 (Lucid)
server.

I'm having trouble with incoming mail from Google's Postini help forum.
The messages I'm getting contain null characters in the body, so Cyrus
is saying "554 5.6.0 Message contains NUL characters (in reply to end
of DATA command)" and is refusing to accept the messages in question.

I added "message_strip_characters = \0" to my Postfix's main.cf and did
a reload of Postfix, but this doesn't seem to have had any effect on the
problem.  I did a Google search and found various complaints over the
years from people claiming "message_strip_characters = \0" didn't work
for them, but there didn't seem to be any obvious answer.

Google really ought to fix their software so it doesn't break the RFCs
by generating mail with nulls in the body, but I'm not going to hold my
breath, and I can't afford the petty luxury of refusing to look at an
e-mail reply because Google broke the specs.

See below for my "postconf -n" output.  Any ideas?

Rich Wales
Palo Alto, CA, USA
ri...@richw.org



alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
default_destination_concurrency_limit = 1
default_destination_recipient_limit = 1
default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what]
blocked using $rbl_domain${rbl_reason?; $rbl_reason}; report problems to
richwales )at( gmail.com
header_checks = pcre:/etc/postfix/ignore_tb_msgid
inet_protocols = ipv4
lmtp_destination_recipient_limit = 1
local_destination_concurrency_limit = 1
local_destination_recipient_limit = 1
local_header_rewrite_clients = permit_sasl_authenticated
local_recipient_maps = hash:/etc/postfix/local_recipients $alias_maps
mail_owner = postfix
mailbox_transport = lmtp:[127.0.0.1]
masquerade_domains = $mydomain
maximal_queue_lifetime = 30d
message_size_limit = 5000
message_strip_characters = \0
milter_default_action = accept
milter_protocol = 2
mydestination = pcre:/etc/postfix/lan_domains
mydomain = richw.org
myhostname = whodunit.richw.org
myorigin = $myhostname
non_smtpd_milters = unix:/var/run/dkim-filter/dkim-filter.sock
queue_directory = /var/spool/postfix
relay_destination_recipient_limit = 1
relay_domains = indigo.richw.org, goldsmurf.randerzo.net, sandals.richw.org
relayhost = [www.richw.org]
smtp_destination_concurrency_limit = 1
smtp_destination_recipient_limit = 1
smtp_sasl_auth_enable = yes
smtp_sasl_mechanism_filter = PLAIN,LOGIN
smtp_sasl_password_maps = hash:/etc/postfix/sasl_password
smtp_sasl_security_options = noanonymous
smtp_sender_dependent_authentication = yes
smtp_use_tls = yes
smtpd_banner = $myhostname ESMTP $mail_name ($mail_version)
smtpd_delay_open_until_valid_rcpt = no
smtpd_discard_ehlo_keywords = etrn,silent-discard
smtpd_etrn_restrictions = reject
smtpd_helo_restrictions = reject_invalid_helo_hostname
smtpd_milters = unix:/var/run/dkim-filter/dkim-filter.sock
smtpd_restriction_classes = do_postgrey
smtpd_tls_CAfile = /etc/postfix/whodunit.pem
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/whodunit.pem
smtpd_tls_key_file = /etc/postfix/whodunit.pem
smtpd_tls_received_header = yes
smtpd_use_tls = yes
soft_bounce = yes
transport_maps = hash:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual_map
virtual_destination_recipient_limit = 1

Re: Filtering spam received from multiple users