testing pipelining

[Kammen van, Marco, Springer SBM NL]

Hi List,

 

Is there a command line trick to test pipelining?

 

We found some very old mail servers (non postfix btw) which don't seem
to properly support pipelining, although they EHLO greet with the
PIPELINING extention 

I haven't been able to find a way to enforce actual pipelining via
simple telnet commands... 

 

If there are better mailinglists for these kind of questions then let me
know as well!


Thanks!

 

- 

Marco van Kammen
Springer Science+Business Media
System Manager & Postmaster 

- 

van Godewijckstraat 30 | 3311 GX
Office Number: 05E21 
Dordrecht | The Netherlands 

-  

tel 

 +31(78)6576446

fax 

 +31(78)6576302

- 

www.springeronline.com   
www.springer.com  

- 

 

 

Re: testing pipelining

[Wietse Venema]

Kammen van, Marco, Springer SBM NL:
> Hi List,
> 
> Is there a command line trick to test pipelining?

No, but you could use Postfix instead.

Sometimes the problem is not with the SMTP server itself, but with
a %#^#&% firewall that mis-implements the protocol.  With pipelining,
multiple commands are bundled together and the result may fill more
than one TCP packet.  Some CISCO implementations can't handle that.

http://fanf.livejournal.com/102206.html

Wietse

> We found some very old mail servers (non postfix btw) which don't seem
> to properly support pipelining, although they EHLO greet with the
> PIPELINING extention 
> 
> I haven't been able to find a way to enforce actual pipelining via
> simple telnet commands... 
> 
>  
> 
> If there are better mailinglists for these kind of questions then let me
> know as well!
> 
> 
> Thanks!
> 
>  
> 
> - 
> 
> Marco van Kammen
> Springer Science+Business Media
> System Manager & Postmaster 
> 
> - 
> 
> van Godewijckstraat 30 | 3311 GX
> Office Number: 05E21 
> Dordrecht | The Netherlands 
> 
> -  
> 
> tel 
> 
>  +31(78)6576446
> 
> fax 
> 
>  +31(78)6576302
> 
> - 
> 
> www.springeronline.com   
> www.springer.com  
> 
> - 
> 
>  
> 
>  
> 

Re: Forwarding emails, quick question

[Brian Pribis]

Victor,

On Tue, Sep 21, 2010 at 10:39 AM, Victor Duchovni
 wrote:
> On Tue, Sep 21, 2010 at 08:36:49AM -0400, Brian Pribis wrote:
>
>complain to the provider of your MUA.
>
>In any case, this thread is closed, the issue has
> NOTHING to do with Postfix. You can explore the semantics of your MUA
> in another forum.
>


Seriously?  You are suggesting I contact gmail, mozilla and the
creators of the mail program on my freebsd machine?  It doesn't work
in any of these.  The problem is NOT with the MUA.   Nor do I think
the problem is with postfix per se.  I can only assume it is with my
setup and that is what I need help with.   As I mentioned before,  I
am programmer, not a network engineer.  So I'm sure I'm missing
something.

Anyone else?

I have commented out almost everything in my main.cf and master.cf and
am only using the virtual table.

Here is the virtual:

c...@letterpress.cc brian

brian is a real live unix account on this system, and mail does indeed
get to this account.

If I email from ANY MUA to c...@letterpress.cc  FROM
br...@boxcarpress.com and hit reply-all I get:
TO = br...@boxcarpress.com
CC = c...@letterpress.cc

If I use mail on freebsd and reply I get:
TO =  c...@letterpress.cc br...@boxcarpress.com

Once again, I am including the output of postconf -n (at the end)

I have read the documents and previously (until I commented everything
out) I had postfix working with spamassassin and clamav just fine.
Other then this one problem postfix was REALLY easy to set up, so I am
just floored this one issue is so hard to figure out.

Thank you

brian

command_directory = /usr/local/sbin
config_directory = /usr/local/etc/postfix
daemon_directory = /usr/local/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
default_destination_concurrency_limit = 20
html_directory = /usr/local/share/doc/postfix
local_destination_concurrency_limit = 2
mail_owner = postfix
mailq_path = /usr/local/bin/mailq
manpage_directory = /usr/local/man
message_size_limit = 2500
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
mynetworks = 127.0.0.0/8, 174.133.15.34, 174.133.15.35, 174.133.15.36,
208.125.111.62
newaliases_path = /usr/local/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/local/share/doc/postfix
relay_domains = $mydestination, 127.0.0.1
sample_directory = /usr/local/etc/postfix
sendmail_path = /usr/local/sbin/sendmail
setgid_group = maildrop
unknown_client_reject_code = 450
unknown_hostname_reject_code = 554
unknown_local_recipient_reject_code = 550
virtual_alias_domains = letterpress.cc
virtual_alias_maps = hash:/usr/local/etc/postfix/virtual

Re: Forwarding emails, quick question

[Mark Goodge]

On 22/09/2010 13:40, Brian Pribis wrote:


Here is the virtual:

c...@letterpress.cc brian

brian is a real live unix account on this system, and mail does indeed
get to this account.

If I email from ANY MUA to c...@letterpress.cc  FROM
br...@boxcarpress.com and hit reply-all I get:
TO = br...@boxcarpress.com
CC = c...@letterpress.cc

If I use mail on freebsd and reply I get:
TO =  c...@letterpress.cc br...@boxcarpress.com

