Re: how to create a filter in amavisd

[deconya]

Hi

im using smtp to send but filtering all with amavisd. The solution of
content-filter needs to create in main.cf or in master.cf?

Thanks

On Fri, Mar 20, 2009 at 12:08 AM, mouss  wrote:

> deconya a écrit :
> > Hi
> >
> > Im configuring a server with postfix amavisd and spamassassin and
> > appears a problem with the antispam rules. There are one application
> > that uses the server to send to different clients mails but the amavisd
> > detect howo to spam this mails. How I can create an exception? I would
> > like to create a whitelist inside amavisd. It's possible?
> >
> how does your application pass mail to postfix?
>
> if it's with the sendmail command, the easy way is to skip amavisd-new
> for sendmail submitted mail by adding
>-o content_filter=
> under the pickup service (in master.cf)
>
>
> if it submits mail via smtp, check if you can configure it to use a
> specific port. then you can use the -o content_filter as above.
>
> otherwise, give more infos. and when you give infos, think of how to
> differentiate mail from uor app and other mail.
>

Re: Performance tuning

[Costin Guşă]

On Fri, Mar 20, 2009 at 5:12 AM, Victor Duchovni
 wrote:
> On Thu, Mar 19, 2009 at 09:52:42PM -0400, Brandon Hilkert wrote:
>
>> I understand what you mean about sending to one server. I'm going to try
>> and setup a few more receiving servers so that I can more accurately
>> simulate sending it out to the internet.
>
> Did you at least take time to rule out the "syslog" bottleneck? This is
> a common problem with stock Linux configurations, where syslog hammers
> the disk so hard that Postfix can't get any I/O done. Throughput as low
> as 10 msgs/sec is strongly suggestive of something like that, or perhaps
> just failure to send in parallel, or insufficient concurrency in output
> processing because all the test messages are routed to the same local(8)
> mailbox.
>
> Linux servers that are 5 years can do 300-400 msgs/sec, when the disk is
> managed by a RAID controller with an 8MB battery cache, and IIRC somewhere
> between 50 and 100 msgs/sec with the cache off.
>
> Start with syslog, then figure out where the messages are accumulating,
> see QSHAPE_README.

atop, nmon, iotop, itop, vmstat, dstat  can also help you identify
system bottlenecks

Re: Performance tuning

[Costin Guşă]

On Thu, Mar 19, 2009 at 10:30 PM, Wietse Venema  wrote:
> Brandon Hilkert:
>> We send out a pretty volume of emails right now using a combination
>> of SQL and IIS SMTP. We get rates now of about 5,000/min. We're
>> looking to not only improve the rates, but incorporate DKIM/Domainkey
>> signing into the process. The choice has been made to go with
>> postfix along with a queue directory on an XFS file system.
>>
>> I'm using postfix as a relay, and having it sign the outgoing
>> emails with DKIM. That process was about twice as slow as without
>> it. Without DKIM, I'm getting a rate of 700/min.
>>
>> I was expecting much better performance out of the box. I realize
>> in my tests I'm going from a single host, to another single postfix
>> box that is receiving all the emails to one account, so there may
>> be bottlenecks that exist in my test setup, that may not be there
>> in our production environment.
>>
>> I'm really hoping to move away from MS SMTP and don't have tons
>> of experience with Linux, so I'm hoping people could give me some
>> good ideas about improving outbound performance. The server will
>> not be directly exposed to the internet, so security is less of
>> a concern as it will be behind several Cisco firewalls. This server
>> will not be receiving any email, so nothing needs to be considered
>> for that side.
>
> To improve performance, you need to identify the bottleneck.
> Usually, the file system is the slowest component.
>
> On Linux systems, fixing this can be as simple as editing the
> syslog.conf file and making sure that the syslog daemon does not
> sync the disk after every logfile record. Something like:
>
>    mail.*      -/var/log/maillog
>
> Postfix was recently clocked at several thousand messages a second
> while sending mail, but receiving mail is much more expensive since
> each message needs to be made persistent on the local disk.
>
> You also need to keep in mind that you can't deliver mail as fast
> to ONE single machine as you can deliver to the whole Internet.
>
> In the one machine case, all the mail is fighting for access to
> the same file system, while with mail into the Internet, you are
> effectively spreading the load over many remote file systems.
>
>        Wietse
>


also, for benchmarking and testing purposes only, if you have plenty
of ram, you can try to move the entire postfix system into ramfs and
completely disable logging, both on the sending and receiving machine

Re: Performance tuning

[Wietse Venema]

Brandon Hilkert:
> What's the best way to clearly identify that syslog is the issue?

Look in my reply. There is an example.

Wietse

> - Original Message - 
> From: "Victor Duchovni" 
> To: 
> Sent: Thursday, March 19, 2009 11:12 PM
> Subject: Re: Performance tuning
> 
> 
> > On Thu, Mar 19, 2009 at 09:52:42PM -0400, Brandon Hilkert wrote:
> >
> >> I understand what you mean about sending to one server. I'm going to try
> >> and setup a few more receiving servers so that I can more accurately
> >> simulate sending it out to the internet.
> >
> > Did you at least take time to rule out the "syslog" bottleneck? This is
> > a common problem with stock Linux configurations, where syslog hammers
> > the disk so hard that Postfix can't get any I/O done. Throughput as low
> > as 10 msgs/sec is strongly suggestive of something like that, or perhaps
> > just failure to send in parallel, or insufficient concurrency in output
> > processing because all the test messages are routed to the same local(8)
> > mailbox.
> >
> > Linux servers that are 5 years can do 300-400 msgs/sec, when the disk is
> > managed by a RAID controller with an 8MB battery cache, and IIRC somewhere
> > between 50 and 100 msgs/sec with the cache off.
> >
> > Start with syslog, then figure out where the messages are accumulating,
> > see QSHAPE_README.
> >
> > -- 
> > 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: Performance tuning

[Ralf Hildebrandt]

* Brandon Hilkert :

> We send out a pretty volume of emails right now using a combination of
> SQL and IIS SMTP. We get rates now of about 5,000/min. We're looking to
> not only improve the rates, but incorporate DKIM/Domainkey signing into
> the process. The choice has been made to go with postfix along with a
> queue directory on an XFS file system.

You can check if the disk I/O is the bottleneck by simply putting the
queue fs in a RAM disk!
 
> I'm using postfix as a relay, and having it sign the outgoing emails
> with DKIM. That process was about twice as slow as without it. Without
> DKIM, I'm getting a rate of 700/min.

Signing takes time! htop will tell you IO rates and CPU usage...
 
-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
"Windows 95 /n./ 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company that can't stand 1 bit of
competition." 

Re: Performance tuning

[Rainer Frey (Inxmail GmbH)]

On Friday 20 March 2009 02:52:42 Brandon Hilkert wrote:

> As I mentioned, we're using the XFS system for the queue, does that provide
> any additional benefit, or would ext3 perform the same? Keep in mind, we
> will be dealing with 1,000,000 piece mailouts during a session. My findings
> were that XFS might handle more of the small html email files better,
> especially if they get backed up in a deferred queue for some reason, is
> this true?

I don't want to make an assumption whether this has anything to do with the 
problem. But although I haven't used XFS for a long time on production 
systems, I remember it was not recommended for fast access to many small 
files, but contrarily for few large files, e.g. media files for streaming. 
Using XFS for a mail spool for performance reason is new to me.

Rainer  

Re: Performance tuning

[Brandon Hilkert]

Is a simple ext3 partition usually the recommend file system?

- Original Message - 
From: "Rainer Frey (Inxmail GmbH)" 

To: 
Sent: Friday, March 20, 2009 6:54 AM
Subject: Re: Performance tuning



On Friday 20 March 2009 02:52:42 Brandon Hilkert wrote:

As I mentioned, we're using the XFS system for the queue, does that 
provide

any additional benefit, or would ext3 perform the same? Keep in mind, we
will be dealing with 1,000,000 piece mailouts during a session. My 
findings

were that XFS might handle more of the small html email files better,
especially if they get backed up in a deferred queue for some reason, is
this true?


I don't want to make an assumption whether this has anything to do with 
the

problem. But although I haven't used XFS for a long time on production
systems, I remember it was not recommended for fast access to many small
files, but contrarily for few large files, e.g. media files for streaming.
Using XFS for a mail spool for performance reason is new to me.

Rainer 

Re: Performance tuning

[Ralf Hildebrandt]

* Brandon Hilkert :
> Is a simple ext3 partition usually the recommend file system?

Yes

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
"C makes it easy to shoot yourself in the foot. C++ makes it harder,
but when you do, it blows away your whole leg." -- Bjarne Stroustrup

Re: Performance tuning

[Rainer Frey (Inxmail GmbH)]

On Friday 20 March 2009 12:04:22 Brandon Hilkert wrote:
> Is a simple ext3 partition usually the recommend file system?

Please do not top post.

We use ext3 to have simple, repeatable, clear server setups without surprises 
or pitfalls. Performance is good enough for our needs, so I never actually 
compared performance. My comment on XFS is a vague memory from several years 
back, and not related to mail servers specifically. Actually, I'd expect XFS 
to be fast enough, but I also see no reason to use it in this case.

Probably you have a different problem, but if you have to setup the server 
again, I'd use ext3.

Rainer

Re: Performance tuning

[Brandon Hilkert]

What's the best way to clearly identify that syslog is the issue?

- Original Message - 
From: "Victor Duchovni" 

To: 
Sent: Thursday, March 19, 2009 11:12 PM
Subject: Re: Performance tuning



On Thu, Mar 19, 2009 at 09:52:42PM -0400, Brandon Hilkert wrote:


I understand what you mean about sending to one server. I'm going to try
and setup a few more receiving servers so that I can more accurately
simulate sending it out to the internet.


Did you at least take time to rule out the "syslog" bottleneck? This is
a common problem with stock Linux configurations, where syslog hammers
the disk so hard that Postfix can't get any I/O done. Throughput as low
as 10 msgs/sec is strongly suggestive of something like that, or perhaps
just failure to send in parallel, or insufficient concurrency in output
processing because all the test messages are routed to the same local(8)
mailbox.

Linux servers that are 5 years can do 300-400 msgs/sec, when the disk is
managed by a RAID controller with an 8MB battery cache, and IIRC somewhere
between 50 and 100 msgs/sec with the cache off.

Start with syslog, then figure out where the messages are accumulating,
see QSHAPE_README.

--
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: Looking for Anti-spam setting: local username/external IP

[Peter Blair]

On Thu, Mar 19, 2009 at 3:28 PM, David A. Gershman
 wrote:
> from an external source.  I'm trying to see if there is a setting in
> master.cf (or other .cf file) which will reject any email from an
> external IP (other than my own) *and* is claiming to be from a local
> user account.

You'll block mail that was sent from your system, to an offsite
forward, which then redirects back to your system again.

Re: whitelist from spamhaus

[Wietse Venema]

Victor Duchovni:
> On Thu, Mar 19, 2009 at 11:58:52PM +0100, mouss wrote:
> 
> > I would suggest separating relay control from other checks. something like
> > 
> > smtpd_relay_restrictions =
> > permit_mynetworks
> > permit_sasl_authenticated
> 
> This has been proposed before.
> 
> http://archives.neohapsis.com/archives/postfix/2006-05/0598.html
> 
> Perhaps some day, it would be a major change, and the question is whether
> it is worth the effort if it is only an interim design. When you change
> something this big, the new feature should be stable for a long time.
> 
> Changing the interface with every release becomes unpopular with users.
> So the current design for all its flaws is stable, and has proved
> reasonably flexible. A new design would need a lot of scrutiny to make
> sure we have a solid solution good for another decade of releases.
> 
> One could, take this to the extreme and introduce a new (not replacement,
> but alternative) SMTP server called "pysmtpd" that bolts a Python
> interpreter into Postfix, and provides all the restriction building blocks
> (various lookups, ...) as functions in the Python interpreter. Then, in
> "pysmtpd" you'd tweak Python code to make access decisions. There'd be
> of stock rules and a gentle configuration syntax for non-programmers,
> but the underlying rule engine would be a full programming language
> extensible by module writers and advanced users.
> 
> Lots of other possibilities. Which approach is right?

One of the goals of Postfix was to provide a system that is more
secure than other MTAs. For this reason I would not build something
as complex as perl/php/python/etc.  into a process that is directly
exposed to the network. If I wanted to do that, I would have built
Postfix like other MTAs. 

Instead, an architecture based on delegation can provide the
necessary isolation and functionality: one process to weed out
connections from botnets and spammers at minimal resource cost,
while delegating complex policies and SMTP handling to less exposed
and more expensive helpers. While process creation remains relatively
expensive and needs to be minimized, IPC is cheap enough.

Wietse

Re: Looking for Anti-spam setting: local username/external IP

[David A. Gershman]

Yeah,  Thought of that a little after mailing.  Oh well, I guess I need
to keep my efforts in later defenses (spamassassin).

Thanks.

> On Thu, Mar 19, 2009 at 3:28 PM, David A. Gershman
>  wrote:
> > from an external source.  I'm trying to see if there is a setting in
> > master.cf (or other .cf file) which will reject any email from an
> > external IP (other than my own) *and* is claiming to be from a local
> > user account.
> 
> You'll block mail that was sent from your system, to an offsite
> forward, which then redirects back to your system again.
> 
> 

---
David A. Gershman
gersh...@dagertech.net
http://dagertech.net/gershman/
"It's all about the path!" --d. gershman

Re: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Ralf Hildebrandt" 

To: 
Sent: Friday, March 20, 2009 6:52 AM
Subject: Re: Performance tuning



* Brandon Hilkert :


We send out a pretty volume of emails right now using a combination of
SQL and IIS SMTP. We get rates now of about 5,000/min. We're looking to
not only improve the rates, but incorporate DKIM/Domainkey signing into
the process. The choice has been made to go with postfix along with a
queue directory on an XFS file system.


You can check if the disk I/O is the bottleneck by simply putting the
queue fs in a RAM disk!



Sorry if this is a stupid question, but how do I go about this. I tried:

mkdir /ram
mount -t ramfs none /ram

and when I send a mail, postfix says there's not enough space in the queue. 
Should I be doing it a different way?


I also put the queue directory back on an ext3 partition and the rates went 
up by about a factor of two.


Also, by default the syslog messages were already set with 
" -/var/log/mail.log". I disabled mail logging all together and found no 
change in rates.


My disk is writing about 3 MB/s which should be well within it's range. I 
would hope even larger, but I would like to work out the ramfs and test for 
sure.




I'm using postfix as a relay, and having it sign the outgoing emails
with DKIM. That process was about twice as slow as without it. Without
DKIM, I'm getting a rate of 700/min.


Signing takes time! htop will tell you IO rates and CPU usage...

--
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 
570-155

http://www.computerbeschimpfung.de
"Windows 95 /n./ 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company that can't stand 1 bit of
competition." 

Postfix and virtual users with additional_condition

[Sebastian Chociwski]

Hello,
I'm trying to make additional conditions work on my system :
Suse 11.1 , postfix 2.5.5 and mysql 5.0.67.
Forwarding and delivering mails to V_USERS works fine for me but I need to
make additional condition 
so I make new column mailactiv with default '1'.
If the mailactiv is set to '1' mail should be delivered otherwise - bounce.
My email2email.cf :
query = SELECT email FROM users WHERE email='%s'
AND mailactiv='1'
NOT WORK.

query = SELECT email FROM users WHERE email='%s'
additional_conditions = AND mailactiv = '1'
NOT WORK,

query = SELECT email FROM users WHERE email='%s' AND mailactiv='1'
NOT WORK,

query = SELECT email FROM users WHERE mailactiv='1' AND email='%s' 
SETS THE WHOLE SYSTEM OUT OF ORDER.

