Speeding up Local Delivery

[Wendigo Thompson]

Hello:

  I maintain for a large client a Postfix/MySQL installation that
archives certain messages required to be held for compliance with
lawsuits and employment litigation.  Postfix accepts mail from the
corporate mail server and delivers the message via a pipe alias to an
application that is then inserting the message into the database.
Recently for a large litigation matter, all mail at this company (300k
messages/day) was required to be held.  The server is mostly doing
fine, but I have noticed that during peak delivery times Postfix will
queue large amounts of mail and be slow at delivering it to the
script/database -- sometimes queueing mail all the way to the weekend,
when things are less busy.  I've watched the time it takes from
Postfix opening the application and sending the data and each message
is taking ~0.003 seconds.  It seems that if I could coax Postfix into
sending more messages to that pipe I wouldn't have queueing issues
during work days.

  I've tuned the concurrency_limits from their defaults upward in
steps of 5 (up to 36 now) without much luck -- I only ever seem to be
able to achieve ~5 deliveries per second. I'd appreciate any guidance
the gurus have to offer.  FWIW, it's 2.4.3 on Mac OS X Server 10.5.

Thanks,
Wendy

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Frank Cusack]

On January 12, 2010 5:59:58 PM -0500 Victor Duchovni 
 wrote:

You latched onto a red-herring, it is far wiser to report accurate
symptoms than to speculate about theoretical causes of unreported
behaviour.


Sure, and that's the reason I started 2 threads.

I thought my first one was totally legitimate regardless of the cause
of this specific problem, and what actually set me off the wrong way
was someone else's comments.  I should know better than to get sucked
in like that.

I think it all ended well though?  Except my problem still exists. :\

-frank

Re: SMTP AUTH issue

[Noah Sheppard]

On Wed, Jan 13, 2010 at 05:21:09AM +0530, Atevewr wrote:
> [..]
> If smtp authentication is on & the client connects through a EHLO
> session, then the authentication goes fine and the user is
> authenticated, but if he connects through a simple HELO session, then
> he is able to send a mail without any authentication?
> How can i disable the HELO command or basically only allow EHLO sessions?

>From what you've said, it sounds like you actually just want to prevent
sending mail without authentication.  If that is the case, use

smtpd_client_restrictions = permit_sasl_authenticated, reject

Only authenticated clients will be allowed to send mail.

Cheers,
-- 
Noah Sheppard
Assistant Computer Resource Manager
Taylor University CSE Department
nshep...@cse.taylor.edu

SMTP AUTH issue

[Atevewr]

Dear All,
I want to ask a simple question regarding smtp authentication.
(Assuming that the user is not in my trusted networks)
If smtp authentication is on & the client connects through a EHLO
session, then the authentication goes fine and the user is
authenticated, but if he connects through a simple HELO session, then
he is able to send a mail without any authentication?
How can i disable the HELO command or basically only allow EHLO sessions?

Thanks in advance!

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Victor Duchovni]

On Tue, Jan 12, 2010 at 03:47:57PM -0500, Frank Cusack wrote:

>> Don't use "reject_unknown_client_hostname" indiscriminantly. Do so only
>> for CIDR blocks in which you find a small number of legitimate MTAs in a
>> larger pool of spam sending hosts without valid PTR records.
>
> In my case, I don't have reject_unknown_client_hostname configured.
> Here is my postconf -n, also in my other thread on my problem:

In that case Postfix is completely agnostic about the DNS PTR records.
Now use tcpdump to verify that the client disconnects either before
it sees the 220 banner from Postfix, or just after with no negative
feedback from Postfix.

Far more likely the client's firewall does not properly ECN, or window
scaling or some other modern feature of your TCP stack.

When a client disconnects "after CONNECT", Postfix never saw a HELO/EHLO
from the client, so no real SMTP dialogue took place. This is almost
always TCP/firewall issues, resolved in the same way as with other layer
3/4 issues.

>> Postfix does not by default reject clients with mismatched forward/reverse
>> DNS. Do not enable this feature for all IPs, it is not recomended. With
>> or without multiple PTRs, plenty of valid MTAs have various DNS issues.
>
> It doesn't seem my configuration is doing that?  I know I am not
> intentionally doing it, that's for sure.  I could care less if PTR matched.
> But that is the distinguishing factor for this host trying to send me
> mail, which is why I latched onto it.

You latched onto a red-herring, it is far wiser to report accurate symptoms
than to speculate about theoretical causes of unreported behaviour.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: client disconnects at CONNECT (multiple PTR problem?)

[/dev/rob0]

On Tue, Jan 12, 2010 at 03:16:53PM -0600, Noel Jones wrote:
> On 1/12/2010 3:05 PM, Frank Cusack wrote:
> >On January 12, 2010 2:49:32 PM -0600 "/dev/rob0"  
> >wrote:
> >>reject_unauth_pipelining won't work here, only in
> >>smtpd_data_restrictions
> >
> >reject_unauth_pipelining
[snip]
> With postfix 2.6 and newer, reject_unauth_piplining works fine in
> any smtpd_*_restrictions stage.
> 
> And like the last sentence says, with versions earlier than 2.6,
> that restriction is only effective in smtpd_data_restrictions.

Thanks for the correction, Frank and Noel; I was going from memory
rather than consulting the up-to-date documentation. Sorry. I'll
spend some time in the release notes as penance. :)
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: client disconnects at CONNECT (multiple PTR problem?)

[Noel Jones]

On 1/12/2010 3:33 PM, Frank Cusack wrote:

On January 12, 2010 3:10:12 PM -0600 Noel Jones 
wrote:

Postfix uses system libraries for DNS lookups. You can test your system
using the same calls with the tools in the auxiliary/name-addr-test
directory in the postfix source.
These aren't built by default; example compile command
# cc -o gethostbyaddr gethostbyaddr.c

If any of these tools crash or give "unexpected" results, there's a
problem with your system libraries; contact your OS vendor.


Thanks, I'll pursue that. I didn't initially think it would be
worthwhile because you'll notice in the log that the pid of smtpd
remains the same. I figured if the host resolver was returning
something bad (causing a crash), that master (or whatever process)
would report the problem rather than smtpd logging a disconnect.


No, I don't think postfix is crashing either. And I don't 
really expect to find a library problem.


Absent other evidence, I think the client disconnected for 
reasons known only to the client.


  -- Noel Jones

Re: multiple PTR records

[Noel Jones]

On 1/12/2010 3:19 PM, Frank Cusack wrote:

On January 12, 2010 2:52:58 PM -0600 Stan Hoeppner
 wrote:

Frank Cusack put forth on 1/12/2010 2:29 PM:

Is it your opinion that the disadvantages I've described aren't valid?


When it comes to multiple PTRs on a single email emitting IP, yes, it is
my opinion that that the disadvantages you describe are not valid. As a
matter of fact, I don't know of a scenario that would *require* an email
emitting IP to have multiple PTRs. Can you post such a scenario?


I can't think of a scenario for ANY type of server that would *require*
multiple PTR records. Not that they are infallible, but certainly
neither did the presumably smarter-than-any-of-us guys that designed
the new IPv6-friendlier getinfo() interfaces.

But I also can't think of a reason to not handle it.

-frank



Postfix supports clients with multiple PTR records just fine. 
 It does not crash, disconnect, error, or in any other way 
not handle them.


Postfix does not do insane things such as walk through all the 
PTRs looking for one that's not "unknown", nor does postfix 
enumerate all possible hostnames for access table lookups.