Once again, I am including the output of postconf -n (at the end)

I have read the documents and previously (until I commented everything
out) I had postfix working with spamassassin and clamav just fine.
Other then this one problem postfix was REALLY easy to set up, so I am
just floored this one issue is so hard to figure out.


Can you show us the headers, as received by the destination MUA, of four 
emails:


1. Sent from br...@boxcarpress.com to c...@letterpress.cc

2. Sent from br...@boxcarpress.com to brian @ whatever the "real" 
address of brian on the server is (ie, what you would send from the 
outside to get straight there, without an intervening forwarding step).


3 and 4. As above, but from a different sender address (one that is not 
in your domain and does not use your MX).


Mark
--
http://mark.goodge.co.uk

Re: Forwarding emails, quick question

[Brian Pribis]

Mark,

Thank you for looking at this.


The first two are sent from thunderbird and picked up by thunderbird.

The second two are sent through gmail and picked up by thunderbird.

On Wed, Sep 22, 2010 at 8:55 AM, Mark Goodge  wrote:
> On 22/09/2010 13:40, Brian Pribis wrote:

> 1. Sent from br...@boxcarpress.com to c...@letterpress.cc
>

>From - Wed Sep 22 09:01:59 2010
X-Account-Key: account9
X-UIDL: +2]!!2]Q"!QR#"!I~?"!
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-Path: 
X-Original-To: c...@letterpress.cc
Delivered-To: br...@boxcarmail.com
Received: from ns34.mmaweb.net (unknown [64.71.129.15])
by boxcarmail.com (Postfix) with ESMTP id B5FE95C066
for ; Wed, 22 Sep 2010 09:01:47 -0400 (EDT)
Received: from Brian-Pribiss-iMac.local
(rrcs-208-125-111-62.nys.biz.rr.com [208.125.111.62])
by ns34.mmaweb.net (8.13.7/8.13.7) with ESMTP id o8MD1kYN020097
for ; Wed, 22 Sep 2010 09:01:47 -0400 (EDT)
Message-ID: <4c99fe3a.6060...@boxcarpress.com>
Date: Wed, 22 Sep 2010 09:01:46 -0400
From: Brian Pribis 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: c...@letterpress.cc
Subject: test
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-UIDL: +2]!!2]Q"!QR#"!I~?"!


> 2. Sent from br...@boxcarpress.com to brian @ whatever the "real" address of
> brian on the server is (ie, what you would send from the outside to get
> straight there, without an intervening forwarding step).
>

>From - Wed Sep 22 09:03:43 2010
X-Account-Key: account9
X-UIDL: ]T#"!:,O"!DJ~!!?2N!!
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-Path: 
X-Original-To: br...@boxcarmail.com
Delivered-To: br...@boxcarmail.com
Received: from ns34.mmaweb.net (unknown [64.71.179.224])
by boxcarmail.com (Postfix) with ESMTP id 1BA6C5C066
for ; Wed, 22 Sep 2010 09:03:41 -0400 (EDT)
Received: from Brian-Pribiss-iMac.local
(rrcs-208-125-111-62.nys.biz.rr.com [208.125.111.62])
by ns34.mmaweb.net (8.13.7/8.13.7) with ESMTP id o8MD3eGM020173
for ; Wed, 22 Sep 2010 09:03:40 -0400 (EDT)
Message-ID: <4c99feac.9070...@boxcarpress.com>
Date: Wed, 22 Sep 2010 09:03:40 -0400
From: Brian Pribis 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: br...@boxcarmail.com
Subject: test
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-UIDL: ]T#"!:,O"!DJ~!!?2N!!



> 3 and 4. As above, but from a different sender address (one that is not in
> your domain and does not use your MX).
>