No idea whats wrong :(


-- 
best regards,
Sebastian Chociwski

Re: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Brandon Hilkert" 

To: 
Sent: Friday, March 20, 2009 10:48 AM
Subject: Re: Performance tuning


- Original Message - 
From: "Ralf Hildebrandt" 

To: 
Sent: Friday, March 20, 2009 6:52 AM
Subject: Re: Performance tuning



* Brandon Hilkert :


We send out a pretty volume of emails right now using a combination of
SQL and IIS SMTP. We get rates now of about 5,000/min. We're looking to
not only improve the rates, but incorporate DKIM/Domainkey signing into
the process. The choice has been made to go with postfix along with a
queue directory on an XFS file system.


You can check if the disk I/O is the bottleneck by simply putting the
queue fs in a RAM disk!



Sorry if this is a stupid question, but how do I go about this. I tried:

mkdir /ram
mount -t ramfs none /ram


I was able to mount to tmpfs and found there was no change in performance.



and when I send a mail, postfix says there's not enough space in the 
queue. Should I be doing it a different way?


I also put the queue directory back on an ext3 partition and the rates 
went up by about a factor of two.


Also, by default the syslog messages were already set with 
" -/var/log/mail.log". I disabled mail logging all together and found no 
change in rates.


My disk is writing about 3 MB/s which should be well within it's range. I 
would hope even larger, but I would like to work out the ramfs and test 
for sure.




I'm using postfix as a relay, and having it sign the outgoing emails
with DKIM. That process was about twice as slow as without it. Without
DKIM, I'm getting a rate of 700/min.


Signing takes time! htop will tell you IO rates and CPU usage...

--
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 
570-155

http://www.computerbeschimpfung.de
"Windows 95 /n./ 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company that can't stand 1 bit of
competition."

Re: VERP Bounce Intercept

[Chris Dos]

Noel Jones wrote:
> Chris Dos wrote:
>> Noel Jones wrote:
 It looks like I want to check for RCPT TO:
 So I ran this check against the regexp table using postmap:
 postmap -q "RCPT TO:"
 regexp:header_checks.regexp
 and it came back with a result of DISCARD.

 So I guess I don't understand how you said it will never match as
 postmap said it does match.

 I'm not trying to be difficult or anything, just trying to figure out
 why this isn't working for me.
>>> Don't use header_checks, use a check_recipient_access map.
>>>
>>> It seems you trying to capture this on the sending system. You can't do
>>> that, the sender isn't verp'ed when header_checks and smtpd_*_checks
>>> sees the address.
>>>
>>>   -- Noel Jones
>>
>> Well, I'm going to really want to forward a message that matches the
>> regexp.  I'm just doing the discard right
>> now for testing.  The header_checks allows me to do more than just
>> accept or reject.
>>
>> Chris
>>
> 
> I don't see a forward action in header_checks.  Maybe you intend to use
> REDIRECT?  Postfix access tables allow more than accept/reject,
> including REDIRECT.
> http://www.postfix.org/access.5.html
> 
> But my point is that header_checks are the wrong tool for the job. 
> There is no guarantee that the envelope sender will be listed in the
> headers you receive.
> 
> And it looks as if you're testing your header_checks on the same machine
> that generates the VERP'ed mail.  That won't work.
> 
>   -- Noel Jones
> 


I was was reading the header_checks won't work on bounced mail.  I setup a 
regexp check_recipient_access map.
 This is the regexp file verp_redirect.regexp :
/^RCPT TO:.+\+.+\=...@.+\..+$/  REDIRECTverpbounce

It's still not working.  Here is the postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
default_process_limit = 200
default_recipient_limit = 2
default_verp_delimiters = +=
disable_verp_bounces = no
disable_vrfy_command = yes
hash_queue_depth = 2
hash_queue_names = deferred, defer, active, incoming
header_checks = regexp:/etc/postfix/header_checks.regexp
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_size_limit = 0
maximal_queue_lifetime = 4d
message_size_limit = 1536
minimal_backoff_time = 7200
mydestination = mail-dr.sharperagent.com, mail-dr.prod.sharperagent.com
myhostname = mail-dr.sharperagent.com
mynetworks = 127.0.0.0/8,   10.20.30.0/24,  10.20.40.0/22,  
172.28.201.0/24,172.28.200.0/30,
71.33.252.73,
myorigin = mail-dr.sharperagent.com
nested_header_checks = regexp:/etc/postfix/header_checks.regexp
propagate_unmatched_extensions = canonical, virtual
qmgr_message_active_limit = 2
qmgr_message_recipient_limit = 10
queue_run_delay = 2000
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, $mynetworks,sharperagent.com,
agentcatalyst.com,
builderintouch.com, lenderintouch.com,mr-roboto.sharperagent.com,   
 minime.sharperagent.com,
relayhost =
smtp_connect_timeout = 10
smtp_helo_timeout = 10
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_authorized_verp_clients = $mynetworks
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_delay_reject = no
smtpd_error_sleep_time = 0
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_hostname,
  regexp:/etc/postfix/helo.regexp,  
  permit
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,
  reject_unauth_pipelining,check_recipient_access 
regexp:/etc/postfix/verp_redirect.regexp,
 check_sender_access hash:/etc/postfix/sender_access,   
check_client_access
regexp:/etc/postfix/habeas_header1.regexp,check_client_access
regexp:/etc/postfix/habeas_header2.regexp,check_client_access
regexp:/etc/postfix/habeas_header3.regexp,  check_client_access 
hash:/etc/postfix/client_access,
  check_recipient_access hash:/etc/postfix/recipient_access,
permit_mynetworks,
permit_sasl_authenticated,reject_unauth_destination,
reject_non_fqdn_hostname,
   reject_rbl_client relays.ordb.org,   
check_policy_service inet:127.0.0.1:6
permit_mx_backup,   reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_hostname,reject_non_fqdn_recipient, 
   reject_unauth_pipelining,
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access,
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/

Re: Performance tuning

[Noel Jones]

Brandon Hilkert wrote:


I also put the queue directory back on an ext3 partition and the rates 
went up by about a factor of two.


Also, by default the syslog messages were already set with " 
-/var/log/mail.log". I disabled mail logging all together and found no 
change in rates.


My disk is writing about 3 MB/s which should be well within it's range. 
I would hope even larger, but I would like to work out the ramfs and 
test for sure.


If your test destination is a single server delivering the 
mail {anywhere}, that's a good candidate for a bottleneck.


For testing, you should set up postfix smtp-sink test program 
included with the postfix source.  The program isn't installed 
by default, but can be found in the src/smtpstone directory of 
the postfix source tree.

http://www.postfix.org/smtp-sink.1.html
Run the smtp-sink program on the test destination server, 
listening on port 25.  Don't run postfix or another mail 
program on that server.


  -- Noel Jones

Re: Performance tuning

[Wietse Venema]

Brandon Hilkert:
> Sorry if this is a stupid question, but how do I go about this. I tried:
> 
> mkdir /ram
> mount -t ramfs none /ram
> 
> and when I send a mail, postfix says there's not enough space in the queue. 
> Should I be doing it a different way?

Postfix requires that the amount of space is several times larger
than the message size limit 

http://www.postfix.org/postconf.5.html#queue_minfree
http://www.postfix.org/postconf.5.html#message_size_limit

> I also put the queue directory back on an ext3 partition and the rates went 
> up by about a factor of two.

Which confirms that XFS is not the best choice to quickly create/delete
of lots of little files.

> Also, by default the syslog messages were already set with 
>  " -/var/log/mail.log". I disabled mail logging all together and found no 
> change in rates.

Good.

> My disk is writing about 3 MB/s which should be well within it's range. I 
> would hope even larger, but I would like to work out the ramfs and test for 
> sure.

Bitrates are completely irrelevant.

Email is about creating and deleting lots of tiny files.  

You need to forget everything you learned about web servers, as it
does not apply to email.

Wietse

Re: VERP Bounce Intercept

[Noel Jones]

Chris Dos wrote:

Noel Jones wrote:

Chris Dos wrote:

Noel Jones wrote:

It looks like I want to check for RCPT TO:
So I ran this check against the regexp table using postmap:
postmap -q "RCPT TO:"
regexp:header_checks.regexp
and it came back with a result of DISCARD.

So I guess I don't understand how you said it will never match as
postmap said it does match.

I'm not trying to be difficult or anything, just trying to figure out
why this isn't working for me.

Don't use header_checks, use a check_recipient_access map.

It seems you trying to capture this on the sending system. You can't do
that, the sender isn't verp'ed when header_checks and smtpd_*_checks
sees the address.

  -- Noel Jones

Well, I'm going to really want to forward a message that matches the
regexp.  I'm just doing the discard right
now for testing.  The header_checks allows me to do more than just
accept or reject.

Chris


I don't see a forward action in header_checks.  Maybe you intend to use
REDIRECT?  Postfix access tables allow more than accept/reject,
including REDIRECT.
http://www.postfix.org/access.5.html

But my point is that header_checks are the wrong tool for the job. 
There is no guarantee that the envelope sender will be listed in the

headers you receive.

And it looks as if you're testing your header_checks on the same machine
that generates the VERP'ed mail.  That won't work.

  -- Noel Jones




I was was reading the header_checks won't work on bounced mail.  I setup a 
regexp check_recipient_access map.
 This is the regexp file verp_redirect.regexp :
/^RCPT TO:.+\+.+\=...@.+\..+$/  REDIRECTverpbounce

It's still not working.  Here is the postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
default_process_limit = 200
default_recipient_limit = 2
default_verp_delimiters = +=
disable_verp_bounces = no
disable_vrfy_command = yes
hash_queue_depth = 2
hash_queue_names = deferred, defer, active, incoming
header_checks = regexp:/etc/postfix/header_checks.regexp
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_size_limit = 0
maximal_queue_lifetime = 4d
message_size_limit = 1536
minimal_backoff_time = 7200
mydestination = mail-dr.sharperagent.com, mail-dr.prod.sharperagent.com
myhostname = mail-dr.sharperagent.com
mynetworks = 127.0.0.0/8,   10.20.30.0/24,  10.20.40.0/22,  
172.28.201.0/24,172.28.200.0/30,
71.33.252.73,
myorigin = mail-dr.sharperagent.com
nested_header_checks = regexp:/etc/postfix/header_checks.regexp
propagate_unmatched_extensions = canonical, virtual
qmgr_message_active_limit = 2
qmgr_message_recipient_limit = 10
queue_run_delay = 2000
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination, $mynetworks,sharperagent.com,
agentcatalyst.com,
builderintouch.com, lenderintouch.com,mr-roboto.sharperagent.com,   
 minime.sharperagent.com,
relayhost =
smtp_connect_timeout = 10
smtp_helo_timeout = 10
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
smtpd_authorized_verp_clients = $mynetworks
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_event_limit_exceptions = $mynetworks
smtpd_delay_reject = no
smtpd_error_sleep_time = 0
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks,
reject_invalid_hostname,
  regexp:/etc/postfix/helo.regexp,  
  permit
smtpd_recipient_restrictions = reject_non_fqdn_sender,
reject_non_fqdn_recipient,
  reject_unauth_pipelining,check_recipient_access 
regexp:/etc/postfix/verp_redirect.regexp,
 check_sender_access hash:/etc/postfix/sender_access,   
check_client_access
regexp:/etc/postfix/habeas_header1.regexp,check_client_access
regexp:/etc/postfix/habeas_header2.regexp,check_client_access
regexp:/etc/postfix/habeas_header3.regexp,  check_client_access 
hash:/etc/postfix/client_access,
  check_recipient_access hash:/etc/postfix/recipient_access,
permit_mynetworks,
permit_sasl_authenticated,reject_unauth_destination,
reject_non_fqdn_hostname,
   reject_rbl_client relays.ordb.org,   
check_policy_service inet:127.0.0.1:6
permit_mx_backup,   reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_hostname,reject_non_fqdn_recipient, 
   reject_unauth_pipelining,
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_access,
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smt

Re: VERP Bounce Intercept

[Chris Dos]

Noel Jones wrote:
>> I was was reading the header_checks won't work on bounced mail.  I
>> setup a regexp check_recipient_access map.
>>  This is the regexp file verp_redirect.regexp :
>> /^RCPT TO:.+\+.+\=...@.+\..+$/  REDIRECTverpbounce
>>
>> It's still not working.  Here is the postconf -n:
>> alias_database = hash:/etc/aliases
>> alias_maps = hash:/etc/aliases
>> append_dot_mydomain = no
>> biff = no
>> config_directory = /etc/postfix
>> default_process_limit = 200
>> default_recipient_limit = 2
>> default_verp_delimiters = +=
>> disable_verp_bounces = no
>> disable_vrfy_command = yes
>> hash_queue_depth = 2
>> hash_queue_names = deferred, defer, active, incoming
>> header_checks = regexp:/etc/postfix/header_checks.regexp
>> html_directory = /usr/share/doc/postfix/html
>> inet_interfaces = all
>> mailbox_size_limit = 0
>> maximal_queue_lifetime = 4d
>> message_size_limit = 1536
>> minimal_backoff_time = 7200
>> mydestination = mail-dr.sharperagent.com, mail-dr.prod.sharperagent.com
>> myhostname = mail-dr.sharperagent.com
>> mynetworks = 127.0.0.0/8,10.20.30.0/24,   
>> 10.20.40.0/22,172.28.201.0/24,172.28.200.0/30,   
>> 71.33.252.73,
>> myorigin = mail-dr.sharperagent.com
>> nested_header_checks = regexp:/etc/postfix/header_checks.regexp
>> propagate_unmatched_extensions = canonical, virtual
>> qmgr_message_active_limit = 2
>> qmgr_message_recipient_limit = 10
>> queue_run_delay = 2000
>> readme_directory = /usr/share/doc/postfix
>> recipient_delimiter = +
>> relay_domains = $mydestination, $mynetworks,   
>> sharperagent.com,agentcatalyst.com,
>> builderintouch.com,lenderintouch.com,   
>> mr-roboto.sharperagent.com,minime.sharperagent.com,
>> relayhost =
>> smtp_connect_timeout = 10
>> smtp_helo_timeout = 10
>> smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
>> smtpd_authorized_verp_clients = $mynetworks
>> smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
>> smtpd_client_event_limit_exceptions = $mynetworks
>> smtpd_delay_reject = no
>> smtpd_error_sleep_time = 0
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions =
>> permit_mynetworks,   
>> reject_invalid_hostname,
>>  
>> regexp:/etc/postfix/helo.regexp,permit
>> smtpd_recipient_restrictions = reject_non_fqdn_sender,   
>> reject_non_fqdn_recipient,
>>   reject_unauth_pipelining,check_recipient_access
>> regexp:/etc/postfix/verp_redirect.regexp,
>>  check_sender_access
>> hash:/etc/postfix/sender_access,check_client_access
>> regexp:/etc/postfix/habeas_header1.regexp,   
>> check_client_access
>> regexp:/etc/postfix/habeas_header2.regexp,   
>> check_client_access
>> regexp:/etc/postfix/habeas_header3.regexp,check_client_access
>> hash:/etc/postfix/client_access,
>>   check_recipient_access
>> hash:/etc/postfix/recipient_access,permit_mynetworks,
>> permit_sasl_authenticated,   
>> reject_unauth_destination,reject_non_fqdn_hostname,
>>reject_rbl_client relays.ordb.org,   
>> check_policy_service inet:127.0.0.1:6
>> permit_mx_backup,reject_invalid_hostname,   
>> reject_non_fqdn_sender,
>> reject_non_fqdn_hostname,   
>> reject_non_fqdn_recipient,reject_unauth_pipelining,
>> smtpd_sender_restrictions = check_sender_access
>> hash:/etc/postfix/sender_access,
>> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
>> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
>> smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
>> smtpd_use_tls = yes
>> strict_rfc821_envelopes = yes
>> transport_maps = hash:/etc/postfix/transport
>> unknown_address_reject_code = 554
>> unknown_client_reject_code = 554
>> unknown_hostname_reject_code = 554
>> verp_delimiter_filter = -+=
>> virtual_alias_maps = hash:/etc/postfix/virtual
>>
>>
>> My log of attempting to send an e-mail looks like this:
>> Mar 20 09:06:34 mail-dr postfix/smtpd[9069]: connect from
>> localhost[127.0.0.1]
>> Mar 20 09:06:34 mail-dr postfix/smtpd[9069]: 7A03D28E132:
>> client=localhost[127.0.0.1]
>> Mar 20 09:06:34 mail-dr postfix/cleanup[9072]: 7A03D28E132:
>> message-id=<20090320150634.7a03d28e...@mail-dr.sharperagent.com>
>> Mar 20 09:06:34 mail-dr postfix/qmgr[9062]: 7A03D28E132:
>> from=, size=527, nrcpt=1 (queue
>> active)
>> Mar 20 09:06:34 mail-dr postfix/smtpd[9069]: lost connection after
>> QUIT from localhost[127.0.0.1]
>> Mar 20 09:06:34 mail-dr postfix/smtpd[9069]: disconnect from
>> localhost[127.0.0.1]
>> Mar 20 09:06:35 mail-dr postfix/smtp[9073]: 7A03D28E132:
>> to=,
>> relay=mail.chrisdos.com[71.33.251.73]:25, delay=0.96,
>> delays=0.05/0.01/0.7/0.2, dsn=5.1.1, status=bounced
>> (host mail.chrisdos.com[71.33.251.73] said: 550 5.1.1
>> : Recipient 

Re: Postfix and virtual users with additional_condition

[Victor Duchovni]

On Fri, Mar 20, 2009 at 03:59:05PM +0100, Sebastian Chociwski wrote:

> query = SELECT email FROM users WHERE email='%s'
>   AND mailactiv='1'

Is the "mailactiv" column integer-valued or string-valued?

> NOT WORK.

You really should report output from tests with "postmap -q". "NOT WORK"
is rather useless.

> query = SELECT email FROM users WHERE email='%s'
> additional_conditions = AND mailactiv = '1'

Of course, "additional_conditions" is not used with new "query =" syntax,
only with the the obsolete "table =" syntax.

> query = SELECT email FROM users WHERE email='%s' AND mailactiv='1'

Equivalent to the first.

> query = SELECT email FROM users WHERE mailactiv='1' AND email='%s' 

Ditto, the order of constraints in SQL is not significant.

> SETS THE WHOLE SYSTEM OUT OF ORDER.

How are we supposed to know what "sets the whole system out of order"
means?

-- 
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: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Wietse Venema" 

To: "Brandon Hilkert" 
Cc: 
Sent: Friday, March 20, 2009 11:30 AM
Subject: Re: Performance tuning



Brandon Hilkert:

Sorry if this is a stupid question, but how do I go about this. I tried:

mkdir /ram
mount -t ramfs none /ram

and when I send a mail, postfix says there's not enough space in the 
queue.

Should I be doing it a different way?


Postfix requires that the amount of space is several times larger
than the message size limit

http://www.postfix.org/postconf.5.html#queue_minfree
http://www.postfix.org/postconf.5.html#message_size_limit


I was able to get it to mount to tmpfs and it showed no change in 
performance, so that would theoretcially rule out any existing disk issue 
right?




I also put the queue directory back on an ext3 partition and the rates 
went

up by about a factor of two.


Which confirms that XFS is not the best choice to quickly create/delete
of lots of little files.


Also, by default the syslog messages were already set with
 " -/var/log/mail.log". I disabled mail logging all together and found no
change in rates.


Good.


My disk is writing about 3 MB/s which should be well within it's range. I
would hope even larger, but I would like to work out the ramfs and test 
for

sure.


Bitrates are completely irrelevant.


what is best to look out and compare?



Email is about creating and deleting lots of tiny files.

You need to forget everything you learned about web servers, as it
does not apply to email.

Wietse 

Re: VERP Bounce Intercept

[Noel Jones]

Chris Dos wrote:


Well, pointing the gun the wrong way is differently something that I don't want 
to be doing.  But in the case,
I'm confused.  I'm having mail-dr send out to another server, 
mail.chrisdos.com, on the internet.  Mail-DR is
a separate mail server all together on a different domain and network.  I'm 
just sending the e-mail to my
server to test this.

I'm doing  smtpd_recipient_restrictions and adding that hash.  That won't work 
for outgoing e-mail?

Chris


All postfix restrictions operate on input, ie. when mail is 
received by postfix.  Can't change that.


  -- Noel Jones

rw_loop: leaving rw loop, no progress

[Mark Martinec]

--  Forwarded Message  --
Subject: Re: [AMaViS-user] rw_loop: leaving rw loop, no progress
Date: Friday 20 March 2009
From: Mark Martinec 
To: amavis-u...@lists.sourceforge.net

Ivan,

> This is log in attached files

Thanks, interesting and strange.

I'll CC this to the Postfix mailing list,
in case someone can provide an explanation.

> I have problem with amavisd-new.
> My system: FreeBSD 5.4, postfix-2.3.14, amavisd-new-2.6.2_2,
> p5-Mail-SpamAssassin-3.2.5
>
> For each message to my server I see this error in amavis log:
> Mar  5 18:17:59 mydomain.ua /usr/local/sbin/amavisd[32001]:
> (32001-01) (!)rw_loop: leaving rw loop, no progress
>
> After 30-60 minutes message will have delivered.

| It happens during fwd-connect phase, i.e. during server greeting and
| EHLO exchange. It seems the Postfix smtpd service takes a long time
| to respond for some reason, and amavisd times out meanwhile.

| > Does it happen often? When it happens to one message, is it likely
| > that it happens to other messages following it too? When this
| > happens, are you able to telnet to 127.0.0.1 port 10025 and
| > receive a greeting and some response to an 'EHLO foo' command?
| > Is there any problem with (slow?) DNS resolving of '127.0.0.1'
| > or 'localhost'?
>
> It's happens for 80% of all message.
> When this happens, I able to telnet to 127.0.0.1 port 10025 and
> receive a greeting and some response to an 'EHLO foo' command

> smtpd_sender_restrictions = permit_mynetworks,
>   permit_sasl_authenticated,
>   check_sender_access hash:/usr/local/etc/postfix/check_sender,
>   reject_unknown_sender_domain,
>   reject_non_fqdn_sender,
>   reject_unverified_sender
>
> smtpd_recipient_restrictions =
>   permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
>
> content_filter=smtp-amavis:[127.0.0.1]:10024
>
> smtp  inet  n   -   n   -   5  smtpd
>
> smtp-amavis unix -  -   n   -   5  smtp
> -o smtp_data_done_timeout=1200
> -o smtp_send_xforward_command=yes
> -o disable_dns_lookups=yes
> -o max_use=20
>
> 127.0.0.1:10025 inet n  -   n   -   5  smtpd
> -o content_filter=
> -o local_recipient_maps=
> -o relay_recipient_maps=
> -o smtpd_restriction_classes=
> -o smtpd_delay_reject=no
> -o smtpd_client_restrictions=permit_mynetworks,reject
> -o smtpd_helo_restrictions=
> -o smtpd_sender_restrictions=
> -o smtpd_recipient_restrictions=permit_mynetworks,reject
> -o mynetworks_style=host
> -o mynetworks=127.0.0.0/8
> -o strict_rfc821_envelopes=yes
> -o smtpd_error_sleep_time=0
> -o smtpd_soft_error_limit=1001
> -o smtpd_hard_error_limit=1000
> -o smtpd_client_connection_count_limit=0
> -o smtpd_client_connection_rate_limit=0
> -o
> receive_override_options=no_header_body_checks,no_unknown_recipient_checks


I'll summarize the events from your two logs and a tcpdump capture:

15:50:35, amavisd requests a connect to postfix at 127.0.0.1 port 10025:

Mar 18 15:50:35 inspe.com.ua /usr/local/sbin/amavisd[43524]: (43524-01)
  smtp creating socket by IO::Socket::INET to [127.0.0.1]:10025
Mar 18 15:50:35 inspe.com.ua /usr/local/sbin/amavisd[43524]: (43524-01)
  rw_loop: needline=1, flush=0, wr=0, timeout=30

tcpdump confirms the triple TCP handshake at that time:

1 15:50:35.184300 localhost.ijs.si localhost.ijs.si TCP 49355 > 10025
  [SYN] Seq=0 Win=65535 Len=0 MSS=16344 WS=1 TSV=18493818 TSER=0

2 15:50:35.184354 localhost.ijs.si localhost.ijs.si TCP 10025 > 49355
  [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=16344 WS=1
  TSV=18493818 TSER=18493818

3 15:50:35.184390 localhost.ijs.si localhost.ijs.si TCP 49355 > 10025
  [ACK] Seq=1 Ack=1 Win=71680 Len=0 TSV=18493818 TSER=18493818

nothing in the Postfix log at 15:50:35 or close to it!

Then, precisely 30 seconds later after a 30 second timer in amavisd
expires, amavisd reports a timeout:

Mar 18 15:51:05 inspe.com.ua /usr/local/sbin/amavisd[43524]: (43524-01)
  (!)rw_loop: leaving rw loop, no progress

the exception handler sends a QUIT just in case, then drops the session.

Now a surprise, tcpdump shows that Postfix send its greeting at just
that moment (i.e. 30 seconds after TCP session was established), then
a QUIT is captured, a response to it, and a normal TCP session rundown:

4 15:51:05.235130 localhost.ijs.si localhost.ijs.si TCP 10025 > 49355
  [PSH, ACK] Seq=1 Ack=1 Win=71680 Len=32 TSV=18496823 TSER=18493818
  220 inspe.com.ua ESMTP Postfix\r\n

Postfix only now logs a connect:

Mar 18 15:51:05 inspe postfix/smtpd[43289]: connect from localhost[127.0.0.1]

5 15:51:05.281348 localhost.ijs.si localhost.ijs.si TCP 49355 > 10025
  [PSH, ACK] Seq=1 Ack=33 Win=71680 Len=6 TSV=18496827 TSER=18496823
  QUIT\r\n

6 15:51:05.281489 localhost.ijs.si localhost.ijs.si TCP 10025 > 49355
  [PSH, ACK] Seq=33 Ack=7 Win=71680 Len=15 TSV=18496827 TSER=18496827
  221 2.0.0 Bye\r\n

followed by a normal TCP rundown:

7 15:51:

Re: Performance tuning

[Wietse Venema]

Brandon Hilkert:
> >> and when I send a mail, postfix says there's not enough space in the 
> >> queue.
> >> Should I be doing it a different way?
> >
> > Postfix requires that the amount of space is several times larger
> > than the message size limit
> >
> > http://www.postfix.org/postconf.5.html#queue_minfree
> > http://www.postfix.org/postconf.5.html#message_size_limit
> 
> I was able to get it to mount to tmpfs and it showed no change in 
> performance, so that would theoretcially rule out any existing disk issue 
> right?

tmpfs is backed by the swap file, which is on disk.

> >> My disk is writing about 3 MB/s which should be well within it's range. I
> >> would hope even larger, but I would like to work out the ramfs and test 
> >> for
> >> sure.
> >
> > Bitrates are completely irrelevant.
> 
> what is best to look out and compare?

When the disk is 100% busy, then it is the bottle neck.  Disks can
be 100% busy jumping around doing very little I/O.

As Noel suggested in earlier email, try running smtp-sink which
does no disk I/O at all. If things are still slow, then the problem
is network or MS-Exchange configuration.

Wietse

Re: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Wietse Venema" 

To: "Brandon Hilkert" 
Cc: "Wietse Venema" ; 
Sent: Friday, March 20, 2009 12:45 PM
Subject: Re: Performance tuning



Brandon Hilkert:

>> and when I send a mail, postfix says there's not enough space in the
>> queue.
>> Should I be doing it a different way?
>
> Postfix requires that the amount of space is several times larger
> than the message size limit
>
> http://www.postfix.org/postconf.5.html#queue_minfree
> http://www.postfix.org/postconf.5.html#message_size_limit

I was able to get it to mount to tmpfs and it showed no change in
performance, so that would theoretcially rule out any existing disk issue
right?


tmpfs is backed by the swap file, which is on disk.

>> My disk is writing about 3 MB/s which should be well within it's 
>> range. I
>> would hope even larger, but I would like to work out the ramfs and 
>> test

>> for
>> sure.
>
> Bitrates are completely irrelevant.

what is best to look out and compare?


When the disk is 100% busy, then it is the bottle neck.  Disks can
be 100% busy jumping around doing very little I/O.

As Noel suggested in earlier email, try running smtp-sink which
does no disk I/O at all. If things are still slow, then the problem
is network or MS-Exchange configuration.


I found the source. How do I build it in Debian? I realize this is probably 
a stupid question, but I don't have tons of experience with Linux.


Exchange hasn't been involved at all. I've been running everything from 
scripts, hoping to zero in on the bottleneck.




Wietse 

Re: Performance tuning

[Victor Duchovni]

On Fri, Mar 20, 2009 at 01:01:55PM -0400, Brandon Hilkert wrote:

> I've been running everything from scripts, hoping to zero in on the
> bottleneck.

How many messages are you sending in parallel in the injector scripts?

SMTP is a high latency half-duplex protocol, and a single injector will
never stress the capacity of the Postfix SMTP server. On a low delay,
high bandwidth network link, you need around 10 parallel injectors to
before you get anywhere near peak server throughput.

-- 
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: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Victor Duchovni" 

To: 
Sent: Friday, March 20, 2009 1:20 PM
Subject: Re: Performance tuning



On Fri, Mar 20, 2009 at 01:01:55PM -0400, Brandon Hilkert wrote:


I've been running everything from scripts, hoping to zero in on the
bottleneck.


How many messages are you sending in parallel in the injector scripts?


My local script on the postfix machine itself. It's just a single shell 
script in a for loop.


Is there a better way to test?



SMTP is a high latency half-duplex protocol, and a single injector will
never stress the capacity of the Postfix SMTP server. On a low delay,
high bandwidth network link, you need around 10 parallel injectors to
before you get anywhere near peak server throughput.

--
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: Performance tuning

[Victor Duchovni]

On Fri, Mar 20, 2009 at 01:32:26PM -0400, Brandon Hilkert wrote:

>
> - Original Message - From: "Victor Duchovni" 
> 
> To: 
> Sent: Friday, March 20, 2009 1:20 PM
> Subject: Re: Performance tuning
>
>
>> On Fri, Mar 20, 2009 at 01:01:55PM -0400, Brandon Hilkert wrote:
>>
>>> I've been running everything from scripts, hoping to zero in on the
>>> bottleneck.
>>
>> How many messages are you sending in parallel in the injector scripts?
>
> My local script on the postfix machine itself. It's just a single shell 
> script in a for loop.
>
> Is there a better way to test?

Yes, of course. Run multiple copies of your script if it
generates particularly representative (of your intended work-load)
content. Otherwise use smtp-source(1) with a suitable number of parallel
streams.

Measurements of single-stream performance just measure single transaction
latency on a lightly loaded server, not peak server throughput.

-- 
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: VERP Bounce Intercept

[Chris Dos]

Noel Jones wrote:
> Chris Dos wrote:
>>
>> Well, pointing the gun the wrong way is differently something that I
>> don't want to be doing.  But in the case,
>> I'm confused.  I'm having mail-dr send out to another server,
>> mail.chrisdos.com, on the internet.  Mail-DR is
>> a separate mail server all together on a different domain and
>> network.  I'm just sending the e-mail to my
>> server to test this.
>>
>> I'm doing  smtpd_recipient_restrictions and adding that hash.  That
>> won't work for outgoing e-mail?
>>
>> Chris
> 
> All postfix restrictions operate on input, ie. when mail is received by
> postfix.  Can't change that.
> 
>   -- Noel Jones
> 

Okay, since the e-mail never finishes sending because the user is unknown on 
the other end and it is rejected
right away, is there another way to do this.

The whole point of this exercise for me is to just intercept a bounce back and 
process it internally instead
of bouncing it back to the person that originally sent the mail.  The best way 
seems to be to use VERP.  Is
there something I'm missing or a different way to go about doing this.  Maybe 
pass all initial bounces through
procmail or something to that affect?

Chris

Re: VERP Bounce Intercept

[Noel Jones]

Chris Dos wrote:

Noel Jones wrote:

Chris Dos wrote:

Well, pointing the gun the wrong way is differently something that I
don't want to be doing.  But in the case,
I'm confused.  I'm having mail-dr send out to another server,
mail.chrisdos.com, on the internet.  Mail-DR is
a separate mail server all together on a different domain and
network.  I'm just sending the e-mail to my
server to test this.

I'm doing  smtpd_recipient_restrictions and adding that hash.  That
won't work for outgoing e-mail?

Chris

All postfix restrictions operate on input, ie. when mail is received by
postfix.  Can't change that.

  -- Noel Jones



Okay, since the e-mail never finishes sending because the user is unknown on 
the other end and it is rejected
right away, is there another way to do this.

The whole point of this exercise for me is to just intercept a bounce back and 
process it internally instead
of bouncing it back to the person that originally sent the mail.  The best way 
seems to be to use VERP.  Is
there something I'm missing or a different way to go about doing this.  Maybe 
pass all initial bounces through
procmail or something to that affect?

Chris


Internally generated bounces don't go through procmail or 
anything, they're just delivered to the original sender address.


Maybe it would be better if you describe the actual problem 
you're trying to solve rather than asking how to implement a 
possible solution.


  -- Noel Jones

Issue with smtpd_recipient_restrictions

[Post Freak]

Hello,
I need to only allow access to known addresses, and found that setting up 
smtpd_recipient_restrictions in main.cf would reject unauthorized recipients. I 
have this setting in main.cf:

smtpd_recipient_restrictions = hash:/etc/postfix/allowed_users, 
reject_unauth_destination


I ran "postmap allowed_users", and restarted postfix. However, no recipients 
are being denied. I ran "postmap -q some...@host.com hash:allowed_users", and 
the command replied with an OK. I tried with
an invalid account, and postmap returned a 1 which is what I expected.
Is there something I'm doing wrong?

Here is my main.cf in case that helps.

queue_directory = /var/spool/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
mydomain = host.com
inet_interfaces = all
mydestination = some.host.com 
unknown_local_recipient_reject_code = 550
mynetworks = 192.168.0.0/24, 192.168.90.0/24, 192.168.20.0/24
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
debug_peer_level = 2
debugger_command =
 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
 xxgdb $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES
local_header_rewrite_clients = static:all
masquerade_domains = .host.com host.com
always_bcc = usern...@host.com
maximal_queue_lifetime = 100d
bounce_queue_lifetime = 100d
maximal_backoff_time = 900s
smtpd_recipient_restrictions = hash:/etc/postfix/allowed_users, 
reject_unauth_destination


Thank you.


  

Re: Issue with smtpd_recipient_restrictions

[Victor Duchovni]

On Fri, Mar 20, 2009 at 11:13:21AM -0700, Post Freak wrote:

> I need to only allow access to known addresses, and found that setting
> up smtpd_recipient_restrictions in main.cf would reject unauthorized
> recipients. I have this setting in main.cf:
> 
> smtpd_recipient_restrictions =
>   hash:/etc/postfix/allowed_users,
>   reject_unauth_destination

Replace "reject_unauth_destination" with "reject" and don't use implicit
"check_mumble_access" in "smtpd_mumbe_restrictions". It is best to start
with "reject_unauth_destination" so are not an open relay by accident
as the rule-set evolves, particularly if you add anti-spam rules, and
then whitelists for those rules:

smtpd_recipient_restrictions =
reject_unauth_destination,
... anti-spam rules here ...
check_recipient_access hash:/etc/postfix/allowed_users,
reject

-- 
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: Issue with smtpd_recipient_restrictions

[Post Freak]

Hello,
Thank you for the configuration, but I am still able to send email to addresses 
not listed in allowed_users. Here is my new config:

smtpd_recipient_restrictions = reject_unauth_destination, 
check_recipient_access hash:/etc/postfix/allowed_users, reject

I've restarted postfix, but I can email recipients not listed in allowed_users. 
Is there something else I'm missing?

Thanks again for your help!





From: Victor Duchovni 
To: postfix-users@postfix.org
Sent: Friday, March 20, 2009 1:20:43 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 11:13:21AM -0700, Post Freak wrote:

> I need to only allow access to known addresses, and found that setting
> up smtpd_recipient_restrictions in main.cf would reject unauthorized
> recipients. I have this setting in main.cf:
> 
> smtpd_recipient_restrictions =
>hash:/etc/postfix/allowed_users,
>reject_unauth_destination

Replace "reject_unauth_destination" with "reject" and don't use implicit
"check_mumble_access" in "smtpd_mumbe_restrictions". It is best to start
with "reject_unauth_destination" so are not an open relay by accident
as the rule-set evolves, particularly if you add anti-spam rules, and
then whitelists for those rules:

smtpd_recipient_restrictions =
reject_unauth_destination,
... anti-spam rules here ...
check_recipient_access hash:/etc/postfix/allowed_users,
reject

-- 
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: VERP Bounce Intercept

[Chris Dos]

Chris Dos wrote:
> Noel Jones wrote:
>>> Okay, since the e-mail never finishes sending because the user is
>>> unknown on the other end and it is rejected
>>> right away, is there another way to do this.
>>>
>>> The whole point of this exercise for me is to just intercept a bounce
>>> back and process it internally instead
>>> of bouncing it back to the person that originally sent the mail.  The
>>> best way seems to be to use VERP.  Is
>>> there something I'm missing or a different way to go about doing
>>> this.  Maybe pass all initial bounces through
>>> procmail or something to that affect?
>>>
>>> Chris
>> Internally generated bounces don't go through procmail or anything,
>> they're just delivered to the original sender address.
>>
>> Maybe it would be better if you describe the actual problem you're
>> trying to solve rather than asking how to implement a possible solution.
>>
>>   -- Noel Jones
> 
> 
> 
> I'm trying to intercept all hard bounced back e-mail and send it to a 
> script/program for processing
> internally.  I wish to prevent all notification of bounces to the person that 
> sent the e-mail.
> 
> I had an idea, and I'm trying to make it work.  Can I just change the 
> master.cf and change bounce to go to a
> pipe?  Like this:
> bounceunix  -   -   n   -   0   pipe
>   flags=DORhu user=root argv=/etc/postfix/dump_bounce.sh
> 
> I keep getting this error though:
> postfix/pipe[9736]: fatal: service bounce requires privileged operation
> 
> I was trying different users besides root, but even root does not work.
> 
>  Chris
>
I figured out that problem by adding a "n" to the unpriv column.

Chris

Re: Performance tuning

[David Rees]

On Thu, Mar 19, 2009 at 6:52 PM, Brandon Hilkert  wrote:
> Our test system is a pretty standard SATA disk with 2GB memory. If disk is
> the necessary resource, would we see an immediate benefit by going to a SCSI
> disk or even a SCSI array, or does that hardware benefit flatten out at some
> point?

Postfix performance is primarily limited by how fast the disk can sync data.

For standard rotational disks, this is going to be primarily limited
by how fast the disk rotates.  Since your standard SATA disk reotates
at 7200 rpm, replacing it with a disk that spins faster (10k or even
15k RPM) will help immensely.  There are 10k SATA disks available,
otherwise you have to go SCSI.  Expect up to a 30% improvement with a
10k rpm disk and nearly double with a 15k rpm disk.

If you want to go significantly faster than that, you have 3 options:

1. More spindles and the appropriate RAID setup.  A RAID10 array with
4 disks should double your random IO performance.
2. IO controller with battery-backed memory cache in write-back mode.
The battery backed cache will basically allow syncs to happen nearly
instantly (as long as your cache isn't full).  This can improve
performance by an order of magnitude.
3. SSD (Solid state disk).  Intel makes some great SATA SSDs that will
absolutely fly under this kind of workload.  But before you buy any
old SSD, I highly recommend you read this article at Anandtech:
http://www.anandtech.com/storage/showdoc.aspx?i=3531
4. A combination of 1 & 2 or 2 & 3.

Hope this helps.

-Dave

Re: VERP Bounce Intercept

[Chris Dos]

--
Chris Dos
Senior Engineer
Cell: 303-520-1821


Chris Dos wrote:
> Chris Dos wrote:
>> Noel Jones wrote:
 Okay, since the e-mail never finishes sending because the user is
 unknown on the other end and it is rejected
 right away, is there another way to do this.

 The whole point of this exercise for me is to just intercept a bounce
 back and process it internally instead
 of bouncing it back to the person that originally sent the mail.  The
 best way seems to be to use VERP.  Is
 there something I'm missing or a different way to go about doing
 this.  Maybe pass all initial bounces through
 procmail or something to that affect?

 Chris
>>> Internally generated bounces don't go through procmail or anything,
>>> they're just delivered to the original sender address.
>>>
>>> Maybe it would be better if you describe the actual problem you're
>>> trying to solve rather than asking how to implement a possible solution.
>>>
>>>   -- Noel Jones
>>
>>
>> I'm trying to intercept all hard bounced back e-mail and send it to a 
>> script/program for processing
>> internally.  I wish to prevent all notification of bounces to the person 
>> that sent the e-mail.
>>
>> I had an idea, and I'm trying to make it work.  Can I just change the 
>> master.cf and change bounce to go to a
>> pipe?  Like this:
>> bounceunix  -   -   n   -   0   pipe
>>   flags=DORhu user=root argv=/etc/postfix/dump_bounce.sh
>>
>> I keep getting this error though:
>> postfix/pipe[9736]: fatal: service bounce requires privileged operation
>>
>> I was trying different users besides root, but even root does not work.
>>
>>  Chris
>>
> I figured out that problem by adding a "n" to the unpriv column.
> 
>   Chris
> 

Though now I'm getting this error after sending bounce to pipe:
Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: unexpected attribute 
nrequest from bounce socket
(expecting: flags)
Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: deliver_request_get: 
error receiving common attributes
Mar 20 12:41:54 mail-dr postfix/qmgr[10151]: 9F2AF28E134: removed

Chris

Re: VERP Bounce Intercept

[Chris Dos]

Noel Jones wrote:
>>
>> Okay, since the e-mail never finishes sending because the user is
>> unknown on the other end and it is rejected
>> right away, is there another way to do this.
>>
>> The whole point of this exercise for me is to just intercept a bounce
>> back and process it internally instead
>> of bouncing it back to the person that originally sent the mail.  The
>> best way seems to be to use VERP.  Is
>> there something I'm missing or a different way to go about doing
>> this.  Maybe pass all initial bounces through
>> procmail or something to that affect?
>>
>> Chris
> 
> Internally generated bounces don't go through procmail or anything,
> they're just delivered to the original sender address.
> 
> Maybe it would be better if you describe the actual problem you're
> trying to solve rather than asking how to implement a possible solution.
> 
>   -- Noel Jones



I'm trying to intercept all hard bounced back e-mail and send it to a 
script/program for processing
internally.  I wish to prevent all notification of bounces to the person that 
sent the e-mail.

I had an idea, and I'm trying to make it work.  Can I just change the master.cf 
and change bounce to go to a
pipe?  Like this:
bounceunix  -   -   n   -   0   pipe
  flags=DORhu user=root argv=/etc/postfix/dump_bounce.sh

I keep getting this error though:
postfix/pipe[9736]: fatal: service bounce requires privileged operation

I was trying different users besides root, but even root does not work.

 Chris

Re: Performance tuning

[Victor Duchovni]

On Fri, Mar 20, 2009 at 11:27:27AM -0700, J Sloan wrote:

> For what it's worth, we've found ext3 to be far too slow for our needs.
> The best setup we've found is reiserfs, mounted with "noatime" and
> "notail" options -

Lets not start file system wars in this thread. The OP's problem is
largely unrelated to file-system selection. Most Postfix users do just
fine with a variety of file-systems, including ext3.

-- 
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: Performance tuning

[J Sloan]

For what it's worth, we've found ext3 to be far too slow for our needs.
The best setup we've found is reiserfs, mounted with "noatime" and
"notail" options -

Joe

Brandon Hilkert wrote:
> - Original Message - From: "Ralf Hildebrandt"
> 
> To: 
> Sent: Friday, March 20, 2009 6:52 AM
> Subject: Re: Performance tuning
>
>
>> * Brandon Hilkert :
>>
>>> We send out a pretty volume of emails right now using a combination of
>>> SQL and IIS SMTP. We get rates now of about 5,000/min. We're looking to
>>> not only improve the rates, but incorporate DKIM/Domainkey signing into
>>> the process. The choice has been made to go with postfix along with a
>>> queue directory on an XFS file system.
>>
>> You can check if the disk I/O is the bottleneck by simply putting the
>> queue fs in a RAM disk!
>>
>
> Sorry if this is a stupid question, but how do I go about this. I tried:
>
> mkdir /ram
> mount -t ramfs none /ram
>
> and when I send a mail, postfix says there's not enough space in the
> queue. Should I be doing it a different way?
>
> I also put the queue directory back on an ext3 partition and the rates
> went up by about a factor of two.
>
> Also, by default the syslog messages were already set with "
> -/var/log/mail.log". I disabled mail logging all together and found no
> change in rates.
>
> My disk is writing about 3 MB/s which should be well within it's
> range. I would hope even larger, but I would like to work out the
> ramfs and test for sure.
>
>
>>> I'm using postfix as a relay, and having it sign the outgoing emails
>>> with DKIM. That process was about twice as slow as without it. Without
>>> DKIM, I'm getting a rate of 700/min.
>>
>> Signing takes time! htop will tell you IO rates and CPU usage...
>>
>> -- 
>> Ralf Hildebrandt
>> Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450
>> 570-155
>> http://www.computerbeschimpfung.de
>> "Windows 95 /n./ 32 bit extensions and a graphical shell for a 16 bit
>> patch to an 8 bit operating system originally coded for a 4 bit
>> microprocessor, written by a 2 bit company that can't stand 1 bit of
>> competition." 
>

Re: Issue with smtpd_recipient_restrictions

[Victor Duchovni]

On Fri, Mar 20, 2009 at 11:39:05AM -0700, Post Freak wrote:

> Thank you for the configuration, but I am still able to send email to
> addresses not listed in allowed_users. Here is my new config:
> 
> smtpd_recipient_restrictions =
>   reject_unauth_destination,
>   check_recipient_access hash:/etc/postfix/allowed_users,
>   reject
> 
> I've restarted postfix, but I can email recipients not listed in
> allowed_users. Is there something else I'm missing?

Yes, your actual configuration differs from what you report. Test
with:

$ postconf smtpd_recipient_restrictions

it should return a single line with th three restrictions above and
intespersed with commas and white-space.

-- 
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: Issue with smtpd_recipient_restrictions

[Post Freak]

Hello,
Yes, postconf did respond with one line and 3 restrictions. Here are the 
results:

[r...@myhost postfix]# postconf smtpd_recipient_restrictions
smtpd_recipient_restrictions = reject_unauth_destination, 
check_recipient_access hash:/etc/postfix/allowed_users, reject


Thanks!





From: Victor Duchovni 
To: Post Freak 
Cc: postfix-users@postfix.org
Sent: Friday, March 20, 2009 1:51:09 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 11:39:05AM -0700, Post Freak wrote:

> Thank you for the configuration, but I am still able to send email to
> addresses not listed in allowed_users. Here is my new config:
> 
> smtpd_recipient_restrictions =
> reject_unauth_destination,
> check_recipient_access hash:/etc/postfix/allowed_users,
> reject
> 
> I've restarted postfix, but I can email recipients not listed in
> allowed_users. Is there something else I'm missing?

Yes, your actual configuration differs from what you report. Test
with:

$ postconf smtpd_recipient_restrictions

it should return a single line with th three restrictions above and
intespersed with commas and white-space.

-- 
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: Issue with smtpd_recipient_restrictions

[Victor Duchovni]

On Fri, Mar 20, 2009 at 12:00:25PM -0700, Post Freak wrote:

> Hello,
> Yes, postconf did respond with one line and 3 restrictions. Here are the 
> results:
> 
> [r...@myhost postfix]# postconf smtpd_recipient_restrictions
> smtpd_recipient_restrictions = reject_unauth_destination, 
> check_recipient_access hash:/etc/postfix/allowed_users, reject

Now prove with unedited log entries that the Postfix configured via this
main.cf file (set syslog_name=postfix-test to show that the server is
using this main.cf file and restart Postfix) accepts "RCPT TO:" commands
with a recipient that is not the $address_verify_sender and is not listed
in the allowed_users table via any of the documented access(5) lookup keys.

Show logging.
postconf -n output
postmap -q results for each full address and domain part.

postmap -q u...@example.com hash:/etc/postfix/allowed_users
postmap -q example.com hash:/etc/postfix/allowed_users
postmap -q com hash:/etc/postfix/allowed_users

consider removing "smtpd_access_maps" from "parent_domain_matches_subdomains"

-- 
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: VERP Bounce Intercept

[Duane Hill]

On Fri, 20 Mar 2009, Chris Dos wrote:


Chris Dos wrote:

Chris Dos wrote:

Noel Jones wrote:

Okay, since the e-mail never finishes sending because the user is
unknown on the other end and it is rejected
right away, is there another way to do this.

The whole point of this exercise for me is to just intercept a bounce
back and process it internally instead
of bouncing it back to the person that originally sent the mail.  The
best way seems to be to use VERP.  Is
there something I'm missing or a different way to go about doing
this.  Maybe pass all initial bounces through
procmail or something to that affect?

Chris

Internally generated bounces don't go through procmail or anything,
they're just delivered to the original sender address.

Maybe it would be better if you describe the actual problem you're
trying to solve rather than asking how to implement a possible solution.

  -- Noel Jones



I'm trying to intercept all hard bounced back e-mail and send it to a 
script/program for processing
internally.  I wish to prevent all notification of bounces to the person that 
sent the e-mail.

I had an idea, and I'm trying to make it work.  Can I just change the master.cf 
and change bounce to go to a
pipe?  Like this:
bounceunix  -   -   n   -   0   pipe
  flags=DORhu user=root argv=/etc/postfix/dump_bounce.sh

I keep getting this error though:
postfix/pipe[9736]: fatal: service bounce requires privileged operation

I was trying different users besides root, but even root does not work.

 Chris


I figured out that problem by adding a "n" to the unpriv column.

Chris



Though now I'm getting this error after sending bounce to pipe:
Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: unexpected attribute 
nrequest from bounce socket
(expecting: flags)
Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: deliver_request_get: 
error receiving common attributes
Mar 20 12:41:54 mail-dr postfix/qmgr[10151]: 9F2AF28E134: removed


Sure. You just took out Postfix's ability to handle bouncing messages 
properly. Have you looked at the man page for bounce(8) to see what its 
purpose is and all it does?

Re: Issue with pipe mail to script

[Simon]

On Fri, Mar 20, 2009 at 11:49 AM, mouss  wrote:

>
> That's possible. please do what I told you. if you did and you still
> have a problem, feel free to ask. but it's annoying for us to help fix
> problems that are known and for which the solution is as easy as to
> follow well documented procedures.

OK.. sorry, just wanted to understand the issue. I have now changed this:

127.0.0.1:10025 inet n  -   n -   -  smtpd
..
-o 
receive_override_options=no_header_body_checks,no_unknown_recipient_checks

to this:

127.0.0.1:10025 inet n  -   n -   -  smtpd
..
-o 
receive_override_options=no_address_mappings,no_header_body_checks,no_unknown_recipient_checks

And it works a treat! Thank you. So it works, but did i use
no_address_mappings correct in this case?

Thanks

Simon

Re: Postfix and virtual users with additional_condition

[Sebastian Chociwski]

OH sorry for that , heres more information:
Activmail is integer.
I checked the varchar "mail" column with default 'y' and got :
query = SELECT email FROM users WHERE email='%s'
AND mail='y'
serwersuse111:~ # postmap -q sebastian...@example.pl
mysql:/etc/postfix/mysql-virtual_email2email.cf
sebastian...@example.pl

When I set 'mail' to 'n :
serwersuse111:~ # postmap -q sebastian...@eurimage.pl
mysql:/etc/postfix/mysql-virtual_email2email.cf
serwersuse111:~ # 

So I guess it should work. But i does not and with 'n' set the mails are
sill delivered to my email account.
The log from delivery :
Mar 20 20:08:44 serwersuse111 postfix/qmgr[17359]: 8382F40E3E0:
from=, size=1547, nrcpt=1 (queue active)
Mar 20 20:08:44 serwersuse111 postfix/smtpd[17396]: disconnect from
localhost[127.0.0.1]
Mar 20 20:08:44 serwersuse111 amavis[5402]: (05402-04) Passed CLEAN,
[209.85.218.161] [209.85.218.161]  ->
, Message-ID:
<917ea74b0903201212l537eb7d1v6f5d38900b03f...@mail.gmail.com>, mail_id:
mlaPdXK+zvkO, Hits: 1.601, size: 1094, queued_as: 8382F40E3E0, 17678 ms
Mar 20 20:08:44 serwersuse111 postfix/smtp[17367]: B463840E19F:
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=18,
delays=0.29/0/0/18, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=05402-04, from
MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8382F40E3E0)
Mar 20 20:08:44 serwersuse111 postfix/qmgr[17359]: B463840E19F: removed
Mar 20 20:08:44 serwersuse111 postfix/virtual[17397]: 8382F40E3E0:
to=, relay=virtual, delay=0.14,
delays=0.07/0.01/0/0.06, dsn=2.0.0, status=sent (delivered to maildir)
Mar 20 20:08:44 serwersuse111 postfix/qmgr[17359]: 8382F40E3E0: removed
Mar 20 20:08:57 serwersuse111 postfix/smtpd[17376]: disconnect from
mail-bw0-f161.google.com[209.85.218.161]

Thank you for your time and sorry if I missed anything.


Victor Duchovni pisze:
> On Fri, Mar 20, 2009 at 03:59:05PM +0100, Sebastian Chociwski wrote:
>
>> query = SELECT email FROM users WHERE email='%s'
>>  AND mailactiv='1'
>
> Is the "mailactiv" column integer-valued or string-valued?
>
>
>> query = SELECT email FROM users WHERE mailactiv='1' AND email='%s' 
>
> Ditto, the order of constraints in SQL is not significant.
>
>> SETS THE WHOLE SYSTEM OUT OF ORDER.
>
> How are we supposed to know what "sets the whole system out of order"
> means?
>
It mean the '/etc/rc.d/postfix restart' fails with the last setting.

Re: VERP Bounce Intercept

[Victor Duchovni]

On Fri, Mar 20, 2009 at 07:09:29PM +, Duane Hill wrote:

>> Though now I'm getting this error after sending bounce to pipe:
>> Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: unexpected attribute 
>> nrequest from bounce socket
>> (expecting: flags)
>> Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: deliver_request_get: 
>> error receiving common attributes
>> Mar 20 12:41:54 mail-dr postfix/qmgr[10151]: 9F2AF28E134: removed
>
> Sure. You just took out Postfix's ability to handle bouncing messages 
> properly. Have you looked at the man page for bounce(8) to see what its 
> purpose is and all it does?

DO NOT modify in any way the Postfix bounce(8) service entries in master.cf.
It is a critical internal service.

bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce

The current list of critical services is:

# critical internal services:

pickupfifo  n   -   n   60  1   pickup
cleanup   unix  n   -   n   -   0   cleanup
qmgr  fifo  n   -   n   300 1   qmgr
tlsmgrunix  -   -   n   1000?   1   tlsmgr
rewrite   unix  -   -   n   -   -   trivial-rewrite
bounceunix  -   -   n   -   0   bounce
defer unix  -   -   n   -   0   bounce
trace unix  -   -   n   -   0   bounce
verifyunix  -   -   n   -   1   verify
flush unix  n   -   n   1000?   0   flush
showq unix  n   -   n   -   -   showq
proxymap  unix  -   -   n   -   -   proxymap
proxywrite unix -   -   n   -   1   proxymap
anvil unix  -   -   n   -   1   anvil
scacheunix  -   -   n   -   1   scache

# critical delivery agents:

error unix  -   -   n   -   -   error
retry unix  -   -   n   -   -   error

Do not modify the above except for "-o" options with "pickup" and
"cleanup" in some configurations. You can add, modify or delete the
various "normal" delivery agents or SMTP listeners:

smtp  inet  n   -   n   -   -   smtpd
smtp  unix  -   -   n   -   -   smtp
relay unix  -   -   n   -   -   smtp
  -o smtp_fallback_relay=
discard   unix  -   -   n   -   -   discard
local unix  -   n   n   -   -   local
virtual   unix  -   n   n   -   -   virtual
lmtp  unix  -   -   n   -   -   lmtp

-- 
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: Postfix and virtual users with additional_condition

[Victor Duchovni]

On Fri, Mar 20, 2009 at 08:19:42PM +0100, Sebastian Chociwski wrote:

> OH sorry for that , heres more information:
> Activmail is integer.

Then the correct SQL query syntax is:

activmail=1

NOT

activmail='1'

This is basic SQL, not Postfix.

-- 
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.

Move queue to RAMFS

[Brandon Hilkert]

I'm trying to get my queue to ramfs. I mounted a volume. When I send mail to 
it, it tells me there's insufficient storage.

I have set:

message_size_limit = 0

What do I need to do to get it to accept mail?

Re: VERP Bounce Intercept

[Chris Dos]

Victor Duchovni wrote:
> On Fri, Mar 20, 2009 at 07:09:29PM +, Duane Hill wrote:
> 
>>> Though now I'm getting this error after sending bounce to pipe:
>>> Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: unexpected attribute 
>>> nrequest from bounce socket
>>> (expecting: flags)
>>> Mar 20 12:41:54 mail-dr postfix/pipe[10163]: warning: deliver_request_get: 
>>> error receiving common attributes
>>> Mar 20 12:41:54 mail-dr postfix/qmgr[10151]: 9F2AF28E134: removed
>> Sure. You just took out Postfix's ability to handle bouncing messages 
>> properly. Have you looked at the man page for bounce(8) to see what its 
>> purpose is and all it does?
> 
> DO NOT modify in any way the Postfix bounce(8) service entries in master.cf.
> It is a critical internal service.
> 
>   bounceunix  -   -   n   -   0   bounce
>   defer unix  -   -   n   -   0   bounce
>   trace unix  -   -   n   -   0   bounce
> 
> The current list of critical services is:
> 
> # critical internal services:
> 
> pickupfifo  n   -   n   60  1   pickup
> cleanup   unix  n   -   n   -   0   cleanup
> qmgr  fifo  n   -   n   300 1   qmgr
> tlsmgrunix  -   -   n   1000?   1   tlsmgr
> rewrite   unix  -   -   n   -   -   trivial-rewrite
> bounceunix  -   -   n   -   0   bounce
> defer unix  -   -   n   -   0   bounce
> trace unix  -   -   n   -   0   bounce
> verifyunix  -   -   n   -   1   verify
> flush unix  n   -   n   1000?   0   flush
> showq unix  n   -   n   -   -   showq
> proxymap  unix  -   -   n   -   -   proxymap
> proxywrite unix -   -   n   -   1   proxymap
> anvil unix  -   -   n   -   1   anvil
> scacheunix  -   -   n   -   1   scache
> 
> # critical delivery agents:
> 
> error unix  -   -   n   -   -   error
> retry unix  -   -   n   -   -   error
> 
> Do not modify the above except for "-o" options with "pickup" and
> "cleanup" in some configurations. You can add, modify or delete the
> various "normal" delivery agents or SMTP listeners:
> 
> smtp  inet  n   -   n   -   -   smtpd
> smtp  unix  -   -   n   -   -   smtp
> relay unix  -   -   n   -   -   smtp
>   -o smtp_fallback_relay=
> discard   unix  -   -   n   -   -   discard
> local unix  -   n   n   -   -   local
> virtual   unix  -   n   n   -   -   virtual
> lmtp  unix  -   -   n   -   -   lmtp
> 

I have read what the the bounce service does.  I wish to intercept ALL hard 
bounces and process them
internally with a script.  I don't want it to bounce back to the sender that 
sent the bad message.  I haven't
been able to figure out a way to do it yet.  If the bounce service also handles 
soft bounces then this isn't
the method to take.  If there is another method that someone suggests, I'm all 
ears.

Chris

Chris

Re: Issue with smtpd_recipient_restrictions

[Post Freak]

I made the syslog_name = postfix-test change, and pasted the contents below. 
The postfr...@gmail.com isn't specified in allowed_users, but postfr...@yahoo 
is. Also, where do I remove smtpd_access_maps? I don't see that setting in 
main.cf.

/var/log/maillog:
Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]: 49B21B3DE52: 
to=, relay=gmail-smtp-in.l.google.com[209.85.221.75]:25, 
delay=4.7, delays=0.12/0.01/0.79/3.8, dsn=2.0.0, status=sent (250 2.0.0 OK 
1237578217 7si1722746qyk.143)
Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]: 49B21B3DE52: removed


The test emails:
[r...@myhost postfix]# postmap -q postfr...@yahoo.com 
hash:/etc/postfix/allowed_users
OK

[r...@myhost postfix]# postmap -q yahoo.com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1

[r...@myhost postfix]# postmap -q com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1

Contents of allowed_users:
postfr...@yahoo.com OK


output from "postconf -n":
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
always_bcc = usern...@host.com
bounce_queue_lifetime = 100d
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = all
local_header_rewrite_clients = static:all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
masquerade_domains = .host.com host.com
maximal_backoff_time = 900s
maximal_queue_lifetime = 100d
mydestination = myhost.host.com
mydomain = host.com
mynetworks = 192.168.0.0/24, 192.168.90.0/24, 192.168.20.0/24
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.2.10/README_FILES
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = reject_unauth_destination, 
check_recipient_access hash:/etc/postfix/allowed_users, reject
syslog_name = postfix-test
unknown_local_recipient_reject_code = 550


Thanks again for all of your help!





From: Victor Duchovni 
To: postfix-users@postfix.org
Sent: Friday, March 20, 2009 2:07:37 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 12:00:25PM -0700, Post Freak wrote:

> Hello,
> Yes, postconf did respond with one line and 3 restrictions. Here are the 
> results:
> 
> [r...@myhost postfix]# postconf smtpd_recipient_restrictions
> smtpd_recipient_restrictions = reject_unauth_destination, 
> check_recipient_access hash:/etc/postfix/allowed_users, reject

Now prove with unedited log entries that the Postfix configured via this
main.cf file (set syslog_name=postfix-test to show that the server is
using this main.cf file and restart Postfix) accepts "RCPT TO:" commands
with a recipient that is not the $address_verify_sender and is not listed
in the allowed_users table via any of the documented access(5) lookup keys.

Show logging.
postconf -n output
postmap -q results for each full address and domain part.

postmap -q u...@example.com hash:/etc/postfix/allowed_users
postmap -q example.com hash:/etc/postfix/allowed_users
postmap -q com hash:/etc/postfix/allowed_users

consider removing "smtpd_access_maps" from "parent_domain_matches_subdomains"

-- 
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: Issue with smtpd_recipient_restrictions

[Victor Duchovni]

On Fri, Mar 20, 2009 at 12:45:50PM -0700, Post Freak wrote:

> I made the syslog_name = postfix-test change, and pasted the contents below. 
> The postfr...@gmail.com isn't specified in allowed_users, but postfr...@yahoo 
> is. Also, where do I remove smtpd_access_maps? I don't see that setting in 
> main.cf.
> 
> /var/log/maillog:
> Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]: 49B21B3DE52: 
> to=, relay=gmail-smtp-in.l.google.com[209.85.221.75]:25, 
> delay=4.7, delays=0.12/0.01/0.79/3.8, dsn=2.0.0, status=sent (250 2.0.0 OK 
> 1237578217 7si1722746qyk.143)
> Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]: 49B21B3DE52: removed