Test your system library handling of the client as suggested 
earlier.  I fully expect it to work just fine.  Assuming it 
does work just fine, the problem is the client, not the PTR 
records.


I'm quite confidant the the multiple PTR issue is a red 
herring for a client that's broken in some other way. 
Everyone else seems to be able to receive mail from such 
clients just fine.


  -- Noel Jones

Re: client disconnects at CONNECT (multiple PTR problem?)

[Frank Cusack]

On January 12, 2010 3:10:12 PM -0600 Noel Jones  
wrote:

On 1/12/2010 2:02 PM, Frank Cusack wrote:

My postfix-2.6.5 is rejecting mail from a host which has a large
PTR RRset -- 44 entries and large enough to require TCP.
host/dig/nslookup actually dumps core on my solaris box (looks like
the bug was fixed in BIND just a few months ago). I don't know for
sure that it is the PTR records that are causing the problem because
all I get in the log is

Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
connect from unknown[1.2.3.4]
Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] lost
connection after CONNECT from unknown[1.2.3.4]
Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
disconnect from unknown[1.2.3.4]


This looks as if the client disconnected.

Postfix uses system libraries for DNS lookups.  You can test your system
using the same calls with the tools in the auxiliary/name-addr-test
directory in the postfix source.
These aren't built by default; example compile command
# cc -o gethostbyaddr gethostbyaddr.c

If any of these tools crash or give "unexpected" results, there's a
problem with your system libraries; contact your OS vendor.


Thanks, I'll pursue that.  I didn't initially think it would be
worthwhile because you'll notice in the log that the pid of smtpd
remains the same.  I figured if the host resolver was returning
something bad (causing a crash), that master (or whatever process)
would report the problem rather than smtpd logging a disconnect.

The tools I noted above that are crashing are not part of the OS and
do not use the system resolver, so I didn't consider that necessarily
a bad sign for postfix.


If all the tools work, then the assumption from here is the client
disconnected -- not a postfix problem.

You might get more information with a network sniffer.
http://www.postfix.org/DEBUG_README.html#sniffer


I did a packet capture (with snaplen 1500) and it revealed nothing
interesting.  Well, other than the fact that postfix does a DNS
query before the disconnect occurs -- obviously, since it at least
wants to log the hostname.

-frank

Re: multiple PTR records

[Frank Cusack]

On January 12, 2010 2:52:58 PM -0600 Stan Hoeppner  
wrote:

Frank Cusack put forth on 1/12/2010 2:29 PM:

Is it your opinion that the disadvantages I've described aren't valid?


When it comes to multiple PTRs on a single email emitting IP, yes, it is
my opinion that that the disadvantages you describe are not valid.  As a
matter of fact, I don't know of a scenario that would *require* an email
emitting IP to have multiple PTRs.  Can you post such a scenario?


I can't think of a scenario for ANY type of server that would *require*
multiple PTR records.  Not that they are infallible, but certainly
neither did the presumably smarter-than-any-of-us guys that designed
the new IPv6-friendlier getinfo() interfaces.

But I also can't think of a reason to not handle it.

-frank

Re: client disconnects at CONNECT (multiple PTR problem?)

[Noel Jones]

On 1/12/2010 3:05 PM, Frank Cusack wrote:

On January 12, 2010 2:49:32 PM -0600 "/dev/rob0"  wrote:



reject_unauth_pipelining won't work here, only in
smtpd_data_restrictions


reject_unauth_pipelining
Reject the request when the client sends SMTP commands ahead of time
where it is not allowed, or when the client sends SMTP commands ahead
of time without knowing that Postfix actually supports ESMTP command
pipelining. This stops mail from bulk mail software that improperly
uses ESMTP command pipelining in order to speed up deliveries.
With Postfix 2.6 and later, the SMTP server sets a per-session flag
whenever it detects illegal pipelining, including pipelined EHLO or
HELO commands. The reject_unauth_pipelining feature simply tests
whether the flag was set at any point in time during the session.
With older Postfix versions, reject_unauth_pipelining checks
the current status of the input read queue, and its usage is not
recommended in contexts other than smtpd_data_restrictions.

I especially point you to the last paragraph.

The reference to EHLO/HELO, and the reference to support in older versions
hints to me it should be in the helo section? Not correct?



With postfix 2.6 and newer, reject_unauth_piplining works fine 
in any smtpd_*_restrictions stage.


And like the last sentence says, with versions earlier than 
2.6, that restriction is only effective in 
smtpd_data_restrictions.


So if you have postfix 2.6 or newer, it's fine to put it in 
the helo section.


  -- Noel Jones

Re: client disconnects at CONNECT (multiple PTR problem?)

[Noel Jones]

On 1/12/2010 2:02 PM, Frank Cusack wrote:

My postfix-2.6.5 is rejecting mail from a host which has a large
PTR RRset -- 44 entries and large enough to require TCP.
host/dig/nslookup actually dumps core on my solaris box (looks like
the bug was fixed in BIND just a few months ago). I don't know for
sure that it is the PTR records that are causing the problem because
all I get in the log is

Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
connect from unknown[1.2.3.4]
Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] lost
connection after CONNECT from unknown[1.2.3.4]
Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
disconnect from unknown[1.2.3.4]


This looks as if the client disconnected.

Postfix uses system libraries for DNS lookups.  You can test 
your system using the same calls with the tools in the 
auxiliary/name-addr-test directory in the postfix source.

These aren't built by default; example compile command
# cc -o gethostbyaddr gethostbyaddr.c

If any of these tools crash or give "unexpected" results, 
there's a problem with your system libraries; contact your OS 
vendor.


If all the tools work, then the assumption from here is the 
client disconnected -- not a postfix problem.


You might get more information with a network sniffer.
http://www.postfix.org/DEBUG_README.html#sniffer

  -- Noel Jones

Re: client disconnects at CONNECT (multiple PTR problem?)

[Frank Cusack]

On January 12, 2010 2:49:32 PM -0600 "/dev/rob0"  wrote:

On Tue, Jan 12, 2010 at 03:02:37PM -0500, Frank Cusack wrote:

My postfix-2.6.5 is rejecting mail from a host which has a large


Not according to what we see below. "Lost connection" does not mean
you rejected them.


Quite.  That should have been obvious to me but I guess not!


smtpd_data_restrictions = reject_multi_recipient_bounce  permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
reject_unauth_pipelining reject_invalid_helo_hostname


reject_unauth_pipelining won't work here, only in
smtpd_data_restrictions


reject_unauth_pipelining
   Reject the request when the client sends SMTP commands ahead of time
   where it is not allowed, or when the client sends SMTP commands ahead
   of time without knowing that Postfix actually supports ESMTP command
   pipelining. This stops mail from bulk mail software that improperly
   uses ESMTP command pipelining in order to speed up deliveries.
   With Postfix 2.6 and later, the SMTP server sets a per-session flag
   whenever it detects illegal pipelining, including pipelined EHLO or
   HELO commands. The reject_unauth_pipelining feature simply tests
   whether the flag was set at any point in time during the session.
   With older Postfix versions, reject_unauth_pipelining checks
   the current status of the input read queue, and its usage is not
   recommended in contexts other than smtpd_data_restrictions.

I especially point you to the last paragraph.

The reference to EHLO/HELO, and the reference to support in older versions
hints to me it should be in the helo section? Not correct?


smtpd_recipient_restrictions = reject_non_fqdn_sender
reject_unknown_sender_domain  reject_non_fqdn_recipient
reject_unknown_recipient_domain  permit_mynetworks
check_sender_access dbm:/etc/postfix/sender_access


