Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread Stan Hoeppner
Michael Orlitzky put forth on 8/10/2010 4:02 PM:

 I think he just wants to know which smtpd restrictions list contains the
 rule that caused the rejection.

This is relatively easy to accomplish with custom rejection messages.  Simply
insert a unique symbol at the beginning of each rejection message text string
which identifies the rejection stage.  This of course would require a separate
access table for each check_client_access statement, which can create future
table management headaches to the point it may not be worth the effort.

-- 
Stan


Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread Stan Hoeppner
Ralf Hildebrandt put forth on 8/11/2010 2:35 AM:
 * Stan Hoeppner s...@hardwarefreak.com:
 Michael Orlitzky put forth on 8/10/2010 4:02 PM:

 I think he just wants to know which smtpd restrictions list contains the
 rule that caused the rejection.

 This is relatively easy to accomplish with custom rejection messages.  Simply
 insert a unique symbol at the beginning of each rejection message text string
 which identifies the rejection stage.  This of course would require a 
 separate
 access table for each check_client_access statement, which can create 
 future
 table management headaches to the point it may not be worth the effort.
 
 Yes, this only works for check_*_access. Stuff like e.g.
 reject_unknown_sender_domain have predefined rejection messages, so...

I was just looking at a Logwatch summary.  The data the OP is requesting _is_
in the Postfix logs somewhere, as Logwatch is tallying the disconnection phases:

   81   Connections lost (inbound)
   61  After DATA
   11  After CONNECT
7  After RCPT
2  After EHLO

If you need this information _per msg_ with detail, you'll have to go digging
and figure it out for yourself.  The data _is_ in there though.  And, yes, I
use smtpd_delay_reject=yes, the default.

-- 
Stan


Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread Stan Hoeppner
Stan Hoeppner put forth on 8/11/2010 3:31 AM:

 I was just looking at a Logwatch summary.  The data the OP is requesting _is_
 in the Postfix logs somewhere, as Logwatch is tallying the disconnection 
 phases:
 
81   Connections lost (inbound)
61  After DATA
11  After CONNECT
 7  After RCPT
 2  After EHLO
 
 If you need this information _per msg_ with detail, you'll have to go digging
 and figure it out for yourself.  The data _is_ in there though.  And, yes, I
 use smtpd_delay_reject=yes, the default.

Found it.  And not really hard to find:

~$ grep  lost connection  /var/log/mail.log|mawk {print'($6, $7, $8, $9,
$10, $11, $12, $13)}'

This won't tell you if/what restriction caused the disconnection, but you'll
definitely know during which SMTP phase the disconnection occurred.

-- 
Stan

lost connection after CONNECT from unknown[119.158.85.98]
lost connection after DATA (10150 bytes) from unknown[109.126.140.66]
lost connection after RCPT from 59-126-95-178.pool.ukrtel.net[178.95.126.59]
lost connection after CONNECT from unknown[41.174.21.83]
lost connection after DATA (0 bytes) from unknown[41.141.110.166]
lost connection after CONNECT from unknown[190.178.115.115]
lost connection after CONNECT from unknown[200.75.242.87]
lost connection after CONNECT from 5ac15e25.bb.sky.com[90.193.94.37]
lost connection after DATA (0 bytes) from unknown[117.204.161.4]
lost connection after CONNECT from unknown[120.162.51.31]
lost connection after MAIL from unknown[201.221.239.203]
lost connection after MAIL from unknown[201.221.239.203]
lost connection after MAIL from unknown[201.221.239.203]
lost connection after CONNECT from unknown[187.89.103.249]
lost connection after DATA (0 bytes) from unknown[121.97.150.20]
lost connection after RCPT from unknown[118.96.255.42]
lost connection after RCPT from unknown[210.122.170.6]
lost connection after RCPT from unknown[205.209.161.181]
lost connection after DATA (0 bytes) from unknown[211.161.193.9]
lost connection after RCPT from unknown[122.100.104.100]
lost connection after DATA (49642 bytes) from unknown[117.206.234.89]
lost connection after DATA (55333 bytes) from unknown[117.206.234.89]
lost connection after DATA (0 bytes) from unknown[190.189.11.16]
lost connection after DATA (0 bytes) from unknown[213.182.94.250]
lost connection after DATA (0 bytes) from unknown[83.149.42.62]
lost connection after CONNECT from unknown[123.26.72.52]
lost connection after DATA (0 bytes) from unknown[119.30.38.43]
lost connection after DATA (0 bytes) from unknown[91.205.168.11]
lost connection after DATA (0 bytes) from unknown[91.205.168.11]
lost connection after DATA (0 bytes) from unknown[91.205.168.11]





Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread Noel Jones