This is a delivery agent log entry, where is the log entry showing the
message entering the Postfix queue via SMTP? Please show all the other
log entries for this queue id.

> [r...@myhost postfix]# postmap -q postfr...@yahoo.com 
> hash:/etc/postfix/allowed_users
> OK

Where is the test with @gmail.com? The tests for yahoo are irrelevant.

> maximal_backoff_time = 900s

Unwise.

> maximal_queue_lifetime = 100d

Especially in combination with this.

> smtpd_recipient_restrictions = reject_unauth_destination, 
> check_recipient_access hash:/etc/postfix/allowed_users, reject
> syslog_name = postfix-test

Your message was not submitted via SMTP, or master.cf overrides the recipient
restrictions setting.

-- 
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: Issue with smtpd_recipient_restrictions

[Post Freak]

Thanks for the feedback. I told the client the maximal_backoff_time and 
maximal_queue_lifetime settings were way too high, and could cause issues, but 
they didn't care.

How I make sure the master.cf doesn't override the recipient restrictions?



Here's everything from the maillog after I send a message. Is there another 
part of the log I'm missing?

Mar 20 14:14:25 slc-monitor1 postfix-test/pickup[22381]: 34223B3DE52: uid=0 
from=
Mar 20 14:14:25 slc-monitor1 postfix-test/cleanup[24007]: 34223B3DE52: 
message-id=<20090320201425.34223b3d...@slc-monitor1.netdeposit.com>
Mar 20 14:14:25 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52: 
from=, size=314, nrcpt=2 (queue active)
Mar 20 14:14:27 slc-monitor1 postfix-test/smtp[24009]: 34223B3DE52: 
to=, relay=gmail-smtp-in.l.google.com[209.85.221.9]:25, 
delay=2.1, delays=0.1/0.01/0.62/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 
1237580067 9si1152356qyk.122)
Mar 20 14:14:27 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52: removed