check_sender_access looks up the MAIL FROM address (or the domain, or
the localpart), see SMTPD_ACCESS_README.html and access.5.html for
details.


Yeah, I knew that. :)  I guess it was stupid to try whitelisting them
at that point.


reject_unauth_destination reject_non_fqdn_hostname
reject_invalid_hostname check_sender_mx_access
cidr:/etc/postfix/bogus_mx reject_rhsbl_sender
dsn.rfc-ignorant.org reject_rhsbl_sender bogusmx.rfc-ignorant.org
reject_rhsbl_sender zen.spamhaus.org
reject_rhsbl_sender bl.spamcop.net permit


Zen and spamcop are not RHSBL services. You're bugging them with
queries that will never match anything. I would suggest that you
consider "reject_rbl_client zen.spamhaus.org", however.


Thanks, I never would have realized that.

-frank

Re: multiple PTR records

[Stan Hoeppner]

Frank Cusack put forth on 1/12/2010 2:29 PM:

> Not to be rude, but I'm not sure why you asked me the question in the
> first place.  It was in fact a great question.  Your response however
> was merely to dismiss my problem.  So it seems like your question was
> just rhetoric designed to sink this discussion into non-technical mush.
> I apologize if that wasn't your intent.

Initially I shoved back a bit I guess because you seemed to enter in attack mode
with fangs out ripping Postfix a new one, so to speak.  I think you were
probably just venting frustration, which is understandable.  I thought I was
pretty restrained. ;)

> Is it your opinion that the disadvantages I've described aren't valid?

When it comes to multiple PTRs on a single email emitting IP, yes, it is my
opinion that that the disadvantages you describe are not valid.  As a matter of
fact, I don't know of a scenario that would *require* an email emitting IP to
have multiple PTRs.  Can you post such a scenario?

-- 
Stan

Re: client disconnects at CONNECT (multiple PTR problem?)

[/dev/rob0]

On Tue, Jan 12, 2010 at 03:02:37PM -0500, Frank Cusack wrote:
> My postfix-2.6.5 is rejecting mail from a host which has a large

Not according to what we see below. "Lost connection" does not mean
you rejected them.

> PTR RRset -- 44 entries and large enough to require TCP. 
> host/dig/nslookup actually dumps core on my solaris box (looks like 
> the bug was fixed in BIND just a few months ago).  I don't know for 
> sure that it is the PTR records that are causing the problem 
> because all I get in the log is

Coincidence, I would guess. Possibly tangentially related in that
this site's administrator might have tried something else that's as
silly as the multiple PTRs. :) This is almost surely something at
layer 2 or 3.

> Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
> connect from unknown[1.2.3.4]
> Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
> lost connection after CONNECT from unknown[1.2.3.4]
> Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info]
> disconnect from unknown[1.2.3.4]
> 
> I'm not sure what part of my postfix config to even look at since 
> the log message is fairly uninformative.  Or more importantly, how 
> to whitelist their MX host.  (I haven't yet reviewed Victor's 
> recent mail on that.)

Whitelisting won't keep the connection from dropping.

> I tried putting then in sender_access but apparently postfix 
> doesn't get that far.  Here are the significant parts of postconf 

You're using sender_access as a check_sender_access lookup (good, the
name and function are related.) However, you would want to use a
check_client_access lookup to whitelist a client. But see above, that
won't address the issue at hand.

> smtpd_data_restrictions = reject_multi_recipient_bounce  permit
> smtpd_helo_required = yes
> smtpd_helo_restrictions = permit_mynetworks
> reject_unauth_pipelining reject_invalid_helo_hostname

reject_unauth_pipelining won't work here, only in
smtpd_data_restrictions

> reject_non_fqdn_helo_hostname

> smtpd_recipient_restrictions = reject_non_fqdn_sender
> reject_unknown_sender_domain  reject_non_fqdn_recipient
> reject_unknown_recipient_domain  permit_mynetworks
> check_sender_access dbm:/etc/postfix/sender_access

check_sender_access looks up the MAIL FROM address (or the domain, or
the localpart), see SMTPD_ACCESS_README.html and access.5.html for
details.

> reject_unauth_destination reject_non_fqdn_hostname 
> reject_invalid_hostname check_sender_mx_access 
> cidr:/etc/postfix/bogus_mx reject_rhsbl_sender
> dsn.rfc-ignorant.org reject_rhsbl_sender bogusmx.rfc-ignorant.org 
> reject_rhsbl_sender zen.spamhaus.org
> reject_rhsbl_sender bl.spamcop.net permit

Zen and spamcop are not RHSBL services. You're bugging them with
queries that will never match anything. I would suggest that you
consider "reject_rbl_client zen.spamhaus.org", however.

Since you munged the name/IP of the peer with which you were having
problems, there's not anything more we can do here.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Frank Cusack]

On January 12, 2010 1:33:46 PM -0500 Victor Duchovni 
 wrote:

On Tue, Jan 12, 2010 at 01:12:52PM -0500, Frank Cusack wrote:


I can't accept mail from hosts with multiple PTR records without manually
whitelisting them.  Additionally, I can't even tell that I'm experiencing
a failure until it is reported to me "manually" and out of band.


Don't use "reject_unknown_client_hostname" indiscriminantly. Do so only
for CIDR blocks in which you find a small number of legitimate MTAs in a
larger pool of spam sending hosts without valid PTR records.


In my case, I don't have reject_unknown_client_hostname configured.
Here is my postconf -n, also in my other thread on my problem:

mydestination =
mynetworks = 127.0.0.0/8
myorigin = foo.com
recipient_delimiter = +
relay_domains = foo.com
relay_recipient_maps = dbm:/etc/postfix/relay_recipients
smtpd_data_restrictions = reject_multi_recipient_bounce  permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks  reject_unauth_pipelining 
reject_invalid_helo_hostname  reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = reject_non_fqdn_sender 
reject_unknown_sender_domain  reject_non_fqdn_recipient 
reject_unknown_recipient_domain  permit_mynetworks  check_sender_access 
dbm:/etc/postfix/sender_access  reject_unauth_destination 
reject_non_fqdn_hostname  reject_invalid_hostname  check_sender_mx_access 
cidr:/etc/postfix/bogus_mx  reject_rhsbl_sender dsn.rfc-ignorant.org 
reject_rhsbl_sender bogusmx.rfc-ignorant.org  reject_rhsbl_sender 
zen.spamhaus.org  reject_rhsbl_sender bl.spamcop.net  permit

smtpd_reject_unlisted_sender = yes
transport_maps = dbm:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = dbm:/etc/postfix/virtual

suggestion: have postconf -n use multiline output like
 smtpd_helo_restrictions = 1
   2
   3


Postfix does not by default reject clients with mismatched forward/reverse
DNS. Do not enable this feature for all IPs, it is not recomended. With
or without multiple PTRs, plenty of valid MTAs have various DNS issues.


It doesn't seem my configuration is doing that?  I know I am not
intentionally doing it, that's for sure.  I could care less if PTR matched.
But that is the distinguishing factor for this host trying to send me
mail, which is why I latched onto it.

-frank

Re: multiple PTR records

[Frank Cusack]

On January 12, 2010 12:28:10 PM -0600 Stan Hoeppner 
 wrote:

Frank Cusack put forth on 1/12/2010 12:12 PM:

On January 12, 2010 12:09:28 PM -0600 Stan Hoeppner
 wrote:

Frank Cusack put forth on 1/12/2010 12:04 PM:


I don't know why you would thank Wietse when there is no disadvantage
to accepting multiple PTR records.  There is only a downside.


What's the downside Frank?


Good question.