>From - Wed Sep 22 09:07:56 2010
X-Account-Key: account9
X-UIDL: ?a["!4:G!!bi3"!8D?!!
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-Path: 
X-Original-To: c...@letterpress.cc
Delivered-To: br...@boxcarmail.com
Received: from mail-bw0-f42.google.com (mail-bw0-f42.google.com [209.85.214.42])
by boxcarmail.com (Postfix) with ESMTP id 008BE5C066
for ; Wed, 22 Sep 2010 09:07:47 -0400 (EDT)
Received: by bwz7 with SMTP id 7so462506bwz.29
for ; Wed, 22 Sep 2010 06:07:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:mime-version:received:from:date
 :message-id:subject:to:content-type;
bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=;
b=piqUcyQ1nKLoJC6ucLRKCXObD4+K9Lma6pBHB5PZQE+IMDZUCDquG7hV7b9hCZm2Ur
 SqzWlNszQdBJU84YtsN19RrefvdwgggNji2tVwJ1zl0LD6KgQbXizZ9D1IBErDJQhrBE
 ie74039E+o6znDowsdIJ9nC11ynhbLIgLxYX4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:from:date:message-id:subject:to:content-type;
b=IDKRRPz4QU2amcgQilPf+cQRgVF0bhm4XP+gk4xzLpafppP7veqihOJ7JOcEYSnkRe
 FKodKc85yYHRoXDk7pSZB+nG1PkUjOnONemmcU2jIeOuZTk3jvRU6GOS0Iw+nInhoCIW
 Fp96Biv+LSojCioLXZdwKWxVhOmE2am72ommI=
Received: by 10.204.68.136 with SMTP id v8mr83442bki.88.1285160867329; Wed, 22
 Sep 2010 06:07:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.178.195 with HTTP; Wed, 22 Sep 2010 06:07:26 -0700 (PDT)
From: Brian Pribis 
Date: Wed, 22 Sep 2010 09:07:26 -0400
Message-ID: 
Subject: Sent from gmail to cbm
To: cbm 
Content-Type: text/plain; charset=ISO-8859-1
X-UIDL: ?a["!4:G!!bi3"!8D?!!




--

>From - Wed Sep 22 09:08:31 2010
X-Account-Key: account9
X-UIDL: ^?U!!l'M"!H#E"!MWL"!
X-Mozilla-Status: 0001
X-Mozilla-Status2: 
X-Mozilla-Keys:
Return-Path: 
X-Original-To: br...@boxcarmail.com
Delivered-To: br...@boxcarmail.com
Received: from mail-bw0-f46.google.com (mail-bw0-f46.google.com [209.85.214.46])
by boxcarmail.com (Postfix) with ESMTP id 217EB5C067
for ; Wed, 22 Sep 2010 09:08:09 -0400 (EDT)
Received: by bwz11 with SMTP id 11so542171bwz.33
for ; Wed, 22 Sep 2

Re: testing pipelining

[Ulrich Zehl]

On Wed, Sep 22, 2010 at 02:17:40PM +0200, Kammen van, Marco, Springer SBM NL 
wrote:
> Is there a command line trick to test pipelining?

swaks (http://jetmore.org/john/code/swaks/) can do pipelining.

swaks --pipeline -f ulr...@topfen.net -t ulr...@topfen.net

It's a perl program, so I do not know if you consider it "a command line 
trick".

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/22/2010 01:22 AM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/21/2010 10:57 PM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
 Since yesterday I am experiencing big problems when delivering mail to
 an alias-list. (Yes, I have set up an owner-listname alias. :-))

The problem seems to be a loop when opening some .forward files:

 8< 
16:23:47.289861 connect(16, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 
110) = 0
16:23:47.290158 send(16, "\2\0\0\0\0\0\0\0\6\0\0\0lhock\0", 18, MSG_NOSIGNAL) = 
18
16:23:47.292426 lstat64("/home/lhock/.forward", {st_mode=S_IFREG|0644, 
st_size=40, ...}) = 0
16:23:47.293302 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) = 16
16:23:47.296889 lstat64("/home/lhock/.forward", {st_mode=S_IFREG|0644, 
st_size=40, ...}) = 0
16:23:47.297719 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) = 19
[...]
16:23:50.884128 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) = 1022
16:23:50.886584 lstat64("/home/lhock/.forward", {st_mode=S_IFREG|0644, 
st_size=40, ...}) = 0
16:23:50.887138 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) = 1023
16:23:50.889588 lstat64("/home/lhock/.forward", {st_mode=S_IFREG|0644, 
st_size=40, ...}) = 0
16:23:50.890142 open("/home/lhock/.forward", O_RDONLY|O_LARGEFILE) = -1 EMFILE 
(Too many open files)
16:23:50.890482 send(7, "<20>Sep 22 16:23:50 postfix/loca"..., 110, 
MSG_NOSIGNAL) = 110
16:23:50.890847 stat64("/var/mail", {st_mode=S_IFDIR|0775, st_size=12288, ...}) 
= 0
16:23:50.891172 stat64("/var/mail/lhock", {st_mode=S_IFREG|0600, 
st_size=491843, ...}) = 0
16:23:50.891361 open("/var/mail/lhock.lock", 
O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0) = -1 EMFILE (Too many open files)
16:23:50.891662 socket(PF_FILE, SOCK_STREAM, 0) = -1 EMFILE (Too many open 
files)
16:23:50.891755 socket(PF_FILE, SOCK_STREAM, 0) = -1 EMFILE (Too many open 
files)
 8< 

I can send you the full strace output on request.

The file contains:
 8< 
x...@gmail.com
\lhock
 8< 
# ls -l /home/lhock/.forward
-rw-r--r-- 1 lhock rk 40 2010-09-15 09:57 /home/lhock/.forward
 8< 

Any hints?
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at   
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> The file contains:
>  8< 
> x...@gmail.com
> \lhock

Your loop does not reproduce.

With this in my own .forward file:

/dev/null
\wietse

Sending mail to wietse results in one copy to /dev/null
and one copy to the mailbox file, and no loop. If it looped
then we would have problem reports for this every day.

One example with "myorigin = $myhostname", "mydestination = $myhostname ".

Sep 22 11:00:10 bristle postfix/qmgr[1894]: BC0AF924782: 
from=, size=351, nrcpt=1 (queue active)
Sep 22 11:00:10 bristle postfix/local[2769]: BC0AF924782: 
to=, orig_to=, relay=local, delay=0.17, 
delays=0.13/0.05/0/0, dsn=2.0.0, status=sent (delivered to file: /dev/null)
Sep 22 11:00:10 bristle postfix/local[2769]: BC0AF924782: 
to=, orig_to=, relay=local, delay=0.21, 
delays=0.13/0.05/0/0.04, dsn=2.0.0, status=sent (delivered to mailbox)

One example with "myorigin = $mydomain", "mydestination = $mydomain ...".