Here are the tests for the gmail account:
[r...@myhost postfix]# postmap -q postfr...@gmail.com 
hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q gmail.com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1


Thank you!





From: Victor Duchovni 
To: Post Freak 
Cc: postfix-users@postfix.org
Sent: Friday, March 20, 2009 2:57:54 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 12:45:50PM -0700, Post Freak wrote:

> I made the syslog_name = postfix-test change, and pasted the contents below. 
> The postfr...@gmail.com isn't specified in allowed_users, but postfr...@yahoo 
> is. Also, where do I remove smtpd_access_maps? I don't see that setting in 
> main.cf.
> 
> /var/log/maillog:
> Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]: 49B21B3DE52: 
> to=, relay=gmail-smtp-in.l.google.com[209.85.221.75]:25, 
> delay=4.7, delays=0.12/0.01/0.79/3.8, dsn=2.0.0, status=sent (250 2.0.0 OK 
> 1237578217 7si1722746qyk.143)
> Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]: 49B21B3DE52: removed


This is a delivery agent log entry, where is the log entry showing the
message entering the Postfix queue via SMTP? Please show all the other
log entries for this queue id.

> [r...@myhost postfix]# postmap -q postfr...@yahoo.com 
> hash:/etc/postfix/allowed_users
> OK

Where is the test with @gmail.com? The tests for yahoo are irrelevant.