I can't accept mail from hosts with multiple PTR records without manually
whitelisting them.  Additionally, I can't even tell that I'm experiencing
a failure until it is reported to me "manually" and out of band.


Have you tried Sendmail, Exim, Qmail and/or other MTAs?  Do any/all of
them handle this "problem" "correctly" for you?  If so, why are you not
using them, instead of asking Wietse to "fix" something that he (and most
others) don't consider "broken"?

I'm somewhat new to the game.  I've only been running Postfix since Q4
'05.  In that time I can't recall ever having the issue you describe.


If you are new to the game, why are you cheerleading?  What you are asking
me reminds me of a typical response to US government dissenters.  "Sit
down and shut up, or leave the country", essentially.  The US is powerful
(for one reason) because of our ability to freely dissent, and open source
software is powerful because of its open nature.

I have been a user of postfix since the time it was vmailer.  I was even
at a talk Wietse gave on it in NYC.  I have also used sendmail since 4.x
(even using it to gateway UUCP) and have also extensively used and
customized qmail (ugh).  Exim is the only major unix MTA I don't have
significant experience with.

I don't know if the other MTAs work with this problem, but to answer your
question the reason I use postfix is the reason I used it from the
beginning: it is the best.  And I understand fully why that is -- I didn't
just read somewhere that it is preferred.  The reason I ask people to "fix"
it is because I want the most utility out of the software I use.  And also
because local patches are always a PITA to maintain.


 It
sounds like you have this problem often.  Why is that?  Who are all of
these sites/orgs sending you mail from hosts with multiple PTRs?  Can you
cite a few examples of such hosts so I can investigate?


I don't have this problem often.  In fact this is the very first time I've
ever come across it.  I'd simply ignore it however the other party is
absolutely critical to us.  I can't give an example because it would
give up my relative anonymity.

Not to be rude, but I'm not sure why you asked me the question in the
first place.  It was in fact a great question.  Your response however
was merely to dismiss my problem.  So it seems like your question was
just rhetoric designed to sink this discussion into non-technical mush.
I apologize if that wasn't your intent.

Is it your opinion that the disadvantages I've described aren't valid?

-frank

client disconnects at CONNECT (multiple PTR problem?)

[Frank Cusack]

My postfix-2.6.5 is rejecting mail from a host which has a large
PTR RRset -- 44 entries and large enough to require TCP.
host/dig/nslookup actually dumps core on my solaris box (looks like
the bug was fixed in BIND just a few months ago).  I don't know for
sure that it is the PTR records that are causing the problem because
all I get in the log is

Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] connect 
from unknown[1.2.3.4]
Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] lost 
connection after CONNECT from unknown[1.2.3.4]
Jan 12 11:14:42 x.y.z postfix/smtpd[29691]: [ID 197553 mail.info] 
disconnect from unknown[1.2.3.4]


I'm not sure what part of my postfix config to even look at since the
log message is fairly uninformative.  Or more importantly, how to whitelist
their MX host.  (I haven't yet reviewed Victor's recent mail on that.)
I tried putting then in sender_access but apparently postfix doesn't get
that far.  Here are the significant parts of postconf -n:

mydestination =
mynetworks = 127.0.0.0/8
myorigin = foo.com
recipient_delimiter = +
relay_domains = foo.com
relay_recipient_maps = dbm:/etc/postfix/relay_recipients
smtpd_data_restrictions = reject_multi_recipient_bounce  permit
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks  reject_unauth_pipelining 
reject_invalid_helo_hostname  reject_non_fqdn_helo_hostname
smtpd_recipient_restrictions = reject_non_fqdn_sender 
reject_unknown_sender_domain  reject_non_fqdn_recipient 
reject_unknown_recipient_domain  permit_mynetworks  check_sender_access 
dbm:/etc/postfix/sender_access  reject_unauth_destination 
reject_non_fqdn_hostname  reject_invalid_hostname  check_sender_mx_access 
cidr:/etc/postfix/bogus_mx  reject_rhsbl_sender dsn.rfc-ignorant.org 
reject_rhsbl_sender bogusmx.rfc-ignorant.org  reject_rhsbl_sender 
zen.spamhaus.org  reject_rhsbl_sender bl.spamcop.net  permit

smtpd_reject_unlisted_sender = yes
transport_maps = dbm:/etc/postfix/transport
unknown_local_recipient_reject_code = 550
virtual_alias_maps = dbm:/etc/postfix/virtual

And, I hope you got down this far, I set the debug_peer_level to 2 for
this host and don't get much help:

Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] connect from 
unknown[1.2.3.4]
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] match_hostaddr: 
1.2.3.4 ~? 127.0.0.0/8
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] 
match_list_match: 1.2.3.4: no match
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] send attr ident 
= smtp:1.2.3.4
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] > 
unknown[1.2.3.4]: 220 ESMTP Postfix
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] match_hostaddr: 
1.2.3.4 ~? 127.0.0.0/8
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] 
match_list_match: 1.2.3.4: no match
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] send attr ident 
= smtp:1.2.3.4
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] lost connection 
after CONNECT from unknown[1.2.3.4]
Jan 12 14:34:27 postfix/smtpd[4318]: [ID 197553 mail.info] disconnect from 
unknown[1.2.3.4]


-frank

Re: Postfix as an MTA question

[mouss]

Bucl, Casper a écrit :
> Hi,
> 
> I’m trying to use Postfix as an MTA. I don’t want to deliver any mail
> locally, just relay everything to an external mail server. I would also
> like everything that runs though this MTA to be sent as a particular
> user, however I don’t want messages intended for users on the system
> such as root to be delivered. I have gotten everything to work except I
> am getting messages for the root user sent to the sendas address. If the
> system users have to be delivered, that is fine, I can just use the
> aliases to redirect them to a single user and then deal with the mail
> there. I would prefer that they go to a black hole though. I’ve been
> trying to find a solutions to this for some time now and haven’t been
> successful so far. Any direction you can provide is appreciated.
> 

It looks like you want:

http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall


> [snip]

Re: Challenge/Response

[Stan Hoeppner]

Noel Jones put forth on 1/12/2010 12:50 PM:
> On 1/12/2010 12:39 PM, Aaron Clausen wrote:
>> Are challenge response systems still heavily frowned on?
>>
> 
> Yes.

Yes.

-- 
Stan

Re: Challenge/Response

[Noel Jones]

On 1/12/2010 12:39 PM, Aaron Clausen wrote:

Are challenge response systems still heavily frowned on?



Yes.

Re: Challenge/Response

[Victor Duchovni]

On Tue, Jan 12, 2010 at 10:39:16AM -0800, Aaron Clausen wrote:

> Are challenge response systems still heavily frowned on?

Yes. This is how I explain spam filtering of C/R requests to
my users:

The attached message was reported by you as a quarantine error.

Sadly, challenge/response anti-spam systems are in turn significant
contributors to the spam volume on the Internet, because spammers
and viruses forge the sender addresses of email, and users who never
sent mail get challenged to prove their intent to send mail they
never sent.

When you find challenges in the quarantine in response to email
you actually sent, by all means release them and respond.  If it
is not inappropriate to do so, perhaps you could suggest to the
recipient that such systems are not a socially responsible way to
stop unwanted email.

Either the sender is unforged and not a spammer, and the challenge
is an unnecessary hurdle, or the sender was forged and the challenge
is unwarranted junk mail. Thus challenge-response anti-spam systems
are always wrong.

Thank you for taking the time to report quarantine errors, while this
type of message will continue to be blocked in the future, we are
in most other cases successful in getting erroneous identification
of legitimate mail to stop.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Challenge/Response