On 8/11/2010 4:10 AM, Stan Hoeppner wrote:

Stan Hoeppner put forth on 8/11/2010 3:31 AM:


I was just looking at a Logwatch summary.  The data the OP is requesting _is_
in the Postfix logs somewhere, as Logwatch is tallying the disconnection phases:

81   Connections lost (inbound)
61  After DATA
11  After CONNECT
 7  After RCPT
 2  After EHLO

If you need this information _per msg_ with detail, you'll have to go digging
and figure it out for yourself.  The data _is_ in there though.  And, yes, I
use smtpd_delay_reject=yes, the default.


Found it.  And not really hard to find:

~$ grep  lost connection  /var/log/mail.log|mawk {print'($6, $7, $8, $9,
$10, $11, $12, $13)}'

This won't tell you if/what restriction caused the disconnection, but you'll
definitely know during which SMTP phase the disconnection occurred.



This is logged when the client disconnected in the middle of 
the transaction -- postfix lost the connection -- NOT a reject.


You won't find reject log entries for the lost connections 
after EHLO or CONNECT, although the ones for RCPT and DATA 
*might* be proceeded by rejects.


This can be confusing because typically most of the lost 
connections are zombies/bots that you would reject anyway.


  -- Noel Jones


Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread Noel Jones

On 8/11/2010 6:54 AM, Stan Hoeppner wrote:

Noel Jones put forth on 8/11/2010 6:20 AM:


This is logged when the client disconnected in the middle of the
transaction -- postfix lost the connection -- NOT a reject.

You won't find reject log entries for the lost connections after EHLO or
CONNECT, although the ones for RCPT and DATA *might* be proceeded by
rejects.

This can be confusing because typically most of the lost connections are
zombies/bots that you would reject anyway.


Are you sure about that Noel?


Absolutely.



Aug  8 13:22:49 greer postfix/smtpd[14798]: connect from
59-126-95-178.pool.ukrtel.net[178.95.126.59]
Aug  8 13:22:50 greer postfix/smtpd[14798]: NOQUEUE: reject: RCPT from
59-126-95-178.pool.ukrtel.net[178.95.126.59]: 554 5.7.1
59-126-95-178.pool.ukrtel.net[178.95.126.59]: Client host rejected: Generic
- Please relay via ISP (ukrtel.net); from=i...@hardwarefreak.com
to=i...@hardwarefreak.com  proto=SMTP helo=59-126-95-178.pool.ukrtel.net
Aug  8 13:22:50 greer postfix/smtpd[14798]: lost connection after RCPT from
59-126-95-178.pool.ukrtel.net[178.95.126.59]
Aug  8 13:22:50 greer postfix/smtpd[14798]: disconnect from
59-126-95-178.pool.ukrtel.net[178.95.126.59]

This example clearly shows the disconnect at RCPT was due to a rejection.
This example was in my previous list.


Don't confuse disconnect from with lost connection.  The 
disconnect is always logged; lost connection is logged when 
the client drops the connection in the middle of the conversation.


This entry shows the client dropped the connection after you 
sent a reject.  Many, but not all, spambots seem to do that.