> maximal_backoff_time = 900s

Unwise.

> maximal_queue_lifetime = 100d

Especially in combination with this.

> smtpd_recipient_restrictions = reject_unauth_destination, 
> check_recipient_access hash:/etc/postfix/allowed_users, reject
> syslog_name = postfix-test

Your message was not submitted via SMTP, or master.cf overrides the recipient
restrictions setting.

-- 
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: Issue with smtpd_recipient_restrictions

[Sahil Tandon]

On Mar 20, 2009, at 4:23 PM, Post Freak  wrote:

Thanks for the feedback. I told the client the maximal_backoff_time  
and maximal_queue_lifetime settings were way too high, and could  
cause issues, but they didn't care.


How I make sure the master.cf doesn't override the recipient  
restrictions?




Here's everything from the maillog after I send a message. Is there  
another part of the log I'm missing?


Mar 20 14:14:25 slc-monitor1 postfix-test/pickup[22381]:  
34223B3DE52: uid=0 from=


pickup(8)!  smtpd(8) restrictions are not applied to locally submitted  
mail.


Mar 20 14:14:25 slc-monitor1 postfix-test/cleanup[24007]:  
34223B3DE52: message-id=<20090320201425.34223b3d...@slc-monitor1.netdeposit.com 
>
Mar 20 14:14:25 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52:  
from=, size=314, nrcpt=2 (queue active)
Mar 20 14:14:27 slc-monitor1 postfix-test/smtp[24009]: 34223B3DE52:  
to=, relay=gmail-smtp- 
in.l.google.com[209.85.221.9]:25, delay=2.1,  
delays=0.1/0.01/0.62/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 1237580067 9 
si1152356qyk.122)
Mar 20 14:14:27 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52:  
removed