Sep 22 11:03:57 bristle postfix/qmgr[2791]: 22F45924782: 
from=, size=335, nrcpt=1 (queue active)
Sep 22 11:03:57 bristle postfix/local[2808]: 22F45924782: 
to=, orig_to=, relay=local, delay=0.02, 
delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to file: /dev/null)
Sep 22 11:03:57 bristle postfix/local[2808]: 22F45924782: 
to=, orig_to=, relay=local, delay=0.02, 
delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox)

Wietse

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/22/2010 05:20 PM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> The file contains:
>>  8< 
>> x...@gmail.com
>> \lhock
> 
> Your loop does not reproduce.

I know. :(

I don't think that the .forward file or its format are causing the problems.

I can smoothly send mails directly to the users with the problematic
.forward files. (Directly as opposed to sending via the list-address.)

Maybe some kind of table overflow is causing the problems? I think the
alias-list grew to a critical size, maybe some datastructure that is
used e.g. for normalizing the destination addresses grew too big?

I am using postfix-2.5.6. Where there significant code changes in this
part of local(8)?

Is there any debug mode that I can use to get some verbose output from
local?

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: How to log/archive full outgoing mails including BCC info?

[Jeroen Geilman]

On 09/22/2010 08:17 AM, Yang Zhang wrote:

On Tue, Sep 21, 2010 at 7:07 PM, Victor Duchovni
  wrote:
   

On Tue, Sep 21, 2010 at 03:41:11PM -0700, Yang Zhang wrote:

 

That's what it does - it generates u...@domain@bcc.invalid - but I was
looking for something that preserves the BCC headers.
   

You are mightily confused. ?Bcc headers are never sent by the MUA,
so there is nothing to preserve. All that needs to be preserved is the
message content and envelope. The "Bcc" header is a user-interface
element, it is not a part of the message in-transit.
 

Good grief, I was mightily confused indeed. Thank you.
   

It would not be a "Bcc" if the list of Bcc'd recipients travelled along
with the message...
 

Actually my model of the world was that the first SMTP server was the
one to strip them out, instead of the MUA!
   


Let me add the Duh to my original reply (which already explained about 
BCC): how does it know it is the first SMTP server ?


Only the MUA knows it is the MUA.


--
Yang Zhang
http://yz.mit.edu/
   

Re: Virtual users pop3d suggestions

[Jeroen Geilman]

On 09/22/2010 02:22 AM, Noel Butler wrote:

  
  
On Tue, 2010-09-21 at 16:47 +1000, Nick Edwards wrote:
   

  
   On Tue, Sep 14, 2010 at 4:53 AM, Seth
Mattinen 
wrote:
  
  
  
 

  
   
Thanks, we have over the weekend ran two testbeds at full thrashing
with in house written scripts, the timings show after 57 hours of
constant stress tests with identical copies of various messages pop'd
by both using 1000 parallel accesses, for pop3 courier is no faster
than dovecot, we are sure if it was imap it would be a different story,
but we have no use, since sqwebmail uses pop3, we can eliminate imap
completely, the decision to our problem is simple now, after this test,
we see no reason to continue to use dovecot in its current state with
its inherit risks when courier has none of them, the move to courier is
now justified.
Thanks to all who offered alternative suggestions.


  
  
I too am considering courier due to dovecots pitfalls, we used it early
part of the millennium with qmail ourselves, it was good, despite it
being very robust, I never really liked sqwebmail    but... since an unmeasurable percentage of users use
webmail, its neither here nor there as far as I'm concerned. 
  
I'd be interested in seeing the results of your tests if possible,
off-list is fine if you want, it might help sway my decision, I like
dovecot, but a flaw that can be worked around but wont be worked around
is a flaw none the less, it might be nit-picking, but it is there, it's
always going to reindex its UID files in pop3 as well as imap, I pride
myself in having a faultless system, even though there is little risk
with pop3, it is a risk none the less, a risk that does not exist using
other software.
  
  


As already explained earlier, if there is a problem with high loads on
a docevot (pop or imap) + NFS + webmail system, don't blame dovecot.
IIRC NFS has ALWAYS had issues with high concurrency and mailbox
sharing.

It would be very instructive to see empirical proof of this issue
(proof that it lies with dovecot deliver), since I am sure dovecot's
developers would appreciate such feedback.

--
J.

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> I can smoothly send mails directly to the users with the problematic
> .forward files. (Directly as opposed to sending via the list-address.)

It also behaves as expected when I include "wietse" (with /dev/null
and \wietse in my .forward file) in an alias, whether or not that
has an owner- alias.

(if you nest aliases, then the "last" alias need the owner- alias).

FYI, nothing will change before this can be independently reproduced.
So, if you can come up with a small example that does not involve
LDAP that would help.

(there is no such thing in Postfix as an overflow; when memory runs
out, Postfix terminates the operation and tries later).

There are no major changes in local(8) source code; I compared the
2.5.something version against today's version (the changes involve
sending bounces to the owner- address, which is not at issue here).

Wietse

Re: metrics to show benefits of postfix vs. sendmail?

[Dennis Carr]

On Tue, 21 Sep 2010, Jay G. Scott wrote:




they haven't started shouting yet, but i sense it's coming.



i don't think i need to be exhaustive.  but right now
i don't have anything i can use to win this argument,
objectively, anyway.


And ed is the standard editor, and has a great memory footprint on the 
Timex Sinclair 1000. :-)


The following arguments are about as objective as you're going to get, I'm 
afraid:


1) It speaks SMTP, ESMTP, and SMTP over secure channels.  Just like 
Sendmail.  Imagine that.