And how about this one?

Aug 10 23:02:46 greer postfix/smtpd[30689]: connect from unknown[113.91.134.58]
Aug 10 23:02:47 greer postfix/smtpd[30689]: NOQUEUE: reject: RCPT from
unknown[113.91.134.58]: 554 5.7.1unknown[113.91.134.58]: Client host
rejected: Mail not accepted from China; from=thei...@robertharding.com
to=s...@hardwarefreak.com  proto=ESMTP helo=QOYCLTMTN
Aug 10 23:02:48 greer postfix/smtpd[30689]: lost connection after DATA (0
bytes) from unknown[113.91.134.58]
Aug 10 23:02:48 greer postfix/smtpd[30689]: disconnect from 
unknown[113.91.134.58]

Again, the disconnection was due to rejection.  This one was also in my
previous example.  In fact, every one of my rejections shows a disconnect
stamp pretty much identical to those which are simply clients prematurely
disconnecting for whatever reason.


Here the client sent the DATA command before it dropped the 
connection.  It dropped the connection because it's a spambot 
and you rejected the recipient.




This leads me to believe the SMTP stage of disconnection is logged for all
disconnects, including those due to rejections.


When the client drops the connection in the middle of a 
transaction the stage is logged.  Normal clients don't drop 
the connection after a reject, but spambots often do.


You can see this for yourself in your logs; not every reject 
is followed by a lost connection message, not every lost 
connection is proceeded by a reject.


I expect most of the lost connection after RCPT or DATA are 
proceeded by a reject simply because most of these are 
spambots.  But one does not equal the other.


Don't confuse disconnect with lost connection.  A 
disconnect message is always logged at the end of the 
conversation when the client disconnects.  A lost connection 
is logged when postfix is still trying to talk to the client 
but the client dropped the connection early.



I guess we'll find out when
Wietse jumps in to educate us on this.



This has been discussed before. Search the archives.


  -- Noel Jones


Email delivery fails on postfix on heavy load

2010-08-11 Thread Sharma, Ashish
Hi,

I have a postfix(postfix 2.6.5) mail receiving server.