Here are the tests for the gmail account:
[r...@myhost postfix]# postmap -q postfr...@gmail.com hash:/etc/ 
postfix/allowed_users

[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q gmail.com hash:/etc/postfix/ 
allowed_users

[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1


Thank you!

From: Victor Duchovni 
To: Post Freak 
Cc: postfix-users@postfix.org
Sent: Friday, March 20, 2009 2:57:54 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 12:45:50PM -0700, Post Freak wrote:

> I made the syslog_name = postfix-test change, and pasted the  
contents below. The postfr...@gmail.com isn't specified in  
allowed_users, but postfr...@yahoo is. Also, where do I remove  
smtpd_access_maps? I don't see that setting in main.cf.

>
> /var/log/maillog:
> Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]:  
49B21B3DE52: to=, relay=gmail-smtp- 
in.l.google.com[209.85.221.75]:25, delay=4.7, delays=0.12/0.01/0.79/3.8 
, dsn=2.0.0, status=sent (250 2.0.0 OK 1237578217 7si1722746qyk.143)
> Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]:  
49B21B3DE52: removed



This is a delivery agent log entry, where is the log entry showing the
message entering the Postfix queue via SMTP? Please show all the other
log entries for this queue id.

> [r...@myhost postfix]# postmap -q postfr...@yahoo.com hash:/etc/ 
postfix/allowed_users

> OK

Where is the test with @gmail.com? The tests for yahoo are irrelevant.

> maximal_backoff_time = 900s

Unwise.

> maximal_queue_lifetime = 100d

Especially in combination with this.

> smtpd_recipient_restrictions = reject_unauth_destination,  
check_recipient_access hash:/etc/postfix/allowed_users, reject

> syslog_name = postfix-test

Your message was not submitted via SMTP, or master.cf overrides the  
recipient

restrictions setting.

--
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: Move queue to RAMFS

[Terry Carmen]

Brandon Hilkert wrote:
I'm trying to get my queue to ramfs. I mounted a volume. When I send 
mail to it, it tells me there's insufficient storage.
 
Not sure about the error, but in general RAMFS sounds like a bad idea 
for a number of reasons including the ability to crash your machine if 
it fills up, and the loss of messages if you lose power or have a 
hardware failure. The server should use free RAM for cache anyway, so 
I'm not sure how much of a performance improvement you'll see.


OTOH, the benchmark data would be interesting.

Also, you might want to check and see where the problem actually is, 
since I'd be amazed if postfix is actually disk-bound. It's more likely 
to be another process or something with log-level set too high. If it 
turns out to be logging and you can't reduce the log data, you could try 
moving syslog to a difference machine.


Terry

Re: Issue with smtpd_recipient_restrictions

[Post Freak]

Hello Sahil,
I'm not as concerned about the locally delivered mail. My main concern is I can 
email recipients outside the network even though I have specified the 
restriction.

Thank you.





From: Sahil Tandon 
To: Post Freak 
Cc: "postfix-users@postfix.org" 
Sent: Friday, March 20, 2009 3:34:13 PM
Subject: Re: Issue with smtpd_recipient_restrictions


On Mar 20, 2009, at 4:23 PM, Post Freak  wrote:

Thanks for the feedback. I told the client the maximal_backoff_time and 
maximal_queue_lifetime settings were way too high, and could cause issues, but 
they didn't care.

How I make sure the master.cf doesn't override the recipient restrictions?



Here's everything from the maillog after I send a message. Is there another 
part of the log I'm missing?

Mar 20 14:14:25 slc-monitor1 postfix-test/pickup[22381]: 34223B3DE52: uid=0 
from=

pickup(8)!  smtpd(8) restrictions are not applied to locally submitted mail.

Mar 20 14:14:25 slc-monitor1 postfix-test/cleanup[24007]: 34223B3DE52: 
message-id=<20090320201425.34223b3d...@slc-monitor1.netdeposit.com>
Mar 20 14:14:25 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52: 
from=, size=314, nrcpt=2 (queue active)
Mar 20 14:14:27 slc-monitor1 postfix-test/smtp[24009]: 34223B3DE52: 
to=, relay=gmail-smtp-in.l.google.com[209.85.221.9]:25, 
delay=2.1, delays=0.1/0.01/0.62/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 
1237580067 9si1152356qyk.122)
Mar 20 14:14:27 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52: removed


Here are the tests for the gmail account:
[r...@myhost postfix]# postmap -q postfr...@gmail.com 
hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q gmail.com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1


Thank you!





From: Victor Duchovni 
To: Post Freak 
Cc: postfix-users@postfix.org
Sent: Friday, March 20, 2009 2:57:54 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 12:45:50PM -0700, Post Freak wrote:

> I made the syslog_name = postfix-test change, and pasted the contents below. 
> The postfr...@gmail.com isn't specified in allowed_users, but postfr...@yahoo 
> is. Also, where do I remove smtpd_access_maps? I don't see that setting in 
> main.cf.
> 
> /var/log/maillog:
> Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]: 49B21B3DE52: 
> to=, relay=gmail-smtp-in.l.google.com[209.85.221.75]:25, 
> delay=4.7, delays=0.12/0.01/0.79/3.8, dsn=2.0.0, status=sent (250 2.0.0 OK 
> 1237578217 7si1722746qyk.143)
> Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]: 49B21B3DE52: removed


This is a delivery agent log entry, where is the log entry showing the
message entering the Postfix queue via SMTP? Please show all the other
log entries for this queue id.

> [r...@myhost postfix]# postmap -q postfr...@yahoo.com 
> hash:/etc/postfix/allowed_users
> OK

Where is the test with @gmail.com? The tests for yahoo are irrelevant.

> maximal_backoff_time = 900s

Unwise.

> maximal_queue_lifetime = 100d

Especially in combination with this.

> smtpd_recipient_restrictions = reject_unauth_destination, 
> check_recipient_access hash:/etc/postfix/allowed_users, reject
> syslog_name = postfix-test

Your message was not submitted via SMTP, or master.cf overrides the recipient
restrictions setting.

-- 
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: Issue with smtpd_recipient_restrictions

[Sahil Tandon]

On Mar 20, 2009, at 4:41 PM, Post Freak  wrote:


Hello Sahil,
I'm not as concerned about the locally delivered mail. My main  
concern is I can email recipients outside the network even though I  
have specified the restriction.


I said locally SUBMITTED.  Not locally delivered.   
smtpd_*_restrictions do not apply to mail that enters Postfix via  
pickup(8).




From: Sahil Tandon 
To: Post Freak 
Cc: "postfix-users@postfix.org" 
Sent: Friday, March 20, 2009 3:34:13 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Mar 20, 2009, at 4:23 PM, Post Freak  wrote:

Thanks for the feedback. I told the client the maximal_backoff_time  
and maximal_queue_lifetime settings were way too high, and could  
cause issues, but they didn't care.


How I make sure the master.cf doesn't override the recipient  
restrictions?




Here's everything from the maillog after I send a message. Is there  
another part of the log I'm missing?


Mar 20 14:14:25 slc-monitor1 postfix-test/pickup[22381]:  
34223B3DE52: uid=0 from=


pickup(8)!  smtpd(8) restrictions are not applied to locally  
submitted mail.


Mar 20 14:14:25 slc-monitor1 postfix-test/cleanup[24007]:  
34223B3DE52: message-id=<20090320201425.34223b3d...@slc-monitor1.netdeposit.com 
>
Mar 20 14:14:25 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52:  
from=, size=314, nrcpt=2 (queue active)
Mar 20 14:14:27 slc-monitor1 postfix-test/smtp[24009]: 34223B3DE52:  
to=, relay=gmail-smtp- 
in.l.google.com[209.85.221.9]:25, delay=2.1,  
delays=0.1/0.01/0.62/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 1237580067 9 
si1152356qyk.122)
Mar 20 14:14:27 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52:  
removed



Here are the tests for the gmail account:
[r...@myhost postfix]# postmap -q postfr...@gmail.com hash:/etc/ 
postfix/allowed_users

[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q gmail.com hash:/etc/postfix/ 
allowed_users

[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1


Thank you!

From: Victor Duchovni 
To: Post Freak 
Cc: postfix-users@postfix.org
Sent: Friday, March 20, 2009 2:57:54 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 12:45:50PM -0700, Post Freak wrote:

> I made the syslog_name = postfix-test change, and pasted the  
contents below. The postfr...@gmail.com isn't specified in  
allowed_users, but postfr...@yahoo is. Also, where do I remove  
smtpd_access_maps? I don't see that setting in main.cf.

>
> /var/log/maillog:
> Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]:  
49B21B3DE52: to=, relay=gmail-smtp- 
in.l.google.com[209.85.221.75]:25, delay=4.7, delays=0.12/0.01/0.79/3.8 
, dsn=2.0.0, status=sent (250 2.0.0 OK 1237578217 7si1722746qyk.143)
> Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]:  
49B21B3DE52: removed



This is a delivery agent log entry, where is the log entry showing  
the
message entering the Postfix queue via SMTP? Please show all the  
other

log entries for this queue id.

> [r...@myhost postfix]# postmap -q postfr...@yahoo.com hash:/etc/ 
postfix/allowed_users

> OK

Where is the test with @gmail.com? The tests for yahoo are  
irrelevant.


> maximal_backoff_time = 900s

Unwise.

> maximal_queue_lifetime = 100d

Especially in combination with this.

> smtpd_recipient_restrictions = reject_unauth_destination,  
check_recipient_access hash:/etc/postfix/allowed_users, reject

> syslog_name = postfix-test

Your message was not submitted via SMTP, or master.cf overrides the  
recipient

restrictions setting.

--
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.

Fw: Issue with smtpd_recipient_restrictions

[Post Freak]

Sorry, I did not CC postfix-users...



- Forwarded Message 
From: Post Freak 
To: Sahil Tandon 
Sent: Friday, March 20, 2009 3:50:09 PM
Subject: Re: Issue with smtpd_recipient_restrictions


AH And the light comes on!

Thank you very much for the clarification.





From: Sahil Tandon 
To: Post Freak 
Cc: "postfix-users@postfix.org" 
Sent: Friday, March 20, 2009 3:48:01 PM
Subject: Re: Issue with smtpd_recipient_restrictions


On Mar 20, 2009, at 4:41 PM, Post Freak  wrote:

Hello Sahil,
I'm not as concerned about the locally delivered mail. My main concern is I can 
email recipients outside the network even though I have specified the 
restriction.

I said locally SUBMITTED.  Not locally delivered.  smtpd_*_restrictions do not 
apply to mail that enters Postfix via pickup(8).





From: Sahil Tandon 
To: Post Freak 
Cc: "postfix-users@postfix.org" 
Sent: Friday, March 20, 2009 3:34:13 PM
Subject: Re: Issue with smtpd_recipient_restrictions


On Mar 20, 2009, at 4:23 PM, Post Freak  wrote:

Thanks for the feedback. I told the client the maximal_backoff_time and 
maximal_queue_lifetime settings were way too high, and could cause issues, but 
they didn't care.

How I make sure the master.cf doesn't override the recipient restrictions?



Here's everything from the maillog after I send a message. Is there another 
part of the log I'm missing?