2) The configuration files do not require a masters degree in both 
linguistics and computer science.  Just requires a bit of moxie.  Not 
necessarily the soda - but that's your call.


3) Last I checked, the O'Reilly book isn't as thick as the Sendmail tome.

And this one applies primarily if it is, indeed, the case:

4) It's working.  It's moving mail.  It's not causing the magic smoke to 
come out of the machine room.  Unless they plan on regular direct 
interaction with the mail server (oppose merely sending and receiving 
email), then they just need to put on the big girl panties and deal with 
it.


To be blunt, if your Sendmail guys are going to gripe about memory 
footprint, then it's probably time for them to move Sendmail off of the 
386 SX 25 with 4 MB of RAM, and perhaps relegate said 386 to maybe 
serving internal NTP for a six machine LAN. :-)  This said, if they need 
an MTA that will also do the dishes, they might want to go to Sears and 
ask somebody some questions


-Dennis

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/22/2010 01:22 AM, Wietse Venema wrote:
> Alexander 'Leo' Bergolth:
>> On 09/21/2010 10:57 PM, Wietse Venema wrote:
>>> Alexander 'Leo' Bergolth:
 Since yesterday I am experiencing big problems when delivering mail to
 an alias-list. (Yes, I have set up an owner-listname alias. :-))
>>>
>>> Do you have the RIGHT owner-listname alias.
>>
>> This seems to be the problem.
>>
>> I have set up two owner- aliases, none of both seems to work...
> 
> As documented, the owner-alias feature exists ONLY 
> IN main.cf:alias_maps NOT IN VIRTUAL ALIAS MAPS.

You are talking about virtual alias maps as configured with the
"virtual_alias_maps" config directive?

I don't use them. I am using alias_maps:

# postconf | grep ldap
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf,
ldap:/etc/postfix/ldap-groups.cf

My owner- address is defined in hash:/etc/aliases and my list address in
ldap:/etc/postfix/ldap-groups.cf.
Do both the list address and the owner- alias have to be in the same
alias-map?

>>> To avoid running out of file handles reduce the number of Postfix
>>> processes or increase your kernel tables.
>>>
>>> http://www.postfix.org/postconf.5.html#default_process_limit
>>> http://www.postfix.org/master.5.html
>>
>> I don't think that this should be a problem. default_process_limit is at
>> 100 and there is virtually no load on the server. Could this setting
>> really interfere with the local daemons behavior?
> 
> If you run fewer local processes then **BIG SURPRISE** they
> will use fewer file handles.

The local(8) process is running into a *PER PROCESS* limit, not a user
or system limit. (The system limit is 1182752.)

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Return-path header

[Alexandre Pires]

Hi Guys, I need to set the return-path header of all my outgoing mail with an 
specific e-mail address Is there any way to do this with postfix ?

Thanks
Alexandre

Re: Return-path header

[Victor Duchovni]

On Wed, Sep 22, 2010 at 04:06:34PM -0300, Alexandre Pires wrote:

> Hi Guys, I need to set the return-path header of all my outgoing mail with an 
> specific e-mail address Is there any way to do this with postfix ?

Set the envelope sender address. There is no "Return-Path" in transit,
the header is added by delivering MTAs to record the final envelope
sender address.

-- 
Viktor.

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

> >>> Do you have the RIGHT owner-listname alias.
> I am using alias_maps:
> 
> # postconf | grep ldap
> alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf,
> ldap:/etc/postfix/ldap-groups.cf
> 
> My owner- address is defined in hash:/etc/aliases and my list address in
> ldap:/etc/postfix/ldap-groups.cf.
> Do both the list address and the owner- alias have to be in the same
> alias-map?

That is not needed. The alias and owner- alias need to be found in
any file listed under alias_maps. 

This changes Postfix's error handling. The idea is that Postfix
creates a new queue file, and when one recipient fails, then Postfix
won't deliver again to the recipients that already have received
the message.

> The local(8) process is running into a *PER PROCESS* limit, not a user
> or system limit. (The system limit is 1182752.)

That is consistent with the description of one process looping.

Wietse

thanks-- Re: metrics to show benefits of postfix

[Jay G. Scott]

RE:  metrics for objective postfix vs. sendmail

Hi,

thanks to all who replied.  i was going to summarize, but, then i
realized i'm not an authority and should leave that to others, like
Victor Duchovni.

anyhoo, i'm gonna call this one done.  i'm committed to switching
to postfix.  (i already was.)  Duchovni lists several excellent points,
but everyone lists the "reading comprehension" factor.

in my case, i didn't list any sort of data mostly because i don't
have it.  every time i've gone looking for data i come back with
the same results:
(at my site) spam arrives in big slugs.  when a big
slug arrives sendmail will bog down--what wouldn't?  and the
process monitoring software will complain that sendmail is down
when it isn't.  otherwise, the machine is lightly loaded.  it
doesn't need any more firepower.  (actually, we have two external
and two internal, but the same remarks apply to all the machines.)
so getting lots of performance data and doing lots of tuning will
result in tuning the idle loop.  and nothing worthwhile will happen.
furthermore, the load on each of the four is different,
and no two of those four have equivalent hardware.

per Duchovni, postfix should be better at handling
connection requests under load, and that should silence the false
alarms.  we shall see -- they were intermittant to start so it'll
take a while to know for sure.

