Strange problem with pickup process (maybe just a coincidence)

synchronize with pickup restart). Is it safe to raise those 60 seconds to a more higher value, such as 600 or so? Am I right with the synchronization hypotesis or could be something different? Thanks a lot. -- Santiago Romero

Re: Strange problem with pickup process (maybe just a coincidence)

Bastian Blank escribió: On Wed, Feb 11, 2009 at 09:00:14AM +0100, Santiago Romero wrote: I have a strange problem monitoring the pickup process: we have a monitoring system that, sometimes, warns us with pickup process not in memory What is the meaning of this message

Re: Limit rate/concurrency to a given domain

? The logfile shows in any way that I'm sending a give email with the slow transport instead of the standard smtp transport? (To verify if my config is working correctly and check if emails are going out by the right transport). Thanks for your help. -- Santiago Romero

Re: Limit rate/concurrency to a given domain

designed. Such kind of change would need 723435 patches in qmail (and that's why I'm migrating all my qmail servers to postfix). Thanks a lot. -- Santiago Romero

Accepting messages only for valid users in a secondary MX server

something similar in postfix (maintaining domains and accounts in 2 different files would be nice)? Thanks a lot. -- Santiago Romero

Re: Accepting messages only for valid users in a secondary MX server

to only for those domains, while accepting any RCPT TO for the others. Thanks. -- Santiago Romero

Possible reasons for qmgr loading the system?

see anything before the postfix restart... Thanks. -- Santiago Romero

Re: Possible reasons for qmgr loading the system?

Wietse Venema escribió: Santiago Romero: I case it happens again ... Where or what should I take a look? At OS level (disk or network I/O, processes...) I didn't see anything before the postfix restart... Try ``strace -o filename -p pid'' or the equivalent for your OS. Hi

Re: PATCH: Possible reasons for qmgr loading the system?

or lower so that the problem reproduces again faster, because it passed 5 days between the last 2 times qmgr ate the CPU...). Thanks. -- Santiago Romero

Re: PATCH: Possible reasons for qmgr loading the system?

that uses that special slow transport. Would I notice any difference in postfix behaviour because of using oqmgr instead of qmgr (less performance or something like that)? Thanks. -- Santiago Romero

Re: PATCH: Possible reasons for qmgr loading the system?

security postfix packages to be released by package maintainers, but I don't know how to force that. Thanks. -- Santiago Romero

Re: PATCH: Possible reasons for qmgr loading the system?

or should notify them to package maintainers... That's what I was asking: if the process is automatic or should I notify / help in any way. -- Santiago Romero

Re: Question about address verification in MX2 when primary MX is down...

If you want this behavior, do not use reject_unverified*. Instead, use a relay_recipient_maps that can be checked locally. Hi. This server is a secondary MX server for our customers. Those customers have their own private primary MX servers, so It's not possible for me to have a local

Re: Question about address verification in MX2 when primary MX is down...

Hi, Quoting the documentation[1]: The unverified_recipient_defer_code parameter (default 450) specifies the numerical Postfix SMTP server reply code when a recipient address probe fails with some temporary error. Some sites insist on changing this into 250. NOTE: This change turns MX servers

Re: Question about address verification in MX2 when primary MX is down...

Yes, that's what the docs say. 450 = default, defer mail if the address can't be verified. 250 = if the address can't be verified, accept it anyway. Not recommended. So, summarizing. (And, please, correct me before doing a wrong change in my config file): My current server now is a

Upgrading from 2.5.1 to 2.5.4 (sasl error????).

sasl-bin 1.5.27-3.1wood Programs for manipulating the SASL users dat Any idea? What I'm doing wrong? Thanks for any help. -- Santiago Romero

Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).

the -DUSE_CYRUS_SASL) Any idea? -- Santiago Romero

Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).

clean sometimes wasn't enough to get rid of some previous build remains. Yes, just after the tar xvzf... -- Santiago Romero

Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).

Santiago Romero wrote: I compile 2.5.1 with: make makefiles CCARGS=-DUSE_SASL_AUTH -lsasl make And SASL works. The same make sentences with 2.5.4 compiles and after the make upgrade it gives the sasl error in the logs. And compiled postfconf says: truth:~/sources/postfix/postfix-2.5.4

Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).

in such an old system I had real problems with other sasl-compiled applications. I must continue using SASL1... Is that a RedHad or Fedora system? Debian Woody (quite old, Debian 2.2). -- Santiago Romero

Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).

. PS: It compiled and worked with the -DUSE_SASL_AUTH -DUSE_CYRUS_SASL -lsasl ... just luck? -- Santiago Romero

Re: Upgrading from 2.5.1 to 2.5.4 (sasl error????).

Santiago Romero: make makefiles CCARGS=-DUSE_SASL_AUTH -DUSE_CYRUS_SASL -lsasl make See the INSTALL file. Also on-line as http://www.postfix.org/INSTALL.html See also the SASL_README file for SASL-specific command syntax. Ok, I see it: make makefiles CCARGS=-DUSE_SASL_AUTH

Re: smtpd banner problem

will connect directly to your port 25 and you'll see your nice banner :) -- Santiago Romero

Regenerate or move postfix queue

Hi. I'm running out of space for my postfix's spool directory and I'm planning to create a new 30GB partition and mount it over the current spool dir (/var/spool/postfix). How do I re-generate the queue after mounting the new partition and having an emtpy /var/spool/postfix/ ? In squid,