On this I have used an email filter (sendmail-jilter 
http://sendmail-jilter.sourceforge.net/) that have some of my custom code. 
Following setting is used for the milter in 'main.cf':

#Milter support for smtpd mail
smtpd_milters =
  inet:localhost:10028

milter_protocol = 2

Here on email loads of approx 40/hour the setup is fine but for email loads of 
approx 600/hour, I am facing following messages in postfix logs:

Aug  9 07:34:12 ip-10-244-155-191 postfix/cleanup[10308]: warning: milter 
inet:localhost:10028: can't read SMFIC_EOH reply packet header: Success
Aug  9 07:34:12 ip-10-244-155-191 postfix/cleanup[10308]: 771CB100168: 
milter-reject: END-OF-MESSAGE from xxx.atlanta.xx.com[15.xxx.32.xx]: 5.5.0 
Service unavailable; from=.x...@**.com 
to=739afne44u...@load...net proto=ESMTP helo=xxx.atlanta.xx.com

On checking the milter side logs I can see that mail is getting passed 
successfully but because of above logged problem the email sender server gives 
out 

'550 5.5.0 Service unavailable'

in the inbox of mail sender.

Any idea what's going on?

Please help!!!

Thanks in advance
Ashish Sharma


Re: Is possible reject mail with multiple destination?

2010-08-11 Thread kazabe
2010/8/11 Magnus Bäck mag...@dsek.lth.se:

 The body (or, as I suspect you really meant, the headers) is irrelevant,
 it's the envelope you should inspect. A policy server can record the
 number of recipients in a message and reject the message if a particular
 condition is met. Check out existing policy servers like policyd and see
 if they meet your requirements.

 Of course, the users will find ways around this -- sending multiple
 messages or just keep sending the messages but to fewer people. You have
 a social problem, not a technical one.


hi

i need by example reject this email.




From: MARTHA DIAZ marthadia...@hotmail.com
To: divin...@hotmail.com, gonzalez...@gmail.com, maia...@hotmail.com,
angelamaritz...@hotmail.com, bibiss...@hotmail.com,
juancaco...@hotmail.com, zhi...@hotmail.com, lcp...@hotmail.com,
carolina_ne...@hotmail.com
CC: dh...@hotmail.com, gerca...@hotmail.com, h...@hotmail.com,
lualne...@hotmail.com, conde...@supercabletv.net.co,
orfigo...@yahoo.com, mt...@hotmail.com, mauherd...@hotmail.com,
mpne...@hotmail.com, rafitapap...@hotmail.com,
albarpel...@hotmail.com, virap...@hotmail.com, zmp...@hotmail.com
Subject: FW: LA MEJOR PUBLICIDAD!!
Date: Tue, 19 Dec 2006 17:52:45 +








From:  Camila Andrea Ruget Castro carc1...@hotmail.com
To:  bellota...@hotmail.com,
mariluna...@hotmail.com,eresand...@hotmail.com,
vdam...@hotmail.com,
luisa7...@hotmail.com,anacristanch...@hotmail.com,
dianan...@hotmail.com,limar...@hotmail.com,
juligonzi_1...@hotmail.com,auriscor...@hotmail.com,
karensita_...@hotmail.com,paula_inmo...@hotmail.com,
daniela_...@hotmail.com,annyita...@hotmail.com,
kalimahe...@hotmail.com,laura_mend_...@hotmail.com,
sajal...@hotmail.com,
gambi...@hotmail.com,johanas...@hotmail.com,
ladydvc2...@hotmail.com,pepadelma...@hotmail.com,
mariap_...@hotmail.com,pepadel...@hotmail.com,
julia_ch...@hotmail.com,
patu...@hotmail.com,mapilarrug...@hotmail.com,
adriru...@hotmail.com,chavita1...@hotmail.com,
marthadia...@hotmail.com,ritogorr...@hotmail.com,
jorgepili2...@hotmail.com,alpinit...@hotmail.com,
ruge...@hotmail.com,
paulis_r...@hotmail.com,pau_9...@hotmail.com,
german_ru...@hotmail.com,daniel_ruget...@hotmail.com
Subject:  FW: LA MEJOR PUBLICIDAD!!
Date:  Tue, 19 Dec 2006 00:35:27 +0100








  From: ricardo8...@hotmail.com
  To: limar...@hotmail.com; karen17...@hotmail.com; 
  angelapatric...@gmail.com; jenbluem...@hotmail.com; 
  angelacaral...@hotmail.com; jotaesk...@hotmail.com; coler...@hotmail.com; 
  adrianitalind...@hotmail.com; ladydvc2...@hotmail.com; cath...@hotmail.com; 
  kavi...@hotmail.com; victoria_45_...@hotmail.com; lyn...@hotmail.com; 
  civil@hotmail.com; lorenaa...@hotmail.com; mariak12...@hotmail.com; 
  astrov...@hotmail.com; joyita...@hotmail.com; zare1...@hotmail.com; 
  pilicamargo_...@hotmail.com; catator...@hotmail.com; anamis...@hotmail.com; 
  luna_18...@hotmail.com; adrianheredi...@hotmail.com; 
  monita_santama...@hotmail.com; ximeka...@hotmail.com; 
  julyca...@hotmail.com; mariacarolin...@hotmail.com; carc1...@hotmail.com; 
  lilianita_ru...@hotmail.com; alejag...@hotmail.com; 
  mafegacha...@hotmail.com; ancod...@hotmail.com; edi...@hotmail.com; 
  memoon...@hotmail.com; yelaiah71...@hotmail.com; juliethce...@hotmail.com
  Subject: LA MEJOR PUBLICIDAD!!
  Date: Sun, 10 Dec 2006 12:36:04 +0100
 
  RICARDO[http://gfx4.mail.live.com/mail/11.00/updatebeta/emoticons/smile_wink.gif]...
  
  Prueba algunos de los nuevos servicios en línea que te ofrece Windows Live 
  Ideas: tan nuevos que ni siquiera se han publicado oficialmente todavía. 
  Pruébalohttp://ideas.live.com

_
Consigue el nuevo Windows Live Messenger
http://get.live.com/messenger/overview




Charla con tus amigos en línea mediante MSN Messenger: Haz clic aquí




Charla con tus amigos en línea mediante MSN Messenger: Haz clic aquí

LOSMEJORESCOMERCIALES.pps


Re: Is possible reject mail with multiple destination?

2010-08-11 Thread Noel Jones

On 8/11/2010 3:43 PM, kazabe wrote:



i need by example reject this email.




From: MARTHA DIAZmarthadia...@hotmail.com
To: divin...@hotmail.com, gonzalez...@gmail.com, maia...@hotmail.com,
angelamaritz...@hotmail.com, bibiss...@hotmail.com,
juancaco...@hotmail.com, zhi...@hotmail.com, lcp...@hotmail.com,
carolina_ne...@hotmail.com
CC: dh...@hotmail.com, gerca...@hotmail.com, h...@hotmail.com,
lualne...@hotmail.com, conde...@supercabletv.net.co,
orfigo...@yahoo.com, mt...@hotmail.com, mauherd...@hotmail.com,
mpne...@hotmail.com, rafitapap...@hotmail.com,
albarpel...@hotmail.com, virap...@hotmail.com, zmp...@hotmail.com
Subject: FW: LA MEJOR PUBLICIDAD!!
Date: Tue, 19 Dec 2006 17:52:45 +



Here's some rope:

# main.cf
header_checks = regexp:/etc/postfix/header_checks

# header_checks
IF /^(to|cc):/
/(@*){10}/  HOLD  too many addresses in To: or CC: header
ENDIF



Note this counts the recipients listed in each header, not the 
combined total.


Note this counts declared recipients listed in the headers. 
This has little or no relation to actual recipients.


I wouldn't be surprised is this rejects mail you want, and 
passes lots of mail you don't want.  Use with caution.


A too many recipients might be spam test is far better 
suited for a scoring system such as SpamAssassin, which can 
also do more complex checks.


Consider using a content_filter or milter that incorporates 
SpamAssassin.


Consider using reject_rbl_client zen.spamhaus.org somewhere 
in your restrictions.  If your site is too big for the free 
spamhaus service, it's well worth paying for.


Consider using the clamav anti-virus scanner with the 
Sanesecurity add-on spam signatures.



  -- Noel Jones


Re: Scanning attachments for content?

2010-08-11 Thread Michael Orlitzky

On 08/11/2010 09:46 AM, Paul Hutchings wrote:

I have a box running Postfix  MailScanner.

I'd like to be able to say If a message comes from XYZ and has Word or
PDF attachments and they contain the word ABC,action.

I'm sure this can be done, I doubt it's a Postfix feature, but I'm
unsure of the best (and easiest for someone like myself) product to be
looking at that hooks into Postfix, so any suggestions would be
appreciated.


Mailscanner is written in Perl? You'll have to do some hacking, but you 
can probably just pass the attachments to antiword[1] or pdftotext[2] 
and then match the result against a regular expression.


You could also look at writing your own content filter which would do 
the same thing in e.g. shell script.



[1] http://www.winfield.demon.nl/
[2] http://poppler.freedesktop.org/


question about Postfix and DNS (maybe not for this list)

2010-08-11 Thread Christopher Adams
Hello all,

I am having a bit of a problem and I am not sure that it is specifically
Postfix-related, but I'll give it a shot. Feel free to flog me or tell me to
go away.

I am running Postfix 2.3 on a CentOS Linux server.

I noticed on our firewall that there were constant connections from the
machine running Postfix to addresses all over the world. The interesting
thing is that the connection is using OpenDNS [208.67.216.132], a public DNS
server. I do not use OpenDNS in my /etc/resolv.conf file (I have 2 other
nameservers listed) and I don't know where it is coming from. Here is an
example:

Aug 11 16:01:25 swiki postfix/smtp[7832]: E38F8DB4CCB: to=ysamo9...@sx.cn,
relay=none, delay=30, delays=0/0/30/0, dsn=4.4.1, status=deferred (connect
to sx.cn[208.67.216.132]: Connection timed out)

If this is the appropriate place to post this question, can someone who
knows more than me analyze this and come up with a theory as to what is
going on?

Thanks for any help you might want to provide.


Re: question about Postfix and DNS (maybe not for this list)

2010-08-11 Thread Walter Pinto
Setup snort and find out where the connections are coming from. There
are many ways to do this.

also check /etc/sysconfig/networking/profiles/default/resolv.conf

Is your server behind a NAT firewall?


Re: question about Postfix and DNS (maybe not for this list)

2010-08-11 Thread Jose Ildefonso Camargo Tolosa
Hi!

On Wed, Aug 11, 2010 at 7:50 PM, Christopher Adams adam...@gmail.com wrote:
 Hello all,

 I am having a bit of a problem and I am not sure that it is specifically
 Postfix-related, but I'll give it a shot. Feel free to flog me or tell me to
 go away.

Ok: go away!

No, just kidding, read on.


 I am running Postfix 2.3 on a CentOS Linux server.

 I noticed on our firewall that there were constant connections from the
 machine running Postfix to addresses all over the world. The interesting
 thing is that the connection is using OpenDNS [208.67.216.132], a public DNS
 server. I do not use OpenDNS in my /etc/resolv.conf file (I have 2 other
 nameservers listed) and I don't know where it is coming from. Here is an
 example:

 Aug 11 16:01:25 swiki postfix/smtp[7832]: E38F8DB4CCB: to=ysamo9...@sx.cn,
 relay=none, delay=30, delays=0/0/30/0, dsn=4.4.1, status=deferred (connect
 to sx.cn[208.67.216.132]: Connection timed out)

Can you post the other lines of this log (same ID: E38F8DB4CCB), where
there is the *from*, and see if the *from* is from your domain, if no:
maybe you are an open relay.

Also, take a look at your mail queue run: mailq


 If this is the appropriate place to post this question, can someone who
 knows more than me analyze this and come up with a theory as to what is
 going on?

Yes, it is, at least judging by the log entry you sent, that's a postfix log.


 Thanks for any help you might want to provide.


No problem.

Ildefonso.


Connection Refused when sending on from local domain

2010-08-11 Thread John

 Hi,

We have a Postfix (2.7.1) instance running successfully for all of our 
mail needs, short of one scenario.  On our network, we are trying to 
configure other hosts (on the same class of private IP address - 
192.168.x.x) to forward mail (logwatch files) to an aliased user using a 
sendmail client.


Here is a snippet of a log entry, from the client, that shows the 
connection refused error:


Aug 11 20:15:41 myhost sendmail[17048]: o7B9uJjQ015169: 
to=u...@example.com, ctladdr=r...@myhost.example.com (0/0), 
delay=15:19:22, xdelay=00:00:00, mailer=esmtp, pri=1560372, 
relay=mail.example.com., dsn=4.0.0, stat=Deferred: Connection refused by 
mail.example.com.


In reading the documentation the only thing I could find that would 
affect this connection was $mydomain and $mynetworks, or so I assumed, 
but cannot seem to find the right mixture to be successful.  I've 
spent a considerable amount of time on this and am now asking what am I 
missing or what do I have misconfigured in order to get this work correctly?


Thanks for any help or pointing me in the right direction.

John

Here is the output of postconf -n

# postconf -n
alias_maps = hash:/etc/postfix/aliases
broken_sasl_auth_clients = yes
canonical_maps = pgsql:/etc/postfix/sql/pgsql-canonical-maps.cf
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = amavisfeed:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = $myhostname, localhost
mail_owner = postfix
mailbox_delivery_lock = fcntl, dotlock
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
masquerade_domains = $mydomain
message_size_limit = 2048
mydestination = $myhostname, mail.$mydomain
mydomain = example.com
myhostname = mail.example.com
mynetworks = 192.168.0.0/24, 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtp_tls_note_starttls_offer = yes
smtpd_helo_required = yes
smtpd_recipient_restrictions = 
permit_sasl_authenticated,permit_mynetworks,reject_non_fqdn_recipient,reject_non_fqdn_sender,reject_unauth_destination,reject_unknown_sender_domain,reject_rbl_client 
zen.spamhaus.org

smtpd_reject_unlisted_sender = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = check_sender_access 
hash:/etc/postfix/sender_access_map

smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/postfix/ssl/myhost.com-cert.pem
smtpd_tls_key_file = /etc/postfix/ssl/myhost.com-key.pem
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
soft_bounce = no
tls_random_source = dev:/dev/urandom
unknown_local_recipient_reject_code = 550
virtual_alias_maps = pgsql:/etc/postfix/sql/pgsql-virtual-alias-maps.cf
virtual_gid_maps = pgsql:/etc/postfix/sql/pgsql-virtual-gid-maps.cf
virtual_mailbox_base = /mail
virtual_mailbox_domains = 
pgsql:/etc/postfix/sql/pgsql-virtual-mailbox-domains.cf

virtual_mailbox_lock = fcntl, dotlock
virtual_mailbox_maps = 
pgsql:/etc/postfix/sql/pgsql-virtual-mailbox-recipients.cf

virtual_uid_maps = pgsql:/etc/postfix/sql/pgsql-virtual-uid-maps.cf

P.S. Thanks Ralph and Patrick for The Book of Postfix, you'll likely 
recognize your virtual hosting solution from Chapter 14...




Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread JunkYardMail1

With smtpd_delay_reject = yes

Which of the restriction sections was the following logged rejection for?
Or put another way, in which of the restriction sections was the rejection 
option reject_rbl_client pbl.spamhaus.org that resulted in the logged 
rejection?


Restriction Options:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_etrn_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
smtpd_end_of_data_restrictions

Aug 10 19:00:14 RapidVPS1 postfix-mx/smtpd[9301]: NOQUEUE: reject: RCPT from 
unknown[190.40.76.65]: 521 5.7.1 Service unavailable; Client host 
[190.40.76.65] blocked using pbl.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=190.40.76.65; from=c...@blah.com 
to=c...@blah.com proto=SMTP helo=client-190.40.76.65.speedy.net.pe


It says RCPT because that is the stage at which the rejections are processed 
when smtpd_delay_reject is enable.  But that is not the restriction section 
the rejection was for.


It was actually an smtpd_client_restrictions, so when smtpd_delay_reject is 
enabled would like it to be logged similarly to how it would be if 
smtpd_delay_reject was disabled.  Designation of CONNECT rather than RCPT.
Aug 10 19:00:14 RapidVPS1 postfix-mx/smtpd[9301]: NOQUEUE: reject: CONNECT 
from unknown[190.40.76.65]: 521 5.7.1 Service unavailable; Client host 
[190.40.76.65] blocked using pbl.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=190.40.76.65; from=c...@mydomain.com 
to=c...@mydomain.com proto=SMTP helo=client-190.40.76.65.speedy.net.pe


When smtpd_delay_reject is disabled it would be logged as:
Aug 10 19:00:14 RapidVPS1 postfix-mx/smtpd[9301]: NOQUEUE: reject: CONNECT 
from unknown[190.40.76.65]: 521 5.7.1 Service unavailable; Client host 
[190.40.76.65] blocked using pbl.spamhaus.org; 
http://www.spamhaus.org/query/bl?ip=190.40.76.65; proto=SMTP


Hope this clarifies rather then muddies.




Re: Connection Refused when sending on from local domain

2010-08-11 Thread Wietse Venema
 Aug 11 20:15:41 myhost sendmail[17048]: o7B9uJjQ015169: 
 to=u...@example.com, ctladdr=r...@myhost.example.com (0/0), 
 delay=15:19:22, xdelay=00:00:00, mailer=esmtp, pri=1560372, 
 relay=mail.example.com., dsn=4.0.0, stat=Deferred: Connection refused by 
 mail.example.com.

That is the Sendmail MTA, not POSTFIX.

Wietse


Re: smtpd_delay_reject = yes Reject Logging

2010-08-11 Thread Noel Jones

On 8/11/2010 8:44 PM, junkyardma...@verizon.net wrote:

With smtpd_delay_reject = yes

Which of the restriction sections was the following logged
rejection for?
Or put another way, in which of the restriction sections was
the rejection option reject_rbl_client pbl.spamhaus.org that
resulted in the logged rejection?



Why would you put pbl.spamhaus.org in more than one section?




Restriction Options:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_etrn_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
smtpd_end_of_data_restrictions

Aug 10 19:00:14 RapidVPS1 postfix-mx/smtpd[9301]: NOQUEUE:
reject: RCPT from unknown[190.40.76.65]: 521 5.7.1 Service
unavailable; Client host [190.40.76.65] blocked using
pbl.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=190.40.76.65;
from=c...@blah.com to=c...@blah.com proto=SMTP
helo=client-190.40.76.65.speedy.net.pe

It says RCPT because that is the stage at which the rejections
are processed when smtpd_delay_reject is enable. But that is
not the restriction section the rejection was for.

It was actually an smtpd_client_restrictions, so when
smtpd_delay_reject is enabled would like it to be logged
similarly to how it would be if smtpd_delay_reject was
disabled. Designation of CONNECT rather than RCPT.
Aug 10 19:00:14 RapidVPS1 postfix-mx/smtpd[9301]: NOQUEUE:
reject: CONNECT from unknown[190.40.76.65]: 521 5.7.1 Service
unavailable; Client host [190.40.76.65] blocked using
pbl.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=190.40.76.65;
from=c...@mydomain.com to=c...@mydomain.com proto=SMTP
helo=client-190.40.76.65.speedy.net.pe

When smtpd_delay_reject is disabled it would be logged as:
Aug 10 19:00:14 RapidVPS1 postfix-mx/smtpd[9301]: NOQUEUE:
reject: CONNECT from unknown[190.40.76.65]: 521 5.7.1 Service
unavailable; Client host [190.40.76.65] blocked using
pbl.spamhaus.org;
http://www.spamhaus.org/query/bl?ip=190.40.76.65; proto=SMTP

Hope this clarifies rather then muddies.






Don't use duplicate restrictions.




Postfix User unknown in virtual mailbox table

2010-08-11 Thread Aravind Divakaran


HI 

I have configured my mailserver with fetchmail and postfix.
Mails will come primarly to Google apps then i will fetch the mails to
my localserver and user will send mail to outside from the localserver
relaying through Google apps. Two virtual domains are configured in the
server and users are created in the ldap. I have created the user in the
ldap for which the mail has to be fetched but we have some more users in
our domain. When we try to send the mails to other users it is not
sending to Google apps instead the mailserver is giving User unknown in
virtual mailbox table as the user is not present in the ldap. Is there
a way to configure my postfix server to forward all the user unknown
mails for the virtual domains to the Google apps. 

-- 
Rgds,

Aravind M
D
aravind.divaka...@yukthi.com
Helpdesk Team
Yukthi Systems Pvt Ltd
Ph:-
08042351119 08042351120