again, thanks to all who replied.  FWIW i was drawn to postfix because
it seemed to me that, after all those years, the MTA was due for a
bottom-up rewrite.  well, that's just my $0.02.

thanks.

j.

-- 
Jay Scott   512-835-3553g...@arlut.utexas.edu
Head of Sun Support, Sr. System Administrator
Applied Research Labs, Computer Science Div.   S224
University of Texas at Austin

Re: postfix/local: Too many open files when opening .forward

[Alexander 'Leo' Bergolth]

On 09/22/2010 04:53 PM, Alexander 'Leo' Bergolth wrote:
> On 09/22/2010 01:22 AM, Wietse Venema wrote:
>> Alexander 'Leo' Bergolth:
>>> On 09/21/2010 10:57 PM, Wietse Venema wrote:
 Alexander 'Leo' Bergolth:
> Since yesterday I am experiencing big problems when delivering mail to
> an alias-list. (Yes, I have set up an owner-listname alias. :-))

I have done another test-run with the environment variable EMAIL_VERBOSE
set.

>From the result I compared my own .forward-expansion (user abergolth)
and the first .forward that loops (user lhock).

$ grep -n "^been_here: forward " maillog-abergolth.txt
122:been_here: forward /home/abergolth/.forward: 0
235:been_here: forward /home/abergolth/.forward: 1

$ grep -n "^been_here: forward " maillog-lhock.txt
122:been_here: forward /home/lhock/.forward: 0
235:been_here: forward /home/lhock/.forward: 0
348:been_here: forward /home/lhock/.forward: 0
[...]

So maybe the problem is here:
 8< 
/*
 * Do the duplicate check.
 */
if (htable_locate(dup_filter->table, lookup_key) != 0) {
status = 1;
} else {
if (dup_filter->limit <= 0
|| dup_filter->limit > dup_filter->table->used)
htable_enter(dup_filter->table, lookup_key, (char *) 0);
status = 0;
}
 8< 

Ah! The problem seems to be the duplicate_filter_limit!

I set it to 1 and now everything works fine!

But maybe the default behavior when the dup_filter->limit is reached
should be to print out an error and abort instead of quietly not
inserting it and thus looping on the first .forward that contains an
entry for \username?

Cheers,
--leo
-- 
e-mail   ::: Leo.Bergolth (at) wu.ac.at
fax  ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria

Re: Forwarding emails, quick question

[mouss]

 Le 22/09/2010 14:40, Brian Pribis a écrit :

Victor,

On Tue, Sep 21, 2010 at 10:39 AM, Victor Duchovni
  wrote:

On Tue, Sep 21, 2010 at 08:36:49AM -0400, Brian Pribis wrote:

complain to the provider of your MUA.

In any case, this thread is closed, the issue has
NOTHING to do with Postfix. You can explore the semantics of your MUA
in another forum.



Seriously?  You are suggesting I contact gmail, mozilla and the
creators of the mail program on my freebsd machine?


Brian, with all due respect, you're being too aggressive. let's try to 
start again:


- aliases and virtual aliases only change the _envelope_ recipient. This 
has no influence on headers. if you believe it doesn't work that way for 
you, please show evidence.


- the reply button should use the Reply-To: header if present, and the 
From: header if not. if you think it doesn't work that way for you, then 
please show evidence.


- your original post says "When the email arrives in my mail client it 
arrives with t...@virtual_domain.com in the CC field. ..." if it's so, 
then this has nothing to do with virtual aliases. once again, virtual 
aliases do not change headers.


- just in case you don't, you must understand the difference between the 
envelope (which is used for routing) and headers (which are part of the 
message).



  [snip]

Re: Virtual users pop3d suggestions

[Nick Edwards]

On Thu, Sep 23, 2010 at 2:35 AM, Jeroen Geilman  wrote:

>  On 09/22/2010 02:22 AM, Noel Butler wrote:
>
> On Tue, 2010-09-21 at 16:47 +1000, Nick Edwards wrote:
>
>
>
>  On Tue, Sep 14, 2010 at 4:53 AM, Seth Mattinen 
> wrote:
>
>
>
>
> Thanks, we have over the weekend ran two testbeds at full thrashing with in
> house written scripts, the timings show after 57 hours of constant stress
> tests with identical copies of various messages pop'd by both using 1000
> parallel accesses, for pop3 courier is no faster than dovecot, we are sure
> if it was imap it would be a different story, but we have no use, since
> sqwebmail uses pop3, we can eliminate imap completely, the decision to our
> problem is simple now, after this test, we see no reason to continue to use
> dovecot in its current state with its inherit risks when courier has none of
> them, the move to courier is now justified.
> Thanks to all who offered alternative suggestions.
>
>
>
> I too am considering courier due to dovecots pitfalls, we used it early
> part of the millennium with qmail ourselves, it was good, despite it being
> very robust, I never really liked sqwebmail [image: :)]   but... since an
> unmeasurable percentage of users use webmail, its neither here nor there as
> far as I'm concerned.
>
> I'd be interested in seeing the results of your tests if possible, off-list
> is fine if you want, it might help sway my decision, I like dovecot, but a
> flaw that can be worked around but wont be worked around is a flaw none the
> less, it might be nit-picking, but it is there, it's always going to reindex
> its UID files in pop3 as well as imap, I pride myself in having a faultless
> system, even though there is little risk with pop3, it is a risk none the
> less, a risk that does not exist using other software.
>
>
>
> As already explained earlier, if there is a problem with high loads on a
> docevot (pop or imap) + NFS + webmail system, don't blame dovecot.
> IIRC NFS has ALWAYS had issues with high concurrency and mailbox sharing.
>
> It would be very instructive to see empirical proof of this issue (proof
> that it lies with dovecot deliver), since I am sure dovecot's developers
> would appreciate such feedback.
>
>

