Re: SV: "Redirecting" all, but two, domains.

On Tue, Mar 22, 2011 at 04:48:03AM +, Jan Johansson wrote: > >main.cf: > > relay_domains = example.com > > relay_transport = relay:[mail.example.com] > > default_transport = smtp:[127.0.0.1]:10035 > > smtpd_restriction_classes = redirect_all > > > > retable = pcre:${con

SV: "Redirecting" all, but two, domains.

>main.cf: > relay_domains = example.com > relay_transport = relay:[mail.example.com] > default_transport = smtp:[127.0.0.1]:10035 > smtpd_restriction_classes = redirect_all > > retable = pcre:${config_directory}/ > redirect_all = check_client_access ${retable

Getting abused by backscatter spam

Hi There, We are using postfix on debian lenny. Everything is mysql backed and we are using amavisd-new (spamassassin with daily updates from saupdates.openprotect.com and updates.spamassassin.org & clam-av), postfix-policy greylisting and postfix-policyd-spf-python. All updates applied. But we a

attachments being logged

I'm occasionally seeing file attachments being logged, like so: postfix/smtpd[14027]: read from B8F5EDA8 [B8F5F9BD] (1420 bytes => -1 (0x)) postfix/smtpd[14027]: read from B8F5EDA8 [B8F5F9BD] (1420 bytes => 1420 (0x58C)) postfix/smtpd[14027]: 33 13 c9 09 3f ef 6f 99|0b a8 67 8c 6c

Re: Domain/User path vs. user@domain in mailroot

*sigh* nevermind, after having some coffee and waking my lazy a.. up I realized that it was querying out path from the DB not dynamically! I used postfix.admin so going to see if it was something in the setup that did it, but there is only a few users so far, so I will make the changes via mysql c

Re: Domain/User path vs. user@domain in mailroot

I just love surprises :) But back to the question, sorry I didn't put the full conf report, but both the old and new do have the virtual_mailbox_maps, but the problem is there are multiple domains, and on the old the path is as I said; /home/vmail/domain1/user. Using me as the example, the old

Re: long (non-repeating) queue ID support

It's really trivial code, given that most of the work was already > encapsulated in macros. We're dealing with trivially short strings, > so CPU performance is not a concern either. Implemented as postfix-20110321. The code change is only a few lines, less than the documentation change.

Re: Postfix 2.8.1 for Solaris

Hello Victor & Wietse, Am 07.03.2011 19:48, schrieb Victor Duchovni: Thanks for reviewing my package. >> You must: >> >> - Execute "postfix upgrade-configuration" after installing postfix. >> >> - Respect pathname and mail_owner etc. settings in existing main.cf files. > > This is done: > >

Re: Postfix 2.8.2 stable release available

> [An on-line version of this announcement will be available at > http://www.postfix.org/announcements/postfix-2.8.2.html] > > Postfix stable release 2.8.2 is available. This release has minor > fixes that are already in the experimental (2.9) release. > > - Bugfix: postscreen DNSBL scoring error.

Postfix 2.8.2 stable release available

[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-2.8.2.html] Postfix stable release 2.8.2 is available. This release has minor fixes that are already in the experimental (2.9) release. - Bugfix: postscreen DNSBL scoring error. When a clie

Re: Domain/User path vs. user@domain in mailroot

On 03/21/2011 04:11 PM, lance raymond wrote: ok next question (a little more intelligent I would hope). I am now looking at my working mail and as some test mail comes in for some users, the path is the following; /home/vmail/u...@domain.com for each. The problem is

Re: long (non-repeating) queue ID support

Victor Duchovni: > > > Also, with a little-endian base 52 queue-id, and hash depth of "2", > > > we have 2704 directories to search, while big-endian 32 x 32 takes us > > > to 977 directories as compared to 245 directories for big-endian base 16. > > > > Base 52 requires fewer levels of hashing th

Re: long (non-repeating) queue ID support

On Mon, Mar 21, 2011 at 01:29:15PM -0400, Wietse Venema wrote: > I thought of that. This is not a problem with today's default > configuration where the high-traffic queues (i.e. incoming, active) > are not hashed. > > Do you expect that there will be configurations that do hash their > high-traf

Re: long (non-repeating) queue ID support

Victor Duchovni: > On Mon, Mar 21, 2011 at 07:15:44AM -0400, Wietse Venema wrote: > > > > So my proposed update for the long queue id is: > > > > > > - 4 octets of base 32 encoded tv_usec > > > - 6+ octets of base 51 encoded tv_sec epoch time > > > - one non base 51 octet separator >

Re: "Redirecting" all, but two, domains.

On Mon, Mar 21, 2011 at 03:04:15PM +, Jan Johansson wrote: > I've been playing around with this for a bit, but I cannot find a > smooth'n'easy way to do it... > > Basically we have a server that is primarily a testing environment for a > couple of web based applications. > These applica

Re: long (non-repeating) queue ID support

On Mon, Mar 21, 2011 at 07:15:44AM -0400, Wietse Venema wrote: > > So my proposed update for the long queue id is: > > > > - 4 octets of base 32 encoded tv_usec > > - 6+ octets of base 51 encoded tv_sec epoch time > > - one non base 51 octet separator > > - inode number in base 52

Re: long (non-repeating) queue ID support

Victor Duchovni: > On Sun, Mar 20, 2011 at 03:57:45PM -0400, Wietse Venema wrote: > > > Below is the manpage entry for long queue ID support. Let me know > > if there's anything missing. > > With the first few characters of the new long queue-id encoding the > epoch-seconds time and not the micr

Domain/User path vs. user@domain in mailroot

ok next question (a little more intelligent I would hope). I am now looking at my working mail and as some test mail comes in for some users, the path is the following; /home/vmail/u...@domain.com for each. The problem is both it's not easy as more and more users get running as well as roundcube

"Redirecting" all, but two, domains.

I've been playing around with this for a bit, but I cannot find a smooth'n'easy way to do it... Basically we have a server that is primarily a testing environment for a couple of web based applications. These applications send mail. (Big surprise) These applications have a config switch whic

Re: public NIC not answering - connection refused

yes,agree with matt inet_interfaces = localhost On Mon, 21 Mar 2011 09:45:29 -0400, Matt Hayes wrote: > On 3/21/2011 9:41 AM, lance raymond wrote: >> @John - thanks. Will post that output below. @Matt - SElinux disabled, iptables stopped, so I don't think that is the case. Original post d

Re: public NIC not answering - connection refused

On 2011-03-21 9:53 AM, lance raymond wrote: > *sigh* hate the obvious. But doing a grep inet_inerfaces on the > main.cf file, there was my all, then a bit lower, a > inet_interfaces = localhost so it was getting overwritten. This is why you don't grep the main.cf, you always go

Re: public NIC not answering - connection refused

*sigh* hate the obvious. But doing a grep inet_inerfaces on the main.cffile, there was my all, then a bit lower, a inet_interfaces = localhost so it was getting overwritten. A restart, outside telnet connect worked fine. Man, I do apologize to the group for starting off with such a noob mistake

Re: public NIC not answering - connection refused

can you post your ip information of interface? please run "ipconfig -a" On Mon, 21 Mar 2011 09:41:16 -0400, lance raymond wrote: > @John - thanks. Will post that output below. > @Matt - SElinux disabled, iptables stopped, so I don't think that is the case. > > Original post did have; > "

Re: public NIC not answering - connection refused

On 3/21/2011 9:41 AM, lance raymond wrote: > @John - thanks. Will post that output below. > @Matt - SElinux disabled, iptables stopped, so I don't think that is the > case. > > Original post did have; > "intet_interfaces = all which is the only thing I have found so far. " > so I am not sure if

Re: public NIC not answering - connection refused

Zitat von Matt Hayes : On 3/21/2011 9:25 AM, lance raymond wrote: I am close to having this production server in place and working, running on CentOS 5 patch updated (thanks Steve). I have mysql working nicely with dovecot, and can send mail using both squirrelmail and roundcube but all outsi

public NIC not answering - connection refused

@John - thanks. Will post that output below. @Matt - SElinux disabled, iptables stopped, so I don't think that is the case. Original post did have; " intet_interfaces = all which is the only thing I have found so far. " so I am not sure if something was omitted, or incorrect. @John, here is the

Re: public NIC not answering - connection refused

what do you expect if postfix is configured to listen only on loopback device? tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 2080/master signature.asc Description: OpenPGP digital signature

Re: public NIC not answering - connection refused

On 3/21/2011 9:25 AM, lance raymond wrote: > I am close to having this production server in place and working, > running on CentOS 5 patch updated (thanks Steve). I have mysql working > nicely with dovecot, and can send mail using both squirrelmail and > roundcube but all outsite mail in is refus

public NIC not answering - connection refused

I am close to having this production server in place and working, running on CentOS 5 patch updated (thanks Steve). I have mysql working nicely with dovecot, and can send mail using both squirrelmail and roundcube but all outsite mail in is refused. An outside port scan shows 25 as closed, and a

RE: Upgrading Postfix and invalid/obseleted config values.

> From: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] On Behalf Of Peter > Subject: Re: Upgrading Postfix and invalid/obseleted config values. > > If you would like to have a quota on your maildir mailboxes, the > best > > solution is to always use filesystem-based qu

Re: long (non-repeating) queue ID support

Wietse Venema: > Victor Duchovni: > > On Sun, Mar 20, 2011 at 03:57:45PM -0400, Wietse Venema wrote: > > > > > Below is the manpage entry for long queue ID support. Let me know > > > if there's anything missing. > > > > With the first few characters of the new long queue-id encoding the > > epoc

Re: long (non-repeating) queue ID support

Victor Duchovni: > On Sun, Mar 20, 2011 at 03:57:45PM -0400, Wietse Venema wrote: > > > Below is the manpage entry for long queue ID support. Let me know > > if there's anything missing. > > With the first few characters of the new long queue-id encoding the > epoch-seconds time and not the micr