Mar 20 14:14:25 slc-monitor1 postfix-test/pickup[22381]: 34223B3DE52: uid=0 
from=

pickup(8)!  smtpd(8) restrictions are not applied to locally submitted mail.

Mar 20 14:14:25 slc-monitor1 postfix-test/cleanup[24007]: 34223B3DE52: 
message-id=<20090320201425.34223b3d...@slc-monitor1.netdeposit.com>
Mar 20 14:14:25 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52: 
from=, size=314, nrcpt=2 (queue active)
Mar 20 14:14:27 slc-monitor1 postfix-test/smtp[24009]: 34223B3DE52: 
to=, relay=gmail-smtp-in.l.google.com[209.85.221.9]:25, 
delay=2.1, delays=0.1/0.01/0.62/1.3, dsn=2.0.0, status=sent (250 2.0.0 OK 
1237580067 9si1152356qyk.122)
Mar 20 14:14:27 slc-monitor1 postfix-test/qmgr[22382]: 34223B3DE52: removed


Here are the tests for the gmail account:
[r...@myhost postfix]# postmap -q postfr...@gmail.com 
hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q gmail.com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1
[r...@myhost postfix]# postmap -q com hash:/etc/postfix/allowed_users
[r...@myhost postfix]# echo $?
1


Thank you!





From: Victor Duchovni 
To: Post Freak 
Cc: postfix-users@postfix.org
Sent: Friday, March 20, 2009 2:57:54 PM
Subject: Re: Issue with smtpd_recipient_restrictions

On Fri, Mar 20, 2009 at 12:45:50PM -0700, Post Freak wrote:

> I made the syslog_name = postfix-test change, and pasted the contents below. 
> The postfr...@gmail.com isn't specified in allowed_users, but postfr...@yahoo 
> is. Also, where do I remove smtpd_access_maps? I don't see that setting in 
> main.cf.
> 
> /var/log/maillog:
> Mar 20 13:43:37 slc-monitor1 postfix-test/smtp[19788]: 49B21B3DE52: 
> to=, relay=gmail-smtp-in.l.google.com[209.85.221.75]:25, 
> delay=4.7, delays=0.12/0.01/0.79/3.8, dsn=2.0.0, status=sent (250 2.0.0 OK 
> 1237578217 7si1722746qyk.143)
> Mar 20 13:43:37 slc-monitor1 postfix-test/qmgr[19142]: 49B21B3DE52: removed


This is a delivery agent log entry, where is the log entry showing the
message entering the Postfix queue via SMTP? Please show all the other
log entries for this queue id.

> [r...@myhost postfix]# postmap -q postfr...@yahoo.com 
> hash:/etc/postfix/allowed_users
> OK

Where is the test with @gmail.com? The tests for yahoo are irrelevant.

> maximal_backoff_time = 900s

Unwise.

> maximal_queue_lifetime = 100d

Especially in combination with this.

> smtpd_recipient_restrictions = reject_unauth_destination, 
> check_recipient_access hash:/etc/postfix/allowed_users, reject
> syslog_name = postfix-test

Your message was not submitted via SMTP, or master.cf overrides the recipient
restrictions setting.

-- 
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: Issue with smtpd_recipient_restrictions

[Victor Duchovni]

On Fri, Mar 20, 2009 at 01:41:22PM -0700, Post Freak wrote:

> I'm not as concerned about the locally delivered mail. My main concern
> is I can email recipients outside the network even though I have specified
> the restriction.

The restriction is an *SMTP server* restriction and cannot possibly apply
to mail that did not arrive via SMTP.

If you want to be unable to deliver mail to other addresses, rather
than accept SMTP mail for other addresses, you need to specify transport
settings that break delivery to all other users.

default_transport = error:5.7.1 Destination access denied
transport_maps = hash:/etc/postfix/transport

transport:
u...@example.comsmtp

Or something along these lines. Of course bounces may be a bit problematic
if you accept mail from senders not on the list.

-- 
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: Move queue to RAMFS

[Brandon Hilkert]

- Original Message - 
From: "Terry Carmen" 

To: "Brandon Hilkert" 
Cc: "Postfix users" 
Sent: Friday, March 20, 2009 4:40 PM
Subject: Re: Move queue to RAMFS



Brandon Hilkert wrote:
I'm trying to get my queue to ramfs. I mounted a volume. When I send mail 
to it, it tells me there's insufficient storage.


Not sure about the error, but in general RAMFS sounds like a bad idea for 
a number of reasons including the ability to crash your machine if it 
fills up, and the loss of messages if you lose power or have a hardware 
failure. The server should use free RAM for cache anyway, so I'm not sure 
how much of a performance improvement you'll see.


OTOH, the benchmark data would be interesting.


This is entirely for disk checking. It will be in a data center where power 
isn't an issue anyway, so loss of queue isn't a problem.




Also, you might want to check and see where the problem actually is, since 
I'd be amazed if postfix is actually disk-bound. It's more likely to be 
another process or something with log-level set too high. If it turns out 
to be logging and you can't reduce the log data, you could try moving 
syslog to a difference machine.


Syslog is waiting to write to the file. I disabled logging entirely which 
showed no significant change in performance.


Re: disk relevance - Dave had a different view about that (see response 
below)


Postfix performance is primarily limited by how fast the disk can sync data.

For standard rotational disks, this is going to be primarily limited
by how fast the disk rotates.  Since your standard SATA disk reotates
at 7200 rpm, replacing it with a disk that spins faster (10k or even
15k RPM) will help immensely.  There are 10k SATA disks available,
otherwise you have to go SCSI.  Expect up to a 30% improvement with a
10k rpm disk and nearly double with a 15k rpm disk.

If you want to go significantly faster than that, you have 3 options:

1. More spindles and the appropriate RAID setup.  A RAID10 array with
4 disks should double your random IO performance.
2. IO controller with battery-backed memory cache in write-back mode.
The battery backed cache will basically allow syncs to happen nearly
instantly (as long as your cache isn't full).  This can improve
performance by an order of magnitude.
3. SSD (Solid state disk).  Intel makes some great SATA SSDs that will
absolutely fly under this kind of workload.  But before you buy any
old SSD, I highly recommend you read this article at Anandtech:
http://www.anandtech.com/storage/showdoc.aspx?i=3531
4. A combination of 1 & 2 or 2 & 3.

Hope this helps.

-Dave




Terry

Re: Postfix and virtual users with additional_condition

[Sebastian Chociwski]

I knew it must be something I am missing but the mails are still delivered.
MYSQL cut :
mailactivint(1) 0   
mailvarchar(1)  n
email2email.cf :
query = SELECT email FROM users WHERE email='%s' AND mailactiv= 1
(checked as well : query = SELECT email FROM users WHERE email='%s' AND
mailactiv=1)
And some log again :
// user with mailactiv default set to 1
serwersuse111:~ # postmap -q jare...@pro-activ.pl
mysql:/etc/postfix/mysql-virtual_email2email.cf
jare...@pro-activ.pl
// user with mailactiv changed to 0 with phpmyadmin (maybe it matters?)
serwersuse111:~ # postmap -q sebastian...@eurimage.pl
mysql:/etc/postfix/mysql-virtual_email2email.cf
serwersuse111:~ #

and maillog from delivery :
Mar 20 22:06:55 serwersuse111 postfix/smtpd[18723]: connect from
mail-bw0-f161.google.com[209.85.218.161]
Mar 20 22:06:56 serwersuse111 postfix/smtpd[18723]: 07EA440E19F:
client=mail-bw0-f161.google.com[209.85.218.161]
Mar 20 22:06:56 serwersuse111 postfix/cleanup[18732]: 07EA440E19F:
message-id=<917ea74b0903201410v61f1925dt84a44c4bc8d7b...@mail.gmail.com>
Mar 20 22:06:56 serwersuse111 postfix/qmgr[18697]: 07EA440E19F:
from=, size=4787, nrcpt=1 (queue active)
Mar 20 22:06:56 serwersuse111 amavis[5402]: (05402-05) (!!)WARN: all
primary virus scanners failed, considering backups
Mar 20 22:07:13 serwersuse111 postfix/smtpd[18739]: warning: dict_nis_init:
NIS domain name not set - NIS lookups disabled
Mar 20 22:07:13 serwersuse111 postfix/smtpd[18739]: connect from
localhost[127.0.0.1]
Mar 20 22:07:13 serwersuse111 postfix/smtpd[18739]: 80AAA40E3E0:
client=localhost[127.0.0.1]
Mar 20 22:07:13 serwersuse111 postfix/cleanup[18732]: 80AAA40E3E0:
message-id=<917ea74b0903201410v61f1925dt84a44c4bc8d7b...@mail.gmail.com>
Mar 20 22:07:13 serwersuse111 postfix/smtpd[18739]: disconnect from
localhost[127.0.0.1]
Mar 20 22:07:13 serwersuse111 postfix/qmgr[18697]: 80AAA40E3E0:
from=, size=5240, nrcpt=1 (queue active)
Mar 20 22:07:13 serwersuse111 amavis[5402]: (05402-05) Passed CLEAN,
[209.85.218.161] [209.85.218.161]  ->
, Message-ID:
<917ea74b0903201410v61f1925dt84a44c4bc8d7b...@mail.gmail.com>, mail_id:
zN+0L8bSr-Og, Hits: 1.36, size: 4787, queued_as: 80AAA40E3E0, 17228 ms
Mar 20 22:07:13 serwersuse111 postfix/smtp[18734]: 07EA440E19F:
to=, relay=127.0.0.1[127.0.0.1]:10024, delay=18,
delays=0.41/0.01/0/17, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=05402-05,
from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 80AAA40E3E0)
Mar 20 22:07:13 serwersuse111 postfix/qmgr[18697]: 07EA440E19F: removed
Mar 20 22:07:13 serwersuse111 postfix/virtual[18740]: 80AAA40E3E0:
to=, relay=virtual, delay=0.12,
delays=0.05/0.01/0/0.06, dsn=2.0.0, status=sent (delivered to maildir)
Mar 20 22:07:13 serwersuse111 postfix/qmgr[18697]: 80AAA40E3E0: removed



Victor Duchovni pisze:
> On Fri, Mar 20, 2009 at 08:19:42PM +0100, Sebastian Chociwski wrote:
>
>> OH sorry for that , heres more information:
>> Activmail is integer.
>
> Then the correct SQL query syntax is:
>
>   activmail=1
>
> NOT
>
>   activmail='1'
>
> This is basic SQL, not Postfix.
>
Good to know. Always open to learn new things.
And sorry to say it - I'm still not able to make it work.

-- 
best regards,
Sebastian Chociwski

protect mailing-/distribution list

[Heiko Baumann]

hello,

in our postfix setup we use virtual_alias_maps to build some simple
mailing-/distribution lists. now we want to reject every mail to a list
where the sender is not a member of the list.


example:

virtual_alias_maps

li...@domaina.tld us...@domain1.tld us...@domain1.tld us...@domain1.tld
li...@domainb.tld us...@domain2.tld us...@domain2.tld us...@domain2.tld

us...@domain1.tld is allowed to send to li...@domaina.tld but not to send
to li...@domainb.tld
us...@domain2.tld is allowed to send to li...@domainb.tld but not to send
to li...@domaina.tld

unknownu...@unknowndomain.tld is allowed to send to us...@domainx.tld but
not to li...@domainx.tld


to accomplish this i found
http://www.postfix.org/RESTRICTION_CLASS_README.html#internal and it seems
to work.

but im not sure how this will scale with a greater amount of lists/members
and if it would be a better decision to use some policy daemon to do this
stuff.

any recommendations?

thanks for you help!

heiko

Re: Postfix and virtual users with additional_condition

[Victor Duchovni]

On Fri, Mar 20, 2009 at 10:17:28PM +0100, Sebastian Chociwski wrote:

> I knew it must be something I am missing but the mails are still delivered.
> MYSQL cut :
> mailactiv  int(1) 0   
> mail  varchar(1)  n
> email2email.cf :
> query = SELECT email FROM users WHERE email='%s' AND mailactiv= 1
> (checked as well : query = SELECT email FROM users WHERE email='%s' AND
> mailactiv=1)

Is there any reason to expect that not matching the query should prevent
delivery? The query is an identity mapping for valid users, what purpose
does it serve? Looks neither valid nor invalid users are rewritten, so
the query seems to have no point. You are looking at the problem at
the wrong level. Ask a Postfix question, not an SQL question.

What Postfix feature are you using to distinguish between valid and
invalid users?

-- 
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.

(postfix newbe) Postfix broken after MailScanner upgrade

[Gregory Machin]

Hi
I'm green to Postfix. I have 2 anti-spam servers that I upgraded
MailScanner to the latest version and a completely new install of
MailScanner and postfix etc. All three have the same problems . the
one thing that is common to all servers is the original configs. For
the google-ing and digging around I'm still non the wiser. I have
looked file permissions etc, reinstalled MailScanner etc .. I'm out of
ideas, If someone with more experience could please advise me.

These are the errors I'm getting on all 3 servers :

Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
end-of-input on private/smtp socket while reading input attribute name
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
socket: malformed response
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
failure -- see a previous warning/fatal/panic logfile record for the
problem description
Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
/usr/libexec/postfix/smtp pid 7304 exit status 1
Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
/usr/libexec/postfix/smtp pid 7606 exit status 1
Mar 20 23:08:13 spam10 postfix/master[2135]: warning:
/usr/libexec/postfix/smtp: bad command startup -- throttling
Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
/usr/libexec/postfix/smtp pid 7607 exit status 1
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
end-of-input on private/smtp socket while reading input attribute name
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
socket: malformed response
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
failure -- see a previous warning/fatal/panic logfile record for the
problem description
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
end-of-input on private/smtp socket while reading input attribute name
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
socket: malformed response
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
failure -- see a previous warning/fatal/panic logfile record for the
problem description
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
end-of-input on private/smtp socket while reading input attribute name
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
socket: malformed response
Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
/usr/libexec/postfix/smtp pid 7608 exit status 1
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
failure -- see a previous warning/fatal/panic logfile record for the
problem description
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
end-of-input on private/smtp socket while reading input attribute name
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
socket: malformed response
Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
failure -- see a previous warning/fatal/panic logfile record for the
problem description
Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
/usr/libexec/postfix/smtp pid 7609 exit status 1


mailq has these errors that I believe are related :

0920312D5264064 Fri Mar 20 17:35:11  tku...@eee.com
(delivery temporarily suspended: unknown mail transport error)
 jpdt...@n.co.za

0902812D4 13035 Fri Mar 20 14:34:33  brint...@uuu.co.za
(delivery temporarily suspended: unknown mail transport error)
 rite...@nn.co.za

0636F12D3594450 Fri Mar 20 01:19:13  revi...@ttt.co.za
(delivery temporarily suspended: unknown mail transport error)
 ta...@xxxr.co.za

039B612D1 11579 Wed Mar 18 14:53:43  emboun...@e.co.za
(delivery temporarily suspended: unknown mail transport error)
 rus...@xxx.co.za


my configs

main.cf



queue_directory = /mnt/ramdisk/postfix
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
mail_owner = postfix
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain, localhost
unknown_local_recipient_reject_code = 550
mynetworks = 127.0.0.0/8, 66.8.84.0/23, 10.0.0.0/8, 172.0.0.0/8
relay_domains = /etc/postfix/relay
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
header_checks = regexp:/etc/postfix/header_checks
debug_peer_level = 2
debugger_command =
 PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
 xxgdb $daemon_directory/$process_name $process_id & sleep 5

sendmail_path = /usr/sbin/sendmail.postfix
newaliases_path = /usr/bin/newaliases.postfix
mailq_path = /usr/bin/mailq.postfix
setgid_group = postdrop
html_directory = no
manpage_directory = /usr/share/man
sample_directory = /usr/share/doc/postfix-2.2.8/samples
readme_directory = /usr/share/doc/postfix-2.2.8/README_FILES
allow_percent

Re: Postfix and virtual users with additional_condition

[Sebastian Chociwski]