This tests I conducted were NOT over NFS, as anyone using NFS would be aware
of its bandwith use which  serves perfectly well on a Gbit LAN anyhow.
The tests were conducted on a local machine.
The dovecot developer would not care that dovecots pop3 speed matches that
of couriers pop3, he has stated publicly dovecot is developed primarily as
imap server, read the dovecot lists archives if you are not subscribed
there. Everyone knows that dovecots imap is faster, but we are not talking
about imap here.

Nick




> J.
>
>

Re: Virtual users pop3d suggestions

[Nick Edwards]

On Wed, Sep 22, 2010 at 10:22 AM, Noel Butler wrote:

>  On Tue, 2010-09-21 at 16:47 +1000, Nick Edwards wrote:
>
>
>
>  On Tue, Sep 14, 2010 at 4:53 AM, Seth Mattinen 
> wrote:
>
>
>
>
> Thanks, we have over the weekend ran two testbeds at full thrashing with in
> house written scripts, the timings show after 57 hours of constant stress
> tests with identical copies of various messages pop'd by both using 1000
> parallel accesses, for pop3 courier is no faster than dovecot, we are sure
> if it was imap it would be a different story, but we have no use, since
> sqwebmail uses pop3, we can eliminate imap completely, the decision to our
> problem is simple now, after this test, we see no reason to continue to use
> dovecot in its current state with its inherit risks when courier has none of
> them, the move to courier is now justified.
> Thanks to all who offered alternative suggestions.
>
>
>
> I too am considering courier due to dovecots pitfalls, we used it early
> part of the millennium with qmail ourselves, it was good, despite it being
> very robust, I never really liked sqwebmail [image: :)]   but... since an
> unmeasurable percentage of users use webmail, its neither here nor there as
> far as I'm concerned.
>
> I'd be interested in seeing the results of your tests if possible, off-list
> is fine if you want, it might help sway my decision, I like dovecot, but a
> flaw that can be worked around but wont be worked around is a flaw none the
> less, it might be nit-picking, but it is there, it's always going to reindex
> its UID files in pop3 as well as imap, I pride myself in having a faultless
> system, even though there is little risk with pop3, it is a risk none the
> less, a risk that does not exist using other software.
>
>
>
Sure thing, I'll forward it off-list in a brief moment.
By the way, I need to thank you, given your discussion with Timo was one
that had set alarm bells off on this, and the thread with Eddie confirmed
the risks, can't understand Timo's attitude towards it, but as he said maybe
dovecot is not for anyone who needs reliable pop3 in NFS.
<>

Re: thanks-- Re: metrics to show benefits of postfix

[Jeroen Geilman]

On 09/22/2010 09:57 PM, Jay G. Scott wrote:

(at my site) spam arrives in big slugs.  when a big
slug arrives sendmail will bog down--what wouldn't?


A properly configured postfix 2.7+ with postscreen wouldn't.

AFAIK your stated problem is exactly why postscreen was developed: to 
keep known spammers (who are on RBLs and/or try to subvert the 
protocols) away from the expensive smtpd daemon, and whitelist regular, 
more trusted clients so they may bypass the stricter and slower 
postscreen tests.


I don't know if anybody has run tests of this yet (it's still kinda 
new), but it would be instructive to compare a "regular" postfix setup 
(pre-postscreen) to a postscreen setup with fairly strict settings, with 
respect to the load when a large spam dump hits.



--
J.

Re: Virtual users pop3d suggestions

[Jeroen Geilman]

On 09/23/2010 12:01 AM, Nick Edwards wrote:



On Thu, Sep 23, 2010 at 2:35 AM, Jeroen Geilman > wrote:


On 09/22/2010 02:22 AM, Noel Butler wrote:

On Tue, 2010-09-21 at 16:47 +1000, Nick Edwards wrote:



On Tue, Sep 14, 2010 at 4:53 AM, Seth Mattinen
mailto:se...@rollernet.us>> wrote: 





Thanks, we have over the weekend ran two testbeds at full
thrashing with in house written scripts, the timings show after
57 hours of constant stress tests with identical copies of
various messages pop'd by both using 1000 parallel accesses, for
pop3 courier is no faster than dovecot, we are sure if it was
imap it would be a different story, but we have no use, since
sqwebmail uses pop3, we can eliminate imap completely, the
decision to our problem is simple now, after this test, we see
no reason to continue to use dovecot in its current state with
its inherit risks when courier has none of them, the move to
courier is now justified.
Thanks to all who offered alternative suggestions.




I too am considering courier due to dovecots pitfalls, we used it
early part of the millennium with qmail ourselves, it was good,
despite it being very robust, I never really liked sqwebmail :)  
but... since an unmeasurable percentage of users use webmail, its

neither here nor there as far as I'm concerned.

I'd be interested in seeing the results of your tests if
possible, off-list is fine if you want, it might help sway my
decision, I like dovecot, but a flaw that can be worked around
but wont be worked around is a flaw none the less, it might be
nit-picking, but it is there, it's always going to reindex its
UID files in pop3 as well as imap, I pride myself in having a
faultless system, even though there is little risk with pop3, it
is a risk none the less, a risk that does not exist using other
software.