[Aaron Clausen]

Are challenge response systems still heavily frowned on?

-- 
Aaron Clausen
mightymartia...@gmail.com

How to not reject valid MTAs for inconsistent forward/reverse DNS.

[Victor Duchovni]

On Tue, Jan 12, 2010 at 01:12:52PM -0500, Frank Cusack wrote:

> I can't accept mail from hosts with multiple PTR records without manually
> whitelisting them.  Additionally, I can't even tell that I'm experiencing
> a failure until it is reported to me "manually" and out of band.

Don't use "reject_unknown_client_hostname" indiscriminantly. Do so only for
CIDR blocks in which you find a small number of legitimate MTAs in a larger
pool of spam sending hosts without valid PTR records.

main.cf:
smtpd_client_restrictions =
check_client_access cidr:${config_directory}/client_access.cidr

client_access.cidr:
192.0.2.0/24reject_unknown_client_hostname
# More conservative:
# 192.0.2.0/24  reject_unknown_reverse_client_hostname

Postfix does not by default reject clients with mismatched forward/reverse
DNS. Do not enable this feature for all IPs, it is not recomended. With
or without multiple PTRs, plenty of valid MTAs have various DNS issues.

Plenty of MTAs with multiple PTRs pass the restriction, provided all
the names resolve to the same IP. It is not the PTR count, but the
consistency with the IP that's important. This is not an invitation
to debate DNS. Just a clarification of the semantics of
"reject_unknown_client_hostname".

Also consider "reject_unknown_reverse_client_hostname", which only tests
existence of PTR records, not their consistency with any forward DNS.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: multiple PTR records

[Stan Hoeppner]

Frank Cusack put forth on 1/12/2010 12:12 PM:
> On January 12, 2010 12:09:28 PM -0600 Stan Hoeppner
>  wrote:
>> Frank Cusack put forth on 1/12/2010 12:04 PM:
>>
>>> I don't know why you would thank Wietse when there is no disadvantage
>>> to accepting multiple PTR records.  There is only a downside.
>>
>> What's the downside Frank?
> 
> Good question.
> 
> I can't accept mail from hosts with multiple PTR records without manually
> whitelisting them.  Additionally, I can't even tell that I'm experiencing
> a failure until it is reported to me "manually" and out of band.

Have you tried Sendmail, Exim, Qmail and/or other MTAs?  Do any/all of them
handle this "problem" "correctly" for you?  If so, why are you not using them,
instead of asking Wietse to "fix" something that he (and most others) don't
consider "broken"?

I'm somewhat new to the game.  I've only been running Postfix since Q4 '05.  In
that time I can't recall ever having the issue you describe.  It sounds like you
have this problem often.  Why is that?  Who are all of these sites/orgs sending
you mail from hosts with multiple PTRs?  Can you cite a few examples of such
hosts so I can investigate?

-- 
Stan

Re: THREAD STILL CLOSED: (was Re: multiple PTR records)

[Frank Cusack]

On January 12, 2010 1:10:51 PM -0500 Victor Duchovni 
 wrote:

If you have a specific use case in which you need guidance to configure
Postfix, please start a new thread, without the polemics.


That is why I stated originally, for my specific problem case I will be
writing in another thread.  I am still collecting debug info so I haven't
sent that mail yet.  Because I have to interact with another mailhost,
out of my control, it's slow going.


If you just want to vent, please do it somewhere else.


Vent?  Did you read my messages?  I am not venting.  I am asking a
legitimate question (to which I could not find previous resolution on)
and furthermore I resent your use of the words "polemics" and "vent"
in reference to my emails on the subject.

You are being dismissive which is totally unfair.

-frank

Re: multiple PTR records

[Frank Cusack]

On January 12, 2010 12:09:28 PM -0600 Stan Hoeppner 
 wrote:

Frank Cusack put forth on 1/12/2010 12:04 PM:


I don't know why you would thank Wietse when there is no disadvantage
to accepting multiple PTR records.  There is only a downside.


What's the downside Frank?


Good question.

I can't accept mail from hosts with multiple PTR records without manually
whitelisting them.  Additionally, I can't even tell that I'm experiencing
a failure until it is reported to me "manually" and out of band.

-frank

THREAD STILL CLOSED: (was Re: multiple PTR records)

[Victor Duchovni]

On Tue, Jan 12, 2010 at 01:04:56PM -0500, Frank Cusack wrote:

> On January 12, 2010 12:24:20 PM -0500 Frank Cusack  
> wrote:
>> Apparently it only "honors" the first PTR record that getnameinfo()
>> returns to it.  Additionally this appears to be a conscious decision
>> and in part designed to impose postfix's sense of order on the world.
>
> Well, I see part of the problem which is that if postfix does use
> getnameinfo(), it can only get 1 of the PTR records.  The supposedly
> superior getnameinfo() can only return a single entry.
>
> On January 12, 2010 11:53:15 AM -0600 Robert Fournerat  
> wrote:
>> In this case at least, I think, "postfix's sense of order on the
>> world" is correct.  Thank you Wietse (et al) for doing this.
>
> Thank you for making my life hell!
>
> Postfix's sense of order may be philosophically correct, but it is not
> consistent with the RFCs, so postfix is wrong.  It is also counter
> to the well established design philosophy, be liberal in what you accept.

THIS THREAD IS CLOSED.

If you have a specific use case in which you need guidance to configure
Postfix, please start a new thread, without the polemics.

If you just want to vent, please do it somewhere else.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: multiple PTR records

[Stan Hoeppner]

Frank Cusack put forth on 1/12/2010 12:04 PM:

> I don't know why you would thank Wietse when there is no disadvantage
> to accepting multiple PTR records.  There is only a downside.

What's the downside Frank?

-- 
Stan

Re: multiple PTR records

[Frank Cusack]

On January 12, 2010 12:24:20 PM -0500 Frank Cusack  
wrote:

Apparently it only "honors" the first PTR record that getnameinfo()
returns to it.  Additionally this appears to be a conscious decision
and in part designed to impose postfix's sense of order on the world.


Well, I see part of the problem which is that if postfix does use
getnameinfo(), it can only get 1 of the PTR records.  The supposedly
superior getnameinfo() can only return a single entry.

On January 12, 2010 11:53:15 AM -0600 Robert Fournerat  
wrote:

In this case at least, I think, "postfix's sense of order on the
world" is correct.  Thank you Wietse (et al) for doing this.


Thank you for making my life hell!

Postfix's sense of order may be philosophically correct, but it is not
consistent with the RFCs, so postfix is wrong.  It is also counter
to the well established design philosophy, be liberal in what you accept.

Note: I agree that a single PTR record is better.  My opinion is
irrelevant.

I don't know why you would thank Wietse when there is no disadvantage
to accepting multiple PTR records.  There is only a downside.

-frank

Re: multiple PTR records

[Robert Fournerat]

Quoting Frank Cusack :



Apparently it only "honors" the first PTR record that getnameinfo()
returns to it.  Additionally this appears to be a conscious decision
and in part designed to impose postfix's sense of order on the world.



-frank


In this case at least, I think, "postfix's sense of order on the
world" is correct.  Thank you Wietse (et al) for doing this.

Robert



This message was sent using IMP, the Internet Messaging Program.

Re: multiple PTR records

[Frank Cusack]

On January 12, 2010 11:07:25 AM -0600 "/dev/rob0"  wrote:

It's hard to focus on what you said when we don't know what you
said. :)


I thought it was pretty clear. :)