I am (almost ;) ) 100% sure that only mail could be delivered is in ONE
mysql db.
serwersuse111:~ # cat /etc/postfix/main.cf
queue_directory=/var/spool/postfix
command_directory=/usr/sbin
daemon_directory = /usr/lib/postfix
data_directory=/var/lib/postfix
mail_owner=postfix

myhostname = suse11.eurimage.pl
mydestination = suse11.eurimage.pl, localhost, localhost.localdomain
mynetworks = 127.0.0.0/8
virtual_alias_domains =
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf,
mysql:/etc/postfix/mysql-virtual_email2email.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_mailbox_base = /home/vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
#smtpd_sasl_auth_enable = yes
#broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
check_client_access
hash:/etc/postfix/pop-before-smtp,reject_unauth_destination
#smtpd_use_tls = yes
#smtpd_tls_cert_file = /etc/postfix/smtpd.cert
#smtpd_tls_key_file = /etc/postfix/smtpd.key
transport_maps = proxy:mysql:/etc/postfix/mysql-virtual_transports.cf
virtual_create_maildirsize = yes
virtual_maildir_extended = yes
#virtual_mailbox_limit_maps =
proxy:mysql:/etc/postfix/mysql-virtual_mailbox_limit_maps.cf
#virtual_mailbox_limit_override = yes
#virtual_maildir_limit_message = "The user you are trying to reach is over
quota."
#virtual_overquota_bounce = yes
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks

_forvawrdings.cf points at empty DB
_email2email.cf points at DB I use to decide what mails to deliver
_domains.cf is DB with domains i want to accept (one column with domain
name)
_transports.cf empty DB
If I send email to adres that does not exist in email2email DB its returned
with info about "Delivery to the following recipient failed permanently:".
postmap -q works fine for me : return mail when mailactiv =1 and return
empty when mailactiv=0 .
Why postfix delivers mail that should be rejected ?
I tested one more thing :
query = SELECT email FROM users WHERE email='%s' AND mail=1
mail is y/n so it should be rejected but while postmap -q shows empty the
postfix delivers mails.
It looks like it's just ignoring anything with and after 'AND..."


Victor Duchovni pisze:
> On Fri, Mar 20, 2009 at 10:17:28PM +0100, Sebastian Chociwski wrote:
>
>> I knew it must be something I am missing but the mails are still
delivered.
>> MYSQL cut :
>> mailactiv int(1) 0   
>> mail varchar(1)  n
>> email2email.cf :
>> query = SELECT email FROM users WHERE email='%s' AND mailactiv= 1
>> (checked as well : query = SELECT email FROM users WHERE email='%s' AND
>> mailactiv=1)
>
> Is there any reason to expect that not matching the query should prevent
> delivery? The query is an identity mapping for valid users, what purpose
> does it serve? Looks neither valid nor invalid users are rewritten, so
> the query seems to have no point. You are looking at the problem at
> the wrong level. Ask a Postfix question, not an SQL question.
>
> What Postfix feature are you using to distinguish between valid and
> invalid users?
>

lost connection with [] while sending RCPT TO

[Tomasz Suchodolski]

Hello,

Today i had a mail that stuck in the queue with error:
lost connection with mail.someserver.xxx [xx.xxx.xxx.xxx] while
sending RCPT TO), so i looked at logs.
During the session, their server sent mail:
from=<> to= 
proto=SMTP helo= and got greylisted each time. 
After this, mail ended in deferred. So I whitelisted their 
adress(postgrey), flushed the queue. Again their server
sent a test message, got answer "user unknown" and finally my mail was 
delivered.


Is it common to send such testing messages ?

Regards,
Tomasz

Re: Looking for Anti-spam setting: local username/external IP

[mouss]

David A. Gershman a écrit :
> Yeah,  Thought of that a little after mailing.  Oh well, I guess I need
> to keep my efforts in later defenses (spamassassin).
> 
> Thanks.
> 
>> On Thu, Mar 19, 2009 at 3:28 PM, David A. Gershman
>>  wrote:
>>> from an external source.  I'm trying to see if there is a setting in
>>> master.cf (or other .cf file) which will reject any email from an
>>> external IP (other than my own) *and* is claiming to be from a local
>>> user account.
>> You'll block mail that was sent from your system, to an offsite
>> forward, which then redirects back to your system again.

"unauthorized" forwarding is less common today. so you can block mail
with a sender in your domain except for a list of authorized clients.

That said, until now, I have never needed such control. so use
zen.spamhaus.org, and let the rest go through spamassassin. only if you
think a lot of junk goes to spamassassin should you think of improving
your postfix defense. but then, show full headers.

PS. Please do not top post. if you don't understand what this means,
google...

Re: protect mailing-/distribution list

[mouss]

Heiko Baumann a écrit :
> hello,
> 
> in our postfix setup we use virtual_alias_maps to build some simple
> mailing-/distribution lists. now we want to reject every mail to a list
> where the sender is not a member of the list.
> 
> 
> example:
> 
> virtual_alias_maps
> 
> li...@domaina.tld us...@domain1.tld us...@domain1.tld us...@domain1.tld
> li...@domainb.tld us...@domain2.tld us...@domain2.tld us...@domain2.tld
> 
> us...@domain1.tld is allowed to send to li...@domaina.tld but not to send
> to li...@domainb.tld
> us...@domain2.tld is allowed to send to li...@domainb.tld but not to send
> to li...@domaina.tld
> 
> unknownu...@unknowndomain.tld is allowed to send to us...@domainx.tld but
> not to li...@domainx.tld
> 
> 
> to accomplish this i found
> http://www.postfix.org/RESTRICTION_CLASS_README.html#internal and it seems
> to work.
> 
> but im not sure how this will scale with a greater amount of lists/members
> and if it would be a better decision to use some policy daemon to do this
> stuff.
> 
> any recommendations?
> 

use a list manager (mailman, sympa, ...).

Re: (postfix newbe) Postfix broken after MailScanner upgrade

[mouss]

Gregory Machin a écrit :
> Hi
> I'm green to Postfix. I have 2 anti-spam servers that I upgraded
> MailScanner to the latest version and a completely new install of
> MailScanner and postfix etc. All three have the same problems . the
> one thing that is common to all servers is the original configs. For
> the google-ing and digging around I'm still non the wiser. I have
> looked file permissions etc, reinstalled MailScanner etc .. I'm out of
> ideas, If someone with more experience could please advise me.
> 
> These are the errors I'm getting on all 3 servers :
> 
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
> end-of-input on private/smtp socket while reading input attribute name
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
> socket: malformed response
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
> failure -- see a previous warning/fatal/panic logfile record for the
> problem description
> Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
> /usr/libexec/postfix/smtp pid 7304 exit status 1
> Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
> /usr/libexec/postfix/smtp pid 7606 exit status 1
> Mar 20 23:08:13 spam10 postfix/master[2135]: warning:
> /usr/libexec/postfix/smtp: bad command startup -- throttling
> Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
> /usr/libexec/postfix/smtp pid 7607 exit status 1
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
> end-of-input on private/smtp socket while reading input attribute name
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
> socket: malformed response
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
> failure -- see a previous warning/fatal/panic logfile record for the
> problem description
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
> end-of-input on private/smtp socket while reading input attribute name
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
> socket: malformed response
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
> failure -- see a previous warning/fatal/panic logfile record for the
> problem description
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
> end-of-input on private/smtp socket while reading input attribute name
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
> socket: malformed response
> Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
> /usr/libexec/postfix/smtp pid 7608 exit status 1
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
> failure -- see a previous warning/fatal/panic logfile record for the
> problem description
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: premature
> end-of-input on private/smtp socket while reading input attribute name
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: private/smtp
> socket: malformed response
> Mar 20 23:08:13 spam10 postfix/qmgr[2142]: warning: transport smtp
> failure -- see a previous warning/fatal/panic logfile record for the
> problem description
> Mar 20 23:08:13 spam10 postfix/master[2135]: warning: process
> /usr/libexec/postfix/smtp pid 7609 exit status 1
> 
> 
> mailq has these errors that I believe are related :
> 
> 0920312D5264064 Fri Mar 20 17:35:11  tku...@eee.com
> (delivery temporarily suspended: unknown mail transport error)
>  jpdt...@n.co.za
> 
> 0902812D4 13035 Fri Mar 20 14:34:33  brint...@uuu.co.za
> (delivery temporarily suspended: unknown mail transport error)
>  rite...@nn.co.za
> 
> 0636F12D3594450 Fri Mar 20 01:19:13  revi...@ttt.co.za
> (delivery temporarily suspended: unknown mail transport error)
>  ta...@xxxr.co.za
> 
> 039B612D1 11579 Wed Mar 18 14:53:43  emboun...@e.co.za
> (delivery temporarily suspended: unknown mail transport error)
>  rus...@xxx.co.za
> [snip]


just for your info, mailscanner isn't supported here.

that said, it looks like you have a transport error. Unfortunately, you
didn't show the corresponding logs. check other log lines for errors.
you may have mail that should be routed via a transport that you removed
(intentionally or not).

Re: lost connection with [] while sending RCPT TO

[mouss]

Tomasz Suchodolski a écrit :
> Hello,
> 
> Today i had a mail that stuck in the queue with error:
> lost connection with mail.someserver.xxx [xx.xxx.xxx.xxx] while
> sending RCPT TO), so i looked at logs.
> During the session, their server sent mail:
> from=<> to=
> proto=SMTP helo= and got greylisted each time.
> After this, mail ended in deferred. So I whitelisted their
> adress(postgrey), flushed the queue. Again their server
> sent a test message, got answer "user unknown" and finally my mail was
> delivered.
> 
> Is it common to send such testing messages ?
> 

that's called SAV (sender address verification). this is generally not
recommended (except for people who really know what they are doing), but
some servers do that.

it is well know that SAV and greylisting don't marry well...

Re: Performance tuning

[Wietse Venema]

Brandon Hilkert:
> >> what is best to look out and compare?
> >
> > When the disk is 100% busy, then it is the bottle neck.  Disks can
> > be 100% busy jumping around doing very little I/O.
> >
> > As Noel suggested in earlier email, try running smtp-sink which
> > does no disk I/O at all. If things are still slow, then the problem
> > is network or MS-Exchange configuration.
> 
> I found the source. How do I build it in Debian? I realize this is probably 
> a stupid question, but I don't have tons of experience with Linux.

cd $postfixsource
make

> Exchange hasn't been involved at all. I've been running everything from 
> scripts, hoping to zero in on the bottleneck.

You MUST run deliveries in parallel. SMTP is a stupid protocol;
one connection cannot saturate a server.

In fact, Postfix actually has safeguards for naive benchmark
measurements that send mail into Postfix over only a few connections.

Wietse

Re: Performance tuning

[Barney Desmond]

2009/3/21 Brandon Hilkert :
>> When the disk is 100% busy, then it is the bottle neck.  Disks can
>> be 100% busy jumping around doing very little I/O.
>>
>> As Noel suggested in earlier email, try running smtp-sink which
>> does no disk I/O at all. If things are still slow, then the problem
>> is network or MS-Exchange configuration.
>
> I found the source. How do I build it in Debian? I realize this is probably
> a stupid question, but I don't have tons of experience with Linux.

Wietse has already answered this, but packages are your friend:
http://packages.debian.org/search?searchon=contents&keywords=smtp-sink&mode=path&suite=stable&arch=any

You'll see it also includes smtp-source, just the thing to use!
http://packages.debian.org/lenny/i386/postfix/filelist

You should follow Victor's advice and check out the QSHAPE_README:
http://www.postfix.org/QSHAPE_README.html
That's got general bottleneck-finding advice, so it's widely applicable.

Remember that mail is a store-and-forward mechanism. You need to see
if it's slow to accept or slow to flush the messages (or maybe both).
Then the fix the problem based on what you see. I'd turn off DKIM
first to see how much impact it has.

I have some raw performance data available from my own testing, you
may find it interesting. It has some of my own notes/thoughts about
"how to go faster". To anyone reading it, please observe the caveats
noted at the top.
http://www.anchor.com.au/hosting/dedicated/Postfix_MTA_performance_testing

Re: Performance tuning

[Ralf Hildebrandt]

* Brandon Hilkert :

> Sorry if this is a stupid question, but how do I go about this. I tried:
>
> mkdir /ram
> mount -t ramfs none /ram

YOu need to stop postfix first
You need to make sure postfix users /ram as queue_directory

I'd rather mount things differently (tmpfs on Linux), directly "over"
/var/spool/postfix

> and when I send a mail, postfix says there's not enough space in the 
> queue. Should I be doing it a different way?

Yes, it need to be LARGE enough :)

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
Official postfix-users mantra: post FULL log information when asking
questions, since most of us have no ESP abilities.

Re: Performance tuning

[Ralf Hildebrandt]

* Brandon Hilkert :

> I was able to get it to mount to tmpfs and it showed no change in  
> performance, so that would theoretcially rule out any existing disk issue  
> right?

You said ext3 was faster, thus I think your ramfs test was flawed.

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
In our world, software has to be small, has to be debugged, has to
ship as part of a major initiative, has to avoid compatibility
problems, has to avoid end user calls.  Bill Gates

Re: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Ralf Hildebrandt" 

To: 
Sent: Friday, March 20, 2009 9:14 PM
Subject: Re: Performance tuning



* Brandon Hilkert :


I was able to get it to mount to tmpfs and it showed no change in
performance, so that would theoretcially rule out any existing disk issue
right?


You said ext3 was faster, thus I think your ramfs test was flawed.



I was able to mount it to a tmpfs partition. There was no change in 
throughput with my script on a tmpfs vs ext3 drive.


So that would mean my disk is not a contribution factor right?


--
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 
570-155

http://www.computerbeschimpfung.de
In our world, software has to be small, has to be debugged, has to
ship as part of a major initiative, has to avoid compatibility
problems, has to avoid end user calls.  Bill Gates 

Re: Performance tuning

[Ralf Hildebrandt]

* Brandon Hilkert :

>> You said ext3 was faster, thus I think your ramfs test was flawed.
>>
>
> I was able to mount it to a tmpfs partition. There was no change in  
> throughput with my script on a tmpfs vs ext3 drive.
>
> So that would mean my disk is not a contribution factor right?

Probably.

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de

Re: Performance tuning

[Duane Hill]

On Fri, 20 Mar 2009, Brandon Hilkert wrote:

I was able to mount it to a tmpfs partition. There was no change in 
throughput with my script on a tmpfs vs ext3 drive.


So that would mean my disk is not a contribution factor right?


I'm just following this thread because of curiosity.

tmpfs? Or, do you mean ramfs (like Ralf spoke of). I believe there was a 
response already made by Wietse with regards to tmpfs that stated:


"tmpfs is backed by the swap file, which is on disk."

Therefore, I would think you would not see a difference.

Re: Performance tuning

[Brandon Hilkert]

- Original Message - 
From: "Duane Hill" 

To: 
Sent: Friday, March 20, 2009 10:08 PM
Subject: Re: Performance tuning



On Fri, 20 Mar 2009, Brandon Hilkert wrote:

I was able to mount it to a tmpfs partition. There was no change in 
throughput with my script on a tmpfs vs ext3 drive.


So that would mean my disk is not a contribution factor right?


I'm just following this thread because of curiosity.

tmpfs? Or, do you mean ramfs (like Ralf spoke of). I believe there was a 
response already made by Wietse with regards to tmpfs that stated:


"tmpfs is backed by the swap file, which is on disk."

Therefore, I would think you would not see a difference.


Yeah I was kind of thinking the same thing. With tmpfs, you can easily set a 
fixed size, so postfix sees that and will allow you to place the queue in it 
because it appears larger than 1.5 * message_size_limit. However, when I 
mount a ramfs, there is no fixed size, so it looks like zero to postfix and 
will therefore not accept mail because it seems too small, even though the 
space would expand to it allow it.


I haven't figure out how to get around the messages. I tried setting the min 
queue free like I mentioned before, but anything over zero I would think 
would flag it as too much.


any thoughts on how to mount the ramfs to get a true test of running the 
queue in memory?