As already explained earlier, if there is a problem with high
loads on a docevot (pop or imap) + NFS + webmail system, don't
blame dovecot.
IIRC NFS has ALWAYS had issues with high concurrency and mailbox
sharing.

It would be very instructive to see empirical proof of this issue
(proof that it lies with dovecot deliver), since I am sure
dovecot's developers would appreciate such feedback.



This tests I conducted were NOT over NFS, as anyone using NFS would be 
aware of its bandwith use which  serves perfectly well on a Gbit LAN 
anyhow.

The tests were conducted on a local machine.
The dovecot developer would not care that dovecots pop3 speed matches 
that of couriers pop3, he has stated publicly dovecot is developed 
primarily as imap server, read the dovecot lists archives if you are 
not subscribed there. Everyone knows that dovecots imap is faster, but 
we are not talking about imap here.


Oh that was my mistake then, I was certain I saw somebody in this thread 
mention IMAP performance and integrity.


Mea culpa, et al.

Re: Return-path header

[Alexandre Pires]

Thanks Viktor, but how can I set envelop sender address in postfix ?

Thanks
Alexandre

- Original Message - 
From: "Victor Duchovni" 

To: 
Sent: Wednesday, September 22, 2010 4:13 PM
Subject: Re: Return-path header



On Wed, Sep 22, 2010 at 04:06:34PM -0300, Alexandre Pires wrote:

Hi Guys, I need to set the return-path header of all my outgoing mail 
with an specific e-mail address Is there any way to do this with postfix 
?


Set the envelope sender address. There is no "Return-Path" in transit,
the header is added by delivering MTAs to record the final envelope
sender address.

--
Viktor. 

Re: Problem with postfix-dnswl-permit (Was Re: REJECT mails to a specific domain -> ERROR mail to postmaster)

[mouss]

 Le 22/09/2010 03:57, Stan Hoeppner a écrit :

Wietse Venema put forth on 9/21/2010 10:12 AM:

Michael Weissenbacher:

Hi Wietse!


Michael Weissenbacher:

Sep 21 15:04:58 smtp1 postfix/smtpd[14679]: warning: unknown smtpd
restriction: "med"

That is also a configuration error.


This error was really HARD to track. Took me the whole day. But now i
finally found the real cause. On this server I am using the DNSWL from
www.dnswl.org, following the instructions found at
[http://www.dnswl.org/tech#postfix]. They provide a file named
postfix-dnswl-permit which is containing lines like this one:
137.208.3.15/32 permit_auth_destination med wu-wien.ac.at DNSWLId 7368

That is not documented Postfix syntax.

postfix-dnswl-permit lines should not have the scoring comment text
that's in postfix-dnswl-header.  It is useless to Postfix and it breaks
things:

postfix-dnswl-header
222.255.237.6/32  PREPEND X-REPLACEME: low vinabook.com DNSWLId 17147

postfix-dnswl-permit
222.255.237.6/32  permit_auth_destination low vinabook.com DNSWLId 17147

Michael you should contact dnswl about this.  Either you are the first
to run into a problem with it, or their script(s) that create
postfix-dnswl-permit have changed recently.



no, it was that way since a long time. and sigh, I noticed that a long 
long time ago but I focused on the header part...

(I've BCc'd Mathias)


  I'm not a user, so I don't
know what the file content looked like before a few minutes ago.
Regardless, they need to strip the scoring text from
postfix-dnswl-permit lines as, again, it is useless and breaks things.

Re: postfix/local: Too many open files when opening .forward

[Wietse Venema]

Alexander 'Leo' Bergolth:
> Ah! The problem seems to be the duplicate_filter_limit!
> 
> I set it to 1 and now everything works fine!

For the last time, you really should use the proper owner- alias
when delivering mail to a list. Then, one local(8) process will
never attempt to deliver more than 1000 recipients.

As notes in previous reply, the owner- alias is needed for
the "last" alias when you have nested ones.

Wietse

Re: thanks-- Re: metrics to show benefits of postfix

[Stan Hoeppner]

Jeroen Geilman put forth on 9/22/2010 5:06 PM:

> I don't know if anybody has run tests of this yet (it's still kinda
> new), but it would be instructive to compare a "regular" postfix setup
> (pre-postscreen) to a postscreen setup with fairly strict settings, with
> respect to the load when a large spam dump hits.

As I understand postscreen...

This is highly dependent on the spam source(s).  If the dump is from
malware spam bots then postscreen will likely help considerably.  If
it's coming from a large snowshoe farm(s) using real MTAs, and not
listed by any dnsbls, then postscreen may not help much, if at all.  In
this latter case you'll be highly dependent on your content filters.

So WRT snowshoe, postscreen changes the game little, unless the IPs are
dnsbl listed.  Snowshoe often aren't listed at all, but Spamhaus is
doing better today in this regard.  Invaluement's ivmSIP and ivmSIP/24
target snowshoe spam sources specifically, and would be a good addition
to anyone's postscreen dnsbl config.  Unfortunately the Invaluement
lists are not free, although they are relatively inexpensive.  They also
must be hosted locally via rbldnsd or BIND (or any dns server using BIND
format).  http://www.invaluement.net

-- 
Stan