On Tue, Jan 12, 2010 at 11:27:43AM -0500, Frank Cusack wrote:

After searching the mailing list (and the web in general) what I
can gather about multiple PTR records is that postfix is adamant
that hosts should not have multiple PTR records.

Who cares?


In other words,

Why does postfix not handle hosts with multiple PTR records correctly?
Apparently it only "honors" the first PTR record that getnameinfo()
returns to it.  Additionally this appears to be a conscious decision
and in part designed to impose postfix's sense of order on the world.

I'm not entirely sure my idea of what postfix is doing with multiple
PTR records is correct, like I said it's just what I've gathered from
recent discussion.  Since you didn't refute my first paragraph I
figure my guess is correct.

-frank

Re: multiple PTR records

[/dev/rob0]

On Tue, Jan 12, 2010 at 11:27:43AM -0500, Frank Cusack wrote:
> After searching the mailing list (and the web in general) what I 
> can gather about multiple PTR records is that postfix is adamant 
> that hosts should not have multiple PTR records.
> 
> Who cares?  It's like saying DNS names should not have underscores
> or spaces.

Indeed, the DNS standards allow PTR records to coexist with other
PTRs and other RR types. If you're delegated some in-addr.arpa.
zones, you can in fact put any and all RR types in them. What the
resolver clients may or may not do with those records is another
issue altogether.

Furthermore, you're not even limited to the naming of your records.
If you have 2.0.192.in-addr.arpa., you can have records with any
legal name: rob0.2.0.192.in-addr.arpa. wacky.2.0.192.in-addr.arpa.,
whatever strikes your fancy, and $INCLUDE above re: resolvers.

> Yes we don't like it, but it's easy for postfix to accept and deal 
> with it.  OTOH, it's difficult to get OTHER admins to fix their 
> configuration and additionally it doesn't actually create a problem 
> that I can see.
> 
> I'll post my actual problem in another thread, to keep this one 
> focused on the policy around multiple PTR records.

I don't understand. Are you asking a question about how Postfix
handles the case when multiple PTRs are found for a single IP
address? That was discussed here fairly recently. Or are you
advocating a change in how this case should be handled?

It's hard to focus on what you said when we don't know what you
said. :)
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

THREAD CLOSED: (was Re: multiple PTR records)

[Victor Duchovni]

On Tue, Jan 12, 2010 at 11:27:43AM -0500, Frank Cusack wrote:

> Yes we don't like it, but it's easy for postfix to accept and deal with it.

You write the code, deploy it on your systems, and suffer the consequences.

> I'll post my actual problem in another thread, to keep this one focused
> on the policy around multiple PTR records.

Just start the other thread if it is on topic. No point in starting
a flame war instead.

THREAD CLOSED.

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

multiple PTR records

[Frank Cusack]

After searching the mailing list (and the web in general) what I can
gather about multiple PTR records is that postfix is adamant that
hosts should not have multiple PTR records.

Who cares?  It's like saying DNS names should not have underscores or
spaces.

Yes we don't like it, but it's easy for postfix to accept and deal with
it.  OTOH, it's difficult to get OTHER admins to fix their configuration
and additionally it doesn't actually create a problem that I can see.

I'll post my actual problem in another thread, to keep this one focused
on the policy around multiple PTR records.

-frank

Re: Spam Attack on my outgoing server

[Terry Carmen]

On 01/12/2010 09:50 AM, Damian Rivas wrote:

Yeah, I've figured out that the problem was a Firewall vulnerability issue, 
port 25 was open to anyone. I've fixed that and problem solved!

Thanks to you all for your help and my apologies because it was not a Postfix 
issue at all,


Don't feel bad.  It's almost never a postfix issue.

Terry

Re: Spam Attack on my outgoing server

[/dev/rob0]

On Tue, Jan 12, 2010 at 11:50:19AM -0300, Damian Rivas wrote:
> >Another possibility, as you mentioned that this is the gateway for 
> >Postfix, is that it has a misconfigured firewall that is doing 
> >both source and destination NAT of port 25 to your Postfix. I just 
> >tested this, and was unable to connect to 200.55.14.250:25, so if 
> >that was the case, it is probably fixed now.
> 
> Yeah, I've figured out that the problem was a Firewall 
> vulnerability issue, port 25 was open to anyone. I've fixed that 
> and problem solved!

Ha! Good work. You read the logs, identified and fixed the problem,
without waiting to be given the answer.

> Thanks to you all for your help and my apologies because it was not 
> a Postfix issue at all,

No problem, I'm glad you caught it and got it fixed quickly. It's a
pleasure to help those who are working to help themselves.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

RE: Spam Attack on my outgoing server

[Damian Rivas]

>>>On Mon, Jan 11, 2010 at 06:15:21PM -0300, Damian Rivas wrote:
> >> mynetworks = 127.0.0.0/8, 200.55.14.248/29, 190.210.52.88/29
> 
> >These are the hosts allowed to relay. Don't mung the IP addresses.
snip

>> All mailing incomes seem to come from ns1.cht.com.ar, which is a 
>> gateway for the internal mail server, this is by the way, where

>ns1.cht.com.ar. 3600IN  A   200.55.14.250

>Indeed, this host is in your $mynetworks. Exclude it using the "!"
>syntax, see example at postconf.5.html#mynetworks .

I cannot exclude that address, it is one of the two gateways the users in the 
organization use, I fixed the problem with other solution.

>> they are normally sent. There were no smtpd outputs before because 
>> the Spam was cycling and there was no room for any new mail. (I 
>> deleted all the spammer mails, of course they keep coming).

>Stop this at once! The ongoing abuse has probably gotten you
>blacklisted. The sooner you stop it, the better your chances of
>repairing the damage.

Yeah, yesterday I immediately stopped the Postfix system as well as the 
internal server Outgoing queue while searching for a way to get out of that 
situation, fortunately we were apparently only banned by Yahoo!, gotta check 
Hotmail. I've checked the host's IP on mxtoolbox today and we were not 
blacklisted anywhere. Luckily it was not harmful enough to rotten the host. :)

>> But now, at this precise moment, I'm watching a lot of junk being 
>> generated on the server so, there is the source of the problem, I 
>> have a worm on my internal web server, no postfix issue.

>Another possibility, as you mentioned that this is the gateway for
>Postfix, is that it has a misconfigured firewall that is doing both
>source and destination NAT of port 25 to your Postfix. I just tested
>this, and was unable to connect to 200.55.14.250:25, so if that was
>the case, it is probably fixed now.

Yeah, I've figured out that the problem was a Firewall vulnerability issue, 
port 25 was open to anyone. I've fixed that and problem solved!

Thanks to you all for your help and my apologies because it was not a Postfix 
issue at all,
Regards,
Damián 

Re: Postfix dovecot and sieve

[Per Laine]

Ok, thanks for the reply. When I set "virtual_transport = dovecot" and add

dovecot   unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -f
${sender} -d ${recipient}

to master.cf I get Can't connect to auth server at
/var/run/dovecot//auth-master: No such file or directory in
dovecot-deliver.log. I guess that postfix is doing things right by now
but dovecot somehow is misconfigured.



On Tue, Jan 12, 2010 at 2:49 PM, Brian Evans - Postfix List
 wrote:
> On 1/12/2010 5:06 AM, Per Laine wrote:
>> Hi all!
>>
>> This is my first post to the list and i hope I can get some help.
>>
>> I'm using postfix as MTA with dovecot IMAP on Ubuntu Karmic and I'm
>> trying to get server-side mail filtering with sieve. Everything seems
>> like it's working but it's not. I telnet localhost sive and list rules
>> and it seems like they are active. But it doesn't work. I host two
>> virtual domains with virtual users.
>>
>> I think that maybe it's something with the transport from postfix =>
>> dovecot but i really don't have a clue.
>>
>> Anyone with a similar setup who can be of any assistance?
>>
>
> This is because your virtual delivery is using the virtual(8) agent
> which does not use sieve.
> You need to define a pipe transport in master.cf that points to
> dovecot's deliver agent.
>
> A good reading is here:
> http://www.postfix.org/VIRTUAL_README.html#in_virtual_other
>
>> Postfix version 2.6.5
>> Dovecot version 1.1.11
>>
>> my main.cf:
>>
>
> We prefer 'postconf -n' because it makes it easier to read and it sees
> what Postfix sees.
>
>> virtual_mailbox_domains = /etc/postfix/vhosts
>> virtual_mailbox_base = /home/vmail
>> virtual_mailbox_maps = hash:/etc/postfix/vmaps
>> virtual_minimum_uid = 1000
>> virtual_uid_maps = static:5000
>> virtual_gid_maps = static:5000
>>
>
> A good start, but no virtual_transport statement.
>



-- 
Mvh Per Laine
Tel. 0703 - 82 50 84
p...@laine.se

Re: Postfix dovecot and sieve

[Brian Evans - Postfix List]

On 1/12/2010 5:11 AM, Eero Volotinen wrote:
> Quoting Per Laine :
>
>> Hi all!
>>
>> This is my first post to the list and i hope I can get some help.
>>
>> I'm using postfix as MTA with dovecot IMAP on Ubuntu Karmic and I'm
>> trying to get server-side mail filtering with sieve. Everything seems
>> like it's working but it's not. I telnet localhost sive and list rules
>> and it seems like they are active. But it doesn't work. I host two
>> virtual domains with virtual users.
>>
>> I think that maybe it's something with the transport from postfix =>
>> dovecot but i really don't have a clue.
>>
>> Anyone with a similar setup who can be of any assistance?
>
> Well, atleast you need to use dovecot deliver for mailbox command:
>
> mailbox_command = /usr/libexec/dovecot/deliver
>

This would be good if the OP was using local domains instead of virtual.
Only local(8) uses mailbox_command.

Re: Postfix dovecot and sieve

[Brian Evans - Postfix List]

On 1/12/2010 5:06 AM, Per Laine wrote:
> Hi all!
>
> This is my first post to the list and i hope I can get some help.
>
> I'm using postfix as MTA with dovecot IMAP on Ubuntu Karmic and I'm
> trying to get server-side mail filtering with sieve. Everything seems
> like it's working but it's not. I telnet localhost sive and list rules
> and it seems like they are active. But it doesn't work. I host two
> virtual domains with virtual users.
>
> I think that maybe it's something with the transport from postfix =>
> dovecot but i really don't have a clue.
>
> Anyone with a similar setup who can be of any assistance?
>   

This is because your virtual delivery is using the virtual(8) agent
which does not use sieve.
You need to define a pipe transport in master.cf that points to
dovecot's deliver agent.

A good reading is here:
http://www.postfix.org/VIRTUAL_README.html#in_virtual_other

> Postfix version 2.6.5
> Dovecot version 1.1.11
>
> my main.cf:
>   

We prefer 'postconf -n' because it makes it easier to read and it sees
what Postfix sees.

> virtual_mailbox_domains = /etc/postfix/vhosts
> virtual_mailbox_base = /home/vmail
> virtual_mailbox_maps = hash:/etc/postfix/vmaps
> virtual_minimum_uid = 1000
> virtual_uid_maps = static:5000
> virtual_gid_maps = static:5000
>   

A good start, but no virtual_transport statement.

Re: Messages are stuck in maildrop

[Wietse Venema]

Eugueny Kontsevoy:
> I had some issues with free disk space so I had to start the server, expand
> the partition and restart it again.
> I did the following:
> 
> > postsuper -r ALL
> 
> It reported that it re-queued a bunch of messages and I can see that they're
> sitting in maildrop queue.
> postqueue -p reports that queue is empty (which one???)
> 
> And those messages just sit there, pickup dameon is ignoring them.
> Where do I look?

1) Lok in Postfix log for warning messages.

2) Examine a message with postcat. if all recipients are done_recipient
then the message was already delivered and it can be deleted. You
"postsuper"-ed the message before the queue manager had a chance
to delete it.

Wietse

Re: Auto-whitelist policy

[Eray Aslan]

On 12.01.2010 13:21, Stan Hoeppner wrote:
> Daniel L. Miller put forth on 1/11/2010 5:03 PM:
>> Does anyone have an auto-whitelisting policy daemon?  I want to have a
>> test early in sender checks that would bypass most of my other spam
>> prevention if a sender is in the whitelist - and have that whitelist
>> automatically updated by internal users sending to those remote senders.
> 
> sed -n -e '/postfix\/smtp\[.*status=sent/s/^.*to=<\([^>]*\).*$/\1/p'
> /var/log/mail.log | sort -u
> 
> Thank Victor.  He answered this in 2004.

OP might also want to look at pen pals feature of amavisd-new.  Check
its release notes for "pen pals soft-whitelisting"

-- 
Eray

Re: Auto-whitelist policy

[Stan Hoeppner]

Daniel L. Miller put forth on 1/11/2010 5:03 PM:
> Does anyone have an auto-whitelisting policy daemon?  I want to have a
> test early in sender checks that would bypass most of my other spam
> prevention if a sender is in the whitelist - and have that whitelist
> automatically updated by internal users sending to those remote senders.

sed -n -e '/postfix\/smtp\[.*status=sent/s/^.*to=<\([^>]*\).*$/\1/p'
/var/log/mail.log | sort -u

Thank Victor.  He answered this in 2004.  It was the 2nd hit in google.  Now all
you have to do is take the output of this, say daily, and do a compare/append to
the whitelist file you're maintaining.

--
Stan

Re: Does Postfix cache resolv.conf? [SOLVED]

[Christoph Anton Mitterer]

On Tue, 2010-01-12 at 04:02 -0600, Stan Hoeppner wrote:
> resolvconf has a long list of conflicts including ifupdown and bind8/9.
Uhm has it?

> Would using resolvconf
> break bind?
Unlikely,.. at least I'm using it together with bind9

>   Aptitude seems to suggest this.
Well the resolvconf package conflicts against some specific versions,
which were until then not made compatible with it.

>   Does one need to be extra careful
> if/when installing this package?
There's a readme included in the package which lists mist common
pitfals, but usually all of them should be fixed in current package
versions.

>   What kind of collateral damage does this
> pagkage cause, if any?
Well the worst thing is probably that your resolving doesn't work for
some time and you'll have to remove the package again...


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Postfix dovecot and sieve

[Eero Volotinen]

Quoting Per Laine :


Hi all!

This is my first post to the list and i hope I can get some help.

I'm using postfix as MTA with dovecot IMAP on Ubuntu Karmic and I'm
trying to get server-side mail filtering with sieve. Everything seems
like it's working but it's not. I telnet localhost sive and list rules
and it seems like they are active. But it doesn't work. I host two
virtual domains with virtual users.

I think that maybe it's something with the transport from postfix =>
dovecot but i really don't have a clue.

Anyone with a similar setup who can be of any assistance?


Well, atleast you need to use dovecot deliver for mailbox command:

mailbox_command = /usr/libexec/dovecot/deliver

read the docs for sieve from dovecot.org

--
Eero

Postfix dovecot and sieve

[Per Laine]

Hi all!

This is my first post to the list and i hope I can get some help.

I'm using postfix as MTA with dovecot IMAP on Ubuntu Karmic and I'm
trying to get server-side mail filtering with sieve. Everything seems
like it's working but it's not. I telnet localhost sive and list rules
and it seems like they are active. But it doesn't work. I host two
virtual domains with virtual users.

I think that maybe it's something with the transport from postfix =>
dovecot but i really don't have a clue.

Anyone with a similar setup who can be of any assistance?

Postfix version 2.6.5
Dovecot version 1.1.11

my main.cf:
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
content_filter = scan:127.0.0.1:10026
receive_override_options = no_address_mappings
readme_directory = no
smtpd_tls_security_level=may
smtpd_tls_cert_file=/etc/ssl/smtpd.crt
smtpd_tls_key_file=/etc/ssl/smtpd.key
smtpd_use_tls=yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions =
   permit_mynetworks
   permit_sasl_authenticated
   reject_unauth_destination
   check_policy_service inet:127.0.0.1:10023
myhostname = localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
relayhost =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
virtual_mailbox_domains = /etc/postfix/vhosts
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 1000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
header_checks = pcre:/etc/postfix/header_checks

my master.cf:
smtp  inet  n   -   -   -   -   smtpd
   -o content_filter=spamassassin
# AV scan filter (used by content_filter)
scan  unix  -   -   n   -   16  smtp
   -o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10025 inet  n -   n   -   16  smtpd
   -o content_filter=
   -o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
   -o smtpd_helo_restrictions=
   -o smtpd_client_restrictions=
   -o smtpd_sender_restrictions=
   -o smtpd_recipient_restrictions=permit_mynetworks,reject
   -o mynetworks_style=host
   -o smtpd_authorized_xforward_hosts=127.0.0.0/8
submission inet n   -   -   -   -   smtpd
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_client_restrictions=permit_sasl_authenticated,reject
pickupfifo  n   -   -   60  1   pickup
cleanup   unix  n   -   -   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgrunix  -   -   -   1000?   1   tlsmgr
rewrite   unix  -   -   -   -   -   trivial-rewrite
bounceunix  -   -   -   -   0   bounce
defer unix  -   -   -   -   0   bounce
trace unix  -   -   -   -   0   bounce
verifyunix  -   -   -   -   1   verify
flush unix  n   -   -   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   -   -   -   smtp
relay unix  -   -   -   -   -   smtp
   -o smtp_fallback_relay=
showq unix  n   -   -   -   -   showq
error unix  -   -   -   -   -   error
retry unix  -   -   -   -   -   error
discard   unix  -   -   -   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   -   -   -   lmtp
anvil unix  -   -   -   -   1   anvil
scacheunix  -   -   -   -   1   scache

maildrop  unix  -   n   n   -   -   pipe
 flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

uucp  unix  -   n   n   -   -   pipe
 flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

ifmailunix  -   n   n   -   -   pipe
 flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix  -   n   n   -   -   pipe
 flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix  -   n   n   -   2   pipe
 flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${nexthop} ${user} ${extens

Postfix dovecot and sieve

[Per Laine]

Hi all!

This is my first post to the list and i hope I can get some help.

I'm using postfix as MTA with dovecot IMAP on Ubuntu Karmic and I'm
trying to get server-side mail filtering with sieve. Everything seems
like it's working but it's not. I telnet localhost sive and list rules
and it seems like they are active. But it doesn't work. I host two
virtual domains with virtual users.

I think that maybe it's something with the transport from postfix =>
dovecot but i really don't have a clue.

Anyone with a similar setup who can be of any assistance?

Postfix version 2.6.5
Dovecot version 1.1.11

my main.cf:
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
content_filter = scan:127.0.0.1:10026
receive_override_options = no_address_mappings
readme_directory = no
smtpd_tls_security_level=may
smtpd_tls_cert_file=/etc/ssl/smtpd.crt
smtpd_tls_key_file=/etc/ssl/smtpd.key
smtpd_use_tls=yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_authenticated_header = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
check_policy_service inet:127.0.0.1:10023
myhostname = localhost
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
relayhost =
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128 192.168.1.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
virtual_mailbox_domains = /etc/postfix/vhosts
virtual_mailbox_base = /home/vmail
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 1000
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
header_checks = pcre:/etc/postfix/header_checks

my master.cf:
smtp  inet  n   -   -   -   -   smtpd
-o content_filter=spamassassin
# AV scan filter (used by content_filter)
scan  unix  -   -   n   -   16  smtp
-o smtp_send_xforward_command=yes
# For injecting mail back into postfix from the filter
127.0.0.1:10025 inet  n -   n   -   16  smtpd
-o content_filter=
-o 
receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks_style=host
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
submission inet n   -   -   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
pickupfifo  n   -   -   60  1   pickup
cleanup   unix  n   -   -   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgrunix  -   -   -   1000?   1   tlsmgr
rewrite   unix  -   -   -   -   -   trivial-rewrite
bounceunix  -   -   -   -   0   bounce
defer unix  -   -   -   -   0   bounce
trace unix  -   -   -   -   0   bounce
verifyunix  -   -   -   -   1   verify
flush unix  n   -   -   1000?   0   flush
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
smtp  unix  -   -   -   -   -   smtp
relay unix  -   -   -   -   -   smtp
-o smtp_fallback_relay=
showq unix  n   -   -   -   -   showq
error unix  -   -   -   -   -   error
retry unix  -   -   -   -   -   error
discard   unix  -   -   -   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   -   -   -   lmtp
anvil unix  -   -   -   -   1   anvil
scacheunix  -   -   -   -   1   scache

maildrop  unix  -   n   n   -   -   pipe
  flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

uucp  unix  -   n   n   -   -   pipe
  flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

ifmailunix  -   n   n   -   -   pipe
  flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
bsmtp unix  -   n   n   -   -   pipe
  flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
scalemail-backend unix  -   n   n   -   2   pipe
  flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store
${ne

Re: Does Postfix cache resolv.conf? [SOLVED]

[Stan Hoeppner]

Christoph Anton Mitterer put forth on 1/11/2010 5:31 PM:

> Using the "resolvconf" package, should solve your problems, the Debian
> postfix package ships rules for resolvconf in order to automatically
> update the chroot resolv.conf.

resolvconf has a long list of conflicts including ifupdown and bind8/9.  I've
heard of some folks running bind locally on their (large) mail servers for dnsbl
lookups (yes, instead of rbldnsd) and other purposes.  Would using resolvconf
break bind?  Aptitude seems to suggest this.  Does one need to be extra careful
if/when installing this package?  What kind of collateral damage does this
pagkage cause, if any?

Conflicts: bind (< 1:8.3.4-1), bind9 (< 1:9.2.1-7), dhcp-client (=
3.0.1betaRC4-1), dhcp-client (< 2.0pl5-18), dhcp3-client (<
   3.0+3.0.1rc11-5), dhcpcd (< 1:1.3.22pl4-7), divine, dnsmasq (<
1.13-2), ifupdown (< 0.6.4-4.1), laptop-net (< 2.21-1),
   pcmcia-cs (< 3.2.5-1), pdnsd (< 1.1.10par-4), pppconfig (< 2.3.1),
pppoeconf (< 1.0), pump (< 0.8.15-1), runit (<
   1.8.0-3), totd (< 1.4-4), udhcpc (< 0.9.8cvs20050124-3), webmin (<
1.150-2), webmin-wvdial (< 1.160-3), whereami (<
   0.3.3), xisp

--
Stan