Re: about relay server

[ram]

On Mon, 2009-03-09 at 23:40 -0700, tom lee wrote:
> hello,
> 
> I checked the doc about the mail relay in postfix and still not
> clear about two issues.
> 
> I have mail sending from machine A to machine B,  machine B is a relay
> server forwarding the email to machine C (target machine).
> 
> I want to make sure there is no emails bouncing back from either
> machine B or machine C to machine A.
> can it be done?
> 
> If machine C is down,  relay machine B will spool all emails till
> machine C is up.
> what configuration adjustment should I make for relay machine B?
> is there a way to adjust the mail holding days in the relay machine B?

Do you want this limit for all mails , or only for mails to machine B ?

http://www.postfix.org/postconf.5.html

Look for 
bounce_queue_lifetime
maximal_queue_lifetime







> 
> any help is appreciated.
> 
> Tom

Re: virtual_alias_maps

[LuKreme]

On 9-Mar-2009, at 15:58, mouss wrote:

you must understand the difference between
virtual_mailbox_domains
and
virtual_alias_domains


I understand the difference, I have virtual_mailbox_domains assigned  
and I don't have virtual_alias_domains :)


Actually, isn't virtual_mailbox_domains default value ($virtual_maps)  
built from the contents of $config_directory/virtual?


--
Ah, you're a Penguin too? Pilgrim, my son. Pilgrim. Yes, of the
Hare Krishnas. Hairy Fishnuts.

send rate problems

[Tony Liu]

Hi ,

I've controlled the mails delivery rate( F.E hotmail ,1mail /10s) in
postfix,  when this mail is delivered the first time, this rate is okay, but
there is another problem shows,  if some mails are back into queue for
reject reason from one ISP(hotmail), it looks like the re-sending rate is
not at this rate(I got if from analysis mail logs) , Is there is any way to
resolve it?

Thanks in advance!

Tony 

Re: send rate problems

[Wietse Venema]

Tony Liu:
> Hi ,
> 
> I've controlled the mails delivery rate( F.E hotmail ,1mail /10s) in
> postfix,  when this mail is delivered the first time, this rate is okay, but
> there is another problem shows,  if some mails are back into queue for
> reject reason from one ISP(hotmail), it looks like the re-sending rate is
> not at this rate(I got if from analysis mail logs) , Is there is any way to
> resolve it?

The _rate_delay applies to all messages with the same next-hop
destination. If you disagree with this, then you must show the
actual numbers:

Time of day, Recipient domain, Messages per minute.

This is a matter of grep, awk, sort, uniq -c

Wietse

Re: virtual_alias_maps

[Wietse Venema]

LuKreme:
> On 9-Mar-2009, at 15:58, mouss wrote:
> > you must understand the difference between
> > virtual_mailbox_domains
> > and
> > virtual_alias_domains
> 
> I understand the difference, I have virtual_mailbox_domains assigned  
> and I don't have virtual_alias_domains :)

By default, virtual_alias_domains=$virtual_alias_maps, so you have
it unless you set it to an empty value (virtual_alias_domains=).

Wietse

Re: virtual_alias_maps

[Sahil Tandon]

On Mar 10, 2009, at 4:29 AM, LuKreme  wrote:


On 9-Mar-2009, at 15:58, mouss wrote:

you must understand the difference between
   virtual_mailbox_domains
and
   virtual_alias_domains


I understand the difference, I have virtual_mailbox_domains assigned  
and I don't have virtual_alias_domains :)


Ok let's try this again. As a few people on this list have politely  
indicated, you *DO* have virtual_alias_domains set unless you  
explicitly unset it in main.cf.  See the default value for further  
enlightenment.


--
Sahil Tandon 

Sensible config?

[Gaby Vanhegan]

Is this sane or is it going to cause problems?

/etc/postfix/main.cf:
...
# Valid local users only exist in these locations
local_recipient_maps = proxy:unix:passwd.byname $alias_maps  
$virtual_alias_maps

...
# What are the domains that we handle mail for?
virtual_alias_domains = hash:/etc/postfix/virtual_domains
virtual_alias_maps = hash:/etc/postfix/virtual

Should I be omitting the $virtual_alias_maps from the  
local_recipient_maps or does it make no difference at all?


G.

--
Junkets for bunterish lickspittles since 1998!
http://www.playr.co.uk/

RE: Outbound mail routing

[Zachary Fortna]

Is it possible to do this on the domain level as opposed to the user level?  
That way everything from example.com goes to gateway 1 and everything from 
example.net goes to gateway 2?

-Original Message-
From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] 
On Behalf Of Victor Duchovni
Sent: Monday, March 09, 2009 2:24 PM
To: postfix-users@postfix.org
Subject: Re: Outbound mail routing

On Mon, Mar 09, 2009 at 02:10:03PM -0400, Zachary Fortna wrote:

> Is it possible to route outbound messages based upon the domain of the from 
> address?  For example:
> 
> If u...@example.com sends and outbound 
> message it is routed to host1.mailrelay.com and if 
> u...@test.com sends and outbound message it is 
> routed to host2.mailrelay.com
> 
> Thanks in advance for any assistance.

http://www.postfix.org/SOHO_README.html#client_sasl_sender

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

--
This message was scanned by ESVA and is believed to be clean.
Click here to report this message as spam. 
http://nospam.cxtec.com/cgi-bin/learn-msg.cgi?id=67E55186784.96A0E

Re: Sensible config?

[Brian Evans - Postfix List]

Gaby Vanhegan wrote:
> Is this sane or is it going to cause problems?
>
> /etc/postfix/main.cf:
> ...
> # Valid local users only exist in these locations
> local_recipient_maps = proxy:unix:passwd.byname $alias_maps
> $virtual_alias_maps
> ...
> # What are the domains that we handle mail for?
> virtual_alias_domains = hash:/etc/postfix/virtual_domains
> virtual_alias_maps = hash:/etc/postfix/virtual
>
> Should I be omitting the $virtual_alias_maps from the
> local_recipient_maps or does it make no difference at all?
>
Do not include virtual_alias_maps in local_recipient_maps.
virtual_alias_maps are checked globally for all Address Classes.

For more on Address Classes, see
http://www.postfix.org/ADDRESS_CLASS_README.html

Re: hold all relayed mail by default

[Charles Marcus]

On 3/9/2009 6:12 PM, mouss wrote:
>> It will never fail that the user will decide right after clicking the
>> send button that they want to recall it, no matter how long they wait
>> prior to sending...

> and they will also decide to recall it after it was "released" ;-p

Of course... but all joking aside, almost every time someone has asked
me about this, it was within a minute or two of them sending it, so a 5
- or maybe 7 or 8 at most - minute delay really would serve the majority
of cases I've personally encountered...

>> I can't tell you how many times I've had to explain to one of our users
>> why we cannot recall their message - whcih usually ends up with me
>> describing how this exchange capability works, and why it only works
>> under certain limited circumstances, which does NOT include any
>> destinations that are NOT exchange servers configured to cooperate with
>> these requests.

> next time: insult him, then "recall the insult", and see if he accepts ;-p
> 
> or if he is stronger than you, ask him how to recall a phone call ;--p

Funny, but obviously not a real comparison ;)

>> I only said it was an interesting idea, and wondered if it could be
>> automated... I'm still not sure it *should* be done... :)

> it can be automated. the hard part is to define the criteria (when to
> keep, when to "release") and how to recall (how does user tell the
> system that he wants to recall a message,

Well, release after expiry time is easy - as for how the user recalls,
one way would be to define a special email address (ie,
 where example.com is your domain, and tell the user
to simply go to their 'Sent' folder, click the 'Reply button for the
message they want to recall, and change the destination address to
. The magic, of course, would be the script that
processes these requests...

-- 

Best regards,

Charles

Re: v2.5.5 showq and postcat date/time stamp discrepancy

[Glen B]

 
  I'm running the commands from a SSH shell logged in as root. What do you mean 
by setuid wrapper?
 
GlenB

--- On Tue, 3/10/09, Victor Duchovni  wrote:

From: Victor Duchovni 
Subject: Re: v2.5.5 showq and postcat date/time stamp discrepancy
To: postfix-users@postfix.org
Date: Tuesday, March 10, 2009, 1:35 AM

On Tue, Mar 10, 2009 at 01:01:37AM -0400, Glen B wrote:

>
> Hi,
>
> Postfix 2.5.5 on Debian
>
> I've just noticed a discrepancy between showq (postqueue -p) and
postcat. 
> I've looked through the code, played with the conversion code in
postcat 
> and I honestly can not figure out what's going wrong:
>
> -Queue ID- --Size-- Arrival Time -Sender/Recipient---
> DBBAD4A340AD  827 Mon Mar  9 10:29:27  root
>
> *** ENVELOPE RECORDS /var/spool/postfix/maildrop/DBBAD4A340AD ***
> message_arrival_time: Mon Mar  9 06:29:27 2009

Don't use a setuid wrapper to run postcat. When Potfix commands run
with uid != euid, they don't trust the environment, and always report
GMT. If you run "postcat" and "mailq" with uid == euid == 0
(root),
the results are consistent.

-- 
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: Sensible config?

[Gaby Vanhegan]

On 10 Mar 2009, at 13:24, Brian Evans - Postfix List wrote:


Do not include virtual_alias_maps in local_recipient_maps.
virtual_alias_maps are checked globally for all Address Classes.

For more on Address Classes, see
http://www.postfix.org/ADDRESS_CLASS_README.html


That makes sense.  I'm not sure why I had it there in the first place,  
I thought it seemed superfluous...


--
Uganda Maximum - Enemy of the English Thrust
http://www.playr.co.uk/

Re: v2.5.5 showq and postcat date/time stamp discrepancy

[Wietse Venema]

Glen B:
> ?
> ? I'm running the commands from a SSH shell logged in as root. What do you 
> mean by setuid wrapper?
> ?

Type the following commands, and report the output:

$ date
$ mailq | grep DBBAD4A340AD
$ date

This may very well be a Debian bug where they run daemons chrooted
but don't provide the correct timezone file inside the jail.

Wietse

RE: Outbound mail routing

[J.P. Trosclair]

On Tue, 10 Mar 2009 09:12:43 -0400, Zachary Fortna 
wrote:
> Is it possible to do this on the domain level as opposed to the user
level?
>  That way everything from example.com goes to gateway 1 and everything
from
> example.net goes to gateway 2?
> 

Have a look at:
http://www.postfix.org/postconf.5.html#transport_maps

And:
http://www.postfix.org/transport.5.html

RE: Outbound mail routing

[J.P. Trosclair]

On Tue, 10 Mar 2009 09:12:43 -0400, Zachary Fortna 
wrote:
> Is it possible to do this on the domain level as opposed to the user
level?
>  That way everything from example.com goes to gateway 1 and everything
from
> example.net goes to gateway 2?

I may have goofed, I'm not sure what I suggested is good for outbound mail.
Probably worth having a look anyway.

The flow of messages through Postfix (Ref: Sensible config?)

[Roderick A. Anderson]

I keep seeing and having questions on valid parameters and valid values 
for them.  The Postfix.org site and manual have great listings and this 
list has provided excellent info on them.


Still I stay a bit confused as I started with an older version (could 
have been in the 1.x series) and got much of my main.cf from 
"non-authoritative" sources. :-)  And as I upgraded I never changed 
main.cf much unless I found a problem.


So here I am now wanting to "optimize" the installations I support but 
feel I can't do it right.  Why?  Because I don't know how a message 
flows through the settings in Postfix.


To try and bring this to the subject line; is there a "flow chart" or a 
way to create one of how a message would/should/could be processed?


Plus I have questions like: "Does the order of the parameters in main.cf 
make a difference?  Can I specify *_client_* after *_recipient_*, which 
parameter values are standalone parameters now, etc.


That make any sense ... at all?  Hopefully.


\\||/
Rod
--

Re: about relay server

[tom lee]

On Tue, Mar 10, 2009 at 12:01 AM, ram  wrote:
>
> On Mon, 2009-03-09 at 23:40 -0700, tom lee wrote:
>> hello,
>>
>> I checked the doc about the mail relay in postfix and still not
>> clear about two issues.
>>
>> I have mail sending from machine A to machine B,  machine B is a relay
>> server forwarding the email to machine C (target machine).
>>
>> I want to make sure there is no emails bouncing back from either
>> machine B or machine C to machine A.
>> can it be done?
>>
>> If machine C is down,  relay machine B will spool all emails till
>> machine C is up.
>> what configuration adjustment should I make for relay machine B?
>> is there a way to adjust the mail holding days in the relay machine B?
>
> Do you want this limit for all mails , or only for mails to machine B ?
>
> http://www.postfix.org/postconf.5.html
>
> Look for
> bounce_queue_lifetime
> maximal_queue_lifetime

Ram,
Thanks so much for your help.
All mails sending from machine A via relaying machine B will arrive in
machine C.
I think I need to set up something in machine B so that there will be no mails
bounce back to machine A.
>From your suggestion, I can see one way to do it is to set
maximal_queue_lifetime and bounce_queue_lifetime to 30 days and run
a script to delete all mails that is in the queue more than 15 day every day.
Not sure if there is a better way to do it?

Tom

Re: Outbound mail routing

[Noel Jones]

Zachary Fortna wrote:

Is it possible to do this on the domain level as opposed to the user level?  
That way everything from example.com goes to gateway 1 and everything from 
example.net goes to gateway 2?



Yes, please see
http://www.postfix.org/postconf.5.html#sender_dependent_relayhost_maps
for the table search order.

  -- Noel Jones

Re: The flow of messages through Postfix (Ref: Sensible config?)

[Wietse Venema]

Roderick A. Anderson:
> I keep seeing and having questions on valid parameters and valid values 
> for them.  The Postfix.org site and manual have great listings and this 
> list has provided excellent info on them.
> 
> Still I stay a bit confused as I started with an older version (could 
> have been in the 1.x series) and got much of my main.cf from 
> "non-authoritative" sources. :-)  And as I upgraded I never changed 
> main.cf much unless I found a problem.
> 
> So here I am now wanting to "optimize" the installations I support but 
> feel I can't do it right.  Why?  Because I don't know how a message 
> flows through the settings in Postfix.

It's documented.  http://www.postfix.org/OVERVIEW.html

> To try and bring this to the subject line; is there a "flow chart" or a 
> way to create one of how a message would/should/could be processed?
> 
> Plus I have questions like: "Does the order of the parameters in main.cf 
> make a difference?  Can I specify *_client_* after *_recipient_*, which 
> parameter values are standalone parameters now, etc.

It's documented.  http://www.postfix.org/postconf.5.html

Wietse

> That make any sense ... at all?  Hopefully.
> 
> 
> \\||/
> Rod
> -- 
> 
> 

Re: send rate problems

[Victor Duchovni]

On Tue, Mar 10, 2009 at 05:27:21PM +0800, Tony Liu wrote:

> I've controlled the mails delivery rate( F.E hotmail ,1mail /10s) in
> postfix,  when this mail is delivered the first time, this rate is okay, but
> there is another problem shows,  if some mails are back into queue for
> reject reason from one ISP(hotmail), it looks like the re-sending rate is
> not at this rate(I got if from analysis mail logs) , Is there is any way to
> resolve it?

Well, rate-limited transports have an implicit concurrency limit of 1, and
by default the site is declared dead if for any message connections to all
MX hosts are rejected before "MAIL FROM" ([45]xx banner or EHLO response).

So you need to show logs that distinguish between site failure and
simple message transaction deferral. With site failure, you may want
to tweak the setting of:




and reading the bug work-around in:



This bug will probably be fixed in 2.5.7 (it is also still present in
2.6 snapshots, but will be fixed by 2.6.0).

-- 
Viktor.

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

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


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

Multiple HOLD Queues?

[Terry Carmen]

Is it possible to implement multiple HOLD queues for different types of 
content that requires inspection (spam, file attachments, etc?)


Thanks!

Terry

smtpd_recipient_restrictions Check

[Linux Addict]

Dear Group, I am modifying my recipient restrictions to displayed below. I
referred many documents to compile the options. I want you experts to once
verify it for me.

smtpd_recipient_restrictions =
 reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unlisted_recipient,
reject_invalid_hostname,
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unauth_pipelining,
reject_unknown_reverse_client_hostname
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
permit

Thank you
~LA

Re: Multiple HOLD Queues?

[Victor Duchovni]

On Tue, Mar 10, 2009 at 11:52:07AM -0400, Terry Carmen wrote:

> Is it possible to implement multiple HOLD queues for different types of 
> content that requires inspection (spam, file attachments, etc?)

Yes, use FILTER rather than HOLD, and deliver the mail to separate
Postfix quarantine instances each of which puts all mail on hold.

You may not like this answer. A better solution is an SMTP server that
accepts messages and places them into directories of your choice (
preserving both the message and the envelope), and the messages will
be in plain-text, which is much easier to manage than the queue-file
format in the "hold" queue.

-- 
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: The flow of messages through Postfix (Ref: Sensible config?)

[Roderick A. Anderson]

Wietse Venema wrote:

Roderick A. Anderson:
I keep seeing and having questions on valid parameters and valid values 
for them.  The Postfix.org site and manual have great listings and this 
list has provided excellent info on them.


Still I stay a bit confused as I started with an older version (could 
have been in the 1.x series) and got much of my main.cf from 
"non-authoritative" sources. :-)  And as I upgraded I never changed 
main.cf much unless I found a problem.


So here I am now wanting to "optimize" the installations I support but 
feel I can't do it right.  Why?  Because I don't know how a message 
flows through the settings in Postfix.


It's documented.  http://www.postfix.org/OVERVIEW.html


Totally missed this.   I think I might have skipped it because so many 
OVERIEWs are ... lame.


To try and bring this to the subject line; is there a "flow chart" or a 
way to create one of how a message would/should/could be processed?


Plus I have questions like: "Does the order of the parameters in main.cf 
make a difference?  Can I specify *_client_* after *_recipient_*, which 
parameter values are standalone parameters now, etc.


It's documented.  http://www.postfix.org/postconf.5.html


Been there, done that but forgot about the non-ordered portion.

Now I come to what I was trying to ask.

In a main.cf I have:

smtpd_helo_restrictions = ...
smtpd_data_restrictions = ...
smtpd_recipient_restrictions = ...
header_checks = ...

I'm assuming smtpd_* means the the first three are handled by smtpd but 
in what order?  I'm leaning towards helo, recipient, then data; but 
there are others.  Where do they fall in the processing order?


And who handles header_checks and when?

Sorry to be a pain but I was hoping to not have to dive into the code. 
I sometimes need to justify/explain settings to others with less 
experience than me.  Plus if they are in main.cf grouped and ordered it 
makes the logic clearer.



\\||/
Rod
--

Re: The flow of messages through Postfix (Ref: Sensible config?)

[Victor Duchovni]

On Tue, Mar 10, 2009 at 09:05:28AM -0700, Roderick A. Anderson wrote:

> smtpd_helo_restrictions = ...
> smtpd_data_restrictions = ...
> smtpd_recipient_restrictions = ...
> header_checks = ...
>
> I'm assuming smtpd_* means the the first three are handled by smtpd but in 
> what order?

Well, the only opportunity to respond an SMTP command is in respnse to
*that* command, so originally these took place at the time of the
correspoding SMTP command.

connect:client restrictions
EHLO:   helo restrictions
MAIL FROM:  sender restrictions
RCPT TO:recipient restrictions
DATA:   data restrictions
.:  end of data restrictions (added recently)

Later is was recognized that there are good reasons to delay processing of
and error responses in "connect", "EHLO" and "MAIL" until "RCPT", hence:

http://www.postfix.org/postconf.5.html#smtpd_delay_reject

this does not change the order, just the timing, but the earlier restrictions
are now evaluated once for each recipient, rather than once per message, and
can make use of the (current) recipient address.

> And who handles header_checks and when?

http://www.postfix.org/header_checks.5.html

> Sorry to be a pain but I was hoping to not have to dive into the code.

You could try the documentation instead.

http://www.postfix.org/documentation.html
http://www.postfix.org/postfix-manuals.html

-- 
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: smtpd_recipient_restrictions Check

[Matt Hayes]

Linux Addict wrote:
> Dear Group, I am modifying my recipient restrictions to displayed below.
> I referred many documents to compile the options. I want you experts to
> once verify it for me.
> 
> smtpd_recipient_restrictions = 
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> permit_mynetworks,  
> permit_sasl_authenticated,
> reject_unauth_destination,
> reject_unlisted_recipient,
> reject_invalid_hostname, 
> reject_invalid_helo_hostname
> reject_non_fqdn_helo_hostname
> reject_unauth_pipelining,
> reject_unknown_reverse_client_hostname
> reject_rbl_client zen.spamhaus.org ,
> reject_rbl_client bl.spamcop.net , 
> permit
> 
> Thank you
> ~LA


I would suggest moving permit_sasl_authenticated to the top of that
list.  Either that or using the submission service for SASL
authenticated users

-Matt

Re: smtpd_recipient_restrictions Check

[Victor Duchovni]

On Tue, Mar 10, 2009 at 11:59:22AM -0400, Linux Addict wrote:

> Dear Group, I am modifying my recipient restrictions to displayed below. I
> referred many documents to compile the options. I want you experts to once
> verify it for me.
> 
> smtpd_recipient_restrictions =
>  reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,

This mostly for hosts that handle "submission" from MUAs. Often best to
move submission to port 587 and apply only there. You'll reject bogus
domains from untrusted senders anyway.

> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination,
> reject_unlisted_recipient,
> reject_invalid_hostname,
> reject_invalid_helo_hostname

The two above are the same.

> reject_non_fqdn_helo_hostname

Why so much emphasis on HELO names, they are not a very effective
spam sign.

> reject_unauth_pipelining,

Currently best in smtpd_data_restrictions, where it is effective after
EHLO, as during RCPT TO, additional RCPT TO commands or the "DATA"
command can be legitimately "PIPELINED" in the same packet.

> reject_unknown_reverse_client_hostname
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client bl.spamcop.net,
> permit

Fairly sensible overall.

-- 
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: smtpd_recipient_restrictions Check

[Victor Duchovni]

On Tue, Mar 10, 2009 at 12:17:29PM -0400, Matt Hayes wrote:

> Linux Addict wrote:
> > Dear Group, I am modifying my recipient restrictions to displayed below.
> > I referred many documents to compile the options. I want you experts to
> > once verify it for me.
> > 
> > smtpd_recipient_restrictions = 
> > reject_non_fqdn_sender,
> > reject_non_fqdn_recipient,
> > reject_unknown_sender_domain,
> > reject_unknown_recipient_domain,
> > permit_mynetworks,  
> > permit_sasl_authenticated,
> > reject_unauth_destination,
> > reject_unlisted_recipient,
> > reject_invalid_hostname, 
> > reject_invalid_helo_hostname
> > reject_non_fqdn_helo_hostname
> > reject_unauth_pipelining,
> > reject_unknown_reverse_client_hostname
> > reject_rbl_client zen.spamhaus.org ,
> > reject_rbl_client bl.spamcop.net , 
> > permit
> > 
> > Thank you
> > ~LA
> 
> 
> I would suggest moving permit_sasl_authenticated to the top of that
> list.  Either that or using the submission service for SASL
> authenticated users

THere is not much point in acceping invalid sender and recipient addresses
from MUAs. The restriction is fine where it is.

-- 
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: The flow of messages through Postfix (Ref: Sensible config?)

[Wietse Venema]

Roderick A. Anderson:
> In a main.cf I have:
> 
> smtpd_helo_restrictions = ...
> smtpd_data_restrictions = ...
> smtpd_recipient_restrictions = ...
> header_checks = ...
> 
> I'm assuming smtpd_* means the the first three are handled by smtpd but 
> in what order?  I'm leaning towards helo, recipient, then data; but 
> there are others.  Where do they fall in the processing order?
> 
> And who handles header_checks and when?

It's documented. http://www.postfix.org/SMTPD_ACCESS_README.html

Wietse

Re: Multiple HOLD Queues?

[Wietse Venema]

Terry Carmen:
> Is it possible to implement multiple HOLD queues for different types of 
> content that requires inspection (spam, file attachments, etc?)

Yes. This functionality can be added to Postfix, by plugging an
external information management system into the many standard
message interfaces that Postfix already provides.

Wietse

Re: smtpd_recipient_restrictions Check

[Linux Addict]

On Tue, Mar 10, 2009 at 12:24 PM, Victor Duchovni <
victor.ducho...@morganstanley.com> wrote:

> On Tue, Mar 10, 2009 at 12:17:29PM -0400, Matt Hayes wrote:
>
> > Linux Addict wrote:
> > > Dear Group, I am modifying my recipient restrictions to displayed
> below.
> > > I referred many documents to compile the options. I want you experts to
> > > once verify it for me.
> > >
> > > smtpd_recipient_restrictions =
> > > reject_non_fqdn_sender,
> > > reject_non_fqdn_recipient,
> > > reject_unknown_sender_domain,
> > > reject_unknown_recipient_domain,
> > > permit_mynetworks,
> > > permit_sasl_authenticated,
> > > reject_unauth_destination,
> > > reject_unlisted_recipient,
> > > reject_invalid_hostname,
> > > reject_invalid_helo_hostname
> > > reject_non_fqdn_helo_hostname
> > > reject_unauth_pipelining,
> > > reject_unknown_reverse_client_hostname
> > > reject_rbl_client zen.spamhaus.org ,
> > > reject_rbl_client bl.spamcop.net ,
> > > permit
> > >
> > > Thank you
> > > ~LA
> >
> >
> > I would suggest moving permit_sasl_authenticated to the top of that
> > list.  Either that or using the submission service for SASL
> > authenticated users
>
> THere is not much point in acceping invalid sender and recipient addresses
> from MUAs. The restriction is fine where it is.
>
> --
>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.
>

The reason I moved below is there seems to be some rogue hosts/users(Mostly
things like "Refer a Link")  misusing the priority and injecting spam.

Re: The flow of messages through Postfix (Ref: Sensible config?)

[Roderick A. Anderson]

Victor Duchovni wrote:

On Tue, Mar 10, 2009 at 09:05:28AM -0700, Roderick A. Anderson wrote:






Well, the only opportunity to respond an SMTP command is in respnse to
*that* command, so originally these took place at the time of the
correspoding SMTP command.

connect:client restrictions
EHLO:   helo restrictions
MAIL FROM:  sender restrictions
RCPT TO:recipient restrictions
DATA:   data restrictions
.:  end of data restrictions (added recently)

Later is was recognized that there are good reasons to delay processing of
and error responses in "connect", "EHLO" and "MAIL" until "RCPT", hence:

http://www.postfix.org/postconf.5.html#smtpd_delay_reject

this does not change the order, just the timing, but the earlier restrictions
are now evaluated once for each recipient, rather than once per message, and
can make use of the (current) recipient address.


And who handles header_checks and when?


http://www.postfix.org/header_checks.5.html


I've read this before but missed/forgot this portion, though it is in 
the first paragraph of the Description.



Sorry to be a pain but I was hoping to not have to dive into the code.


You could try the documentation instead.

http://www.postfix.org/documentation.html
http://www.postfix.org/postfix-manuals.html


Oh I have but find myself getting lost as I follow links that lead to 
other links that lead to more links.  Pretty soon I forgot what I 
started out looking for.  :-(  Old age?  :-)


You know I think I better go back to lurking and reading.


\\||/
Rod
--

Fw: Re: v2.5.5 showq and postcat date/time stamp discrepancy

[Glen B]

--- On Tue, 3/10/09, Glen B  wrote:

> From: Glen B 
> Subject: Re: v2.5.5 showq and postcat date/time stamp discrepancy
> To: "Wietse Venema" 
> Date: Tuesday, March 10, 2009, 1:16 PM
> >
> >--- On Tue, 3/10/09, Wietse Venema
>  wrote:
> >
> >From: Wietse Venema 
> >Subject: Re: v2.5.5 showq and postcat date/time stamp
> discrepancy
> >To: "Glen B" 
> >Cc: postfix-users@postfix.org
> >Date: Tuesday, March 10, 2009, 10:36 AM
> >
> >Glen B:
> >> ?
> >> ? I'm running the commands from a SSH shell
> logged in as root. What do
> >you mean by setuid wrapper?
> >> ?
> >
> >Type the following commands, and report the output:
> >
> >$ date
> >$ mailq | grep DBBAD4A340AD
> >$ date
> >
> >This may very well be a Debian bug where they run
> daemons chrooted
> >but don't provide the correct timezone file inside
> the jail.
> 
> 
> Wietse,
> 
> box:/# date
> Tue Mar 10 12:38:51 EDT 2009
> box:/# mailq | grep DBBAD4A340AD
> postqueue: warning: Mail system is down -- accessing queue
> directly
> DBBAD4A340AD  827 Mon Mar  9 10:29:27  root
> box:/# date
> Tue Mar 10 12:39:03 EDT 2009
> box:/#
> 
> I think you are correct, but I've not had any luck
> getting postcat to report based on zoneinfo in the chroot or
> outside of a chroot. Mailq seems to work correctly
> regardless. 
> 
> I've copied zoneinfo files respective to the root path,
> /etc/localtime, and /etc/timezone into the chroot. I also
> tried disabling chroot for showq in master.cf,
> restarting/stopping postfix, and then submitting a new
> message offline. The same date/time issue still appears to
> happen.
> 
> I've seen that the code should be reporting the same
> date/time. Is there another service that I should remove the
> chroot from for testing this?
> 
>  The following services are currently not chrooted:
> 
>  smtpd, qmgr, proxymap, showq, local, virtual, maildrop,
> uucp
> 
> 
> GlenB

 Here's a copy of my response that didn't originally go to the list. 

Re: The flow of messages through Postfix (Ref: Sensible config?)

[Victor Duchovni]

On Tue, Mar 10, 2009 at 10:20:14AM -0700, Roderick A. Anderson wrote:

>> You could try the documentation instead.
>> http://www.postfix.org/documentation.html
>> http://www.postfix.org/postfix-manuals.html
>
> Oh I have but find myself getting lost as I follow links that lead to other 
> links that lead to more links.  Pretty soon I forgot what I started out 
> looking for.  :-(  Old age?  :-)

There are two decent books and I find that tabbed browsing makes it easy to
not lose context. Certainly the links to postconf.5.html don't usually
require too many levels of nesting, so first read the tutorial, open
background tabs for all the parameter links, then review the parameter
docs.

-- 
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: Fw: Re: v2.5.5 showq and postcat date/time stamp discrepancy

[Victor Duchovni]

On Tue, Mar 10, 2009 at 10:20:15AM -0700, Glen B wrote:

> > box:/# mailq | grep DBBAD4A340AD
> > postqueue: warning: Mail system is down -- accessing queue
> > directly
> > DBBAD4A340AD? 827 Mon Mar? 9 10:29:27? root
> > box:/# date
> > Tue Mar 10 12:39:03 EDT 2009
> > box:/#

Perhaps the "postfix" user is unable to read the localtime file, check
permissions all the way down from /. Your tests are running as root,
can you "su postfix -s /bin/sh -c postcat ..." and see how that goes.

-- 
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: send rate problems

[LuKreme]

On 10-Mar-2009, at 03:27, Tony Liu wrote:

Hi ,


Hi.  Please don't hijack another thread when posting a new message.   
That is to say, when you reply to a message on the list and change the  
subject that is NOT the same as creating a new message.


--
I do believe Marsellus Wallace, my husband, your boss, told you to
take *me* out and do *whatever I wanted*. Now I wanna dance, I
wanna win. I want that trophy, so dance good.

Re: smtpd_recipient_restrictions Check

[Linux Addict]

On Tue, Mar 10, 2009 at 12:22 PM, Victor Duchovni <
victor.ducho...@morganstanley.com> wrote:

> On Tue, Mar 10, 2009 at 11:59:22AM -0400, Linux Addict wrote:
>
> > Dear Group, I am modifying my recipient restrictions to displayed below.
> I
> > referred many documents to compile the options. I want you experts to
> once
> > verify it for me.
> >
> > smtpd_recipient_restrictions =
> >  reject_non_fqdn_sender,
> > reject_non_fqdn_recipient,
> > reject_unknown_sender_domain,
> > reject_unknown_recipient_domain,
>
> This mostly for hosts that handle "submission" from MUAs. Often best to
> move submission to port 587 and apply only there. You'll reject bogus
> domains from untrusted senders anyway.
>
> > permit_mynetworks,
> > permit_sasl_authenticated,
> > reject_unauth_destination,
> > reject_unlisted_recipient,
> > reject_invalid_hostname,
> > reject_invalid_helo_hostname
>
> The two above are the same.
>
> > reject_non_fqdn_helo_hostname
>
> Why so much emphasis on HELO names, they are not a very effective
> spam sign.
>
> > reject_unauth_pipelining,
>
> Currently best in smtpd_data_restrictions, where it is effective after
> EHLO, as during RCPT TO, additional RCPT TO commands or the "DATA"
> command can be legitimately "PIPELINED" in the same packet.
>
> > reject_unknown_reverse_client_hostname
> > reject_rbl_client zen.spamhaus.org,
> > reject_rbl_client bl.spamcop.net,
> > permit
>
> Fairly sensible overall.


Is it better to place rbl rejections under smtpd_client_restrictions?



>
>
> --
>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: v2.5.5 showq and postcat date/time stamp discrepancy

[Wietse Venema]

Wietse:
>Type the following commands, and report the output:
>
>$ date
>$ mailq | grep DBBAD4A340AD
>$ date
>
>This may very well be a Debian bug where they run daemons chrooted
>but don't provide the correct timezone file inside the jail.

Glen B:
> box:/# date
> Tue Mar 10 12:38:51 EDT 2009
> box:/# mailq | grep DBBAD4A340AD
> postqueue: warning: Mail system is down -- accessing queue directly
> DBBAD4A340AD? 827 Mon Mar? 9 10:29:27? root

This measurement does not use any Postfix daemon processes, so it
is no good.

What I first need to know is which of the commands reports the
wrong time:  mailq (while Postfix is actually running) or postcat.

I also need to see the evidence that leads you to this conclusion,
because unfortunately too many people make mistakes.

Once that is determined, I may ask you to compile (NOT INSTALL)
Postfix from source code that has not been modified by the friendly
helpful Debian maintainers.

Follow-ups to postfix-users.

Wietse

Re: smtpd_recipient_restrictions Check

[Victor Duchovni]

On Tue, Mar 10, 2009 at 01:37:07PM -0400, Linux Addict wrote:

> > > reject_unknown_reverse_client_hostname
> > > reject_rbl_client zen.spamhaus.org,
> > > reject_rbl_client bl.spamcop.net,
> > > permit
> >
> > Fairly sensible overall.
> 
> Is it better to place rbl rejections under smtpd_client_restrictions?

No, they are just fine at the bottom of the recipient restrictions list.
These are high latency lookups, and you want to do them last, giving
other checks the opportunity to reject the mail cheaply.

-- 
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: virtual_alias_maps

[LuKreme]

On 10-Mar-2009, at 06:44, Sahil Tandon wrote:

On Mar 10, 2009, at 4:29 AM, LuKreme  wrote:

On 9-Mar-2009, at 15:58, mouss wrote:

you must understand the difference between
  virtual_mailbox_domains
and
  virtual_alias_domains


I understand the difference, I have virtual_mailbox_domains  
assigned and I don't have virtual_alias_domains :)


Ok let's try this again. As a few people on this list have politely  
indicated, you *DO* have virtual_alias_domains set unless you  
explicitly unset it in main.cf.  See the default value for further  
enlightenment.


Yes, you obviously missed the smilie at the end.

But to be pedantic, I do *not* have virtual_alias_domains set at all,  
and it does not show up in postconf -n because I've never changed its  
default value ($virtual_alias_maps). From ADDRESS_CLASS_README


For backwards compatibility with Postfix version 1.1, the new
virtual_alias_maps parameter defaults to $virtual_maps, and the new
virtual_alias_domains parameter defaults to $virtual_alias_maps.

% postconf -n | grep "^virtual"
virtual_alias_maps = hash:$config_directory/virtual,pcre: 
$config_directory/virtual.pcre,mysql:$config_directory/ 
mysql_virtual_alias_maps.cf

virtual_gid_maps = static:89
virtual_mailbox_base = /usr/local/virtual
virtual_mailbox_domains = mysql:$config_directory/ 
mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:$config_directory/ 
mysql_virtual_mailbox_maps.cf

virtual_minimum_uid = 89
virtual_transport = procmail
virtual_uid_maps = static:89

If you're saying that I don't understand why I would have a different  
virtual_alias_domains value to the existing virtual_alias_maps, then  
you're right. virtual_alias_domains appears to be an alternate way of  
listing the domains that I would list in the $config_directory/virtual  
file. WHY you would do it this way I have no idea. I suppose if you  
had virtual domains that were not in mysql... even then, not sure what  
the advantage would be.


Could I simply change my virtual_alias_maps definition above to  
virtual_alias_domains? I don't think so. At least how this is setup,  
the mysql_virtual_alias.maps.cf returns the alias (forwarding alias)  
of accounts that have an alias set in postfix admin, which is (at  
least technically) what hash:($config_directory/virtual returns as well.


The actual problem was one of simple memory failure. I forgot that ALL  
of southgaylord.com was setup at a virtual domain and that two  
specific email addresses then pointed back to local users via aliases  
defined in postfixadmin.  When I tried to add back southgaylord.com  
into $config_directory/virtual then everything failed because I was  
showing the same domain in two disparate locations. Once I figured out  
what I'd done previously, I was then able to restore everything to the  
way it was.


This never had anything at all to do with virtual_alias_domains versus  
virtual_alias_maps, though it *was* a logical place to look.



--
I AM ZOMBOR! (kelly) ZOMBOR!

Re: virtual_alias_maps

[Victor Duchovni]

On Tue, Mar 10, 2009 at 12:33:52PM -0600, LuKreme wrote:

> Could I simply change my virtual_alias_maps definition above to 
> virtual_alias_domains? I don't think so. At least how this is setup, the 
> mysql_virtual_alias.maps.cf returns the alias (forwarding alias) of 
> accounts that have an alias set in postfix admin, which is (at least 
> technically) what hash:($config_directory/virtual returns as well.

The recommended approach for those ready to move beyond 1.1 compatible
settings is:

virtual_alias_domains = ... explicit list of domains or tables ...
virtual_alias_maps = ... tables ...

if the number of virtual alias domains is small (1-10) and stable,
avoid tables entirely just list them in main.cf. Yes you can rely
on the backwards compatible interface, but it is more confusing and
in many cases less efficient.

-- 
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: The flow of messages through Postfix (Ref: Sensible config?)

[Charles Marcus]

On 3/10/2009, Victor Duchovni (victor.ducho...@morganstanley.com) wrote:
> There are two decent books and I find that tabbed browsing makes it easy to
> not lose context. Certainly the links to postconf.5.html don't usually
> require too many levels of nesting, so first read the tutorial, open
> background tabs for all the parameter links, then review the parameter
> docs.

And if you're a Firefox user, the Tree Style Tab addon makes a huge
difference for this kind of browsing...

Mac OSX error logs

[Rupert Reid]

Hello All,

I am running postfix (apple version) with MAC OSX10.4.11 client.  I  
found the following entries in the "Console/501/console.log".  I am  
concerned but do not know what it means.  The var/log/mail.log does  
not show any errors and seem to be sending/receiving mail without  
problem.  Below is the output of postconf -n.  I would be grateful if  
anyone could:


a. Tell me what the console.log means
b. Should I be concerened and what should I do about it
c. Are there any vulnerabilities in my configuration and what steps I  
can take to correct them


Thanks in advance
Rups

16:43:57.691 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.693 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.884 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.924 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.926 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.935 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.938 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.949 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:57.955 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:43:58.073 Mail[9868] Unhandled response to command STATUS: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:44:05.839 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.380 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.381 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.425 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.430 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.755 Mail[9868] Unhandled response to command STATUS: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.757 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:57.854 Mail[9868] Unhandled response to command STATUS: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
16:54:58.873 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:12:15.757 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:34:50.408 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:34:50.509 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:34:50.540 Mail[9868] Unhandled response to command STATUS: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:34:50.616 Mail[9868] Unhandled response to command SELECT: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:34:50.655 Mail[9868] Unhandled response to command CLOSE: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection
17:34:50.658 Mail[9868] Unhandled response to command STATUS: * NO   
Mailbox vulnerable - directory /var/mail must have 1777 protection



postconf -n
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost,  
$mydomain, mail.$mydomain, www.$mydomain, ftp.$mydomain, domain2.tld

mydomain_fallback = mail.domain1.tld
myhostname = mail.domain1.tld
mynetworks_style = host
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases
queue_directory = /private/var/spool/postfix
readme_directory = /usr/share/doc/postfix
sample_directory = /usr/share/doc/postfix/examples
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_tls_key_file =
unknown_local_recipient_reject_code = 550
virtual_alias_maps = 

Re: Mac OSX error logs

[Victor Duchovni]

On Tue, Mar 10, 2009 at 07:37:27PM +, Rupert Reid wrote:

> I am running postfix (apple version) with MAC OSX10.4.11 client.  I found 
> the following entries in the "Console/501/console.log".  I am concerned but 
> do not know what it means.  The var/log/mail.log does not show any errors 
> and seem to be sending/receiving mail without problem.  Below is the output 
> of postconf -n.  I would be grateful if anyone could:
>
> a. Tell me what the console.log means

Nothing to do with Postfix, this is Mail.app talking to the IMAP server.
Your IMAP server is not happy with the permissions of the mail store.

> b. Should I be concerened and what should I do about it
>
> c. Are there any vulnerabilities in my configuration and what steps I can 
> take to correct them

Ask on a different list.

> 16:43:57.691 Mail[9868] Unhandled response to command SELECT: * NO  Mailbox 
> vulnerable - directory /var/mail must have 1777 protection

-- 
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: smtpd_recipient_restrictions Check

[LuKreme]

On 10-Mar-2009, at 09:59, Linux Addict wrote:

smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,


I have reject_invalid_hostname here as well (before permit_mynetworks)


permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_unlisted_recipient,


I have reject_unlisted_sender instead, followed by:

 check_client_access cidr:/var/db/dnswl/postfix-dnswl-permit
 check_helo_access pcre:$config_directory/helo_checks.pcre,
 check_sender_access pcre:$config_directory/sender_access.pcre,
 check_client_access pcre:$config_directory/check_client_fqdn.pcre,
 check_recipient_access pcre:$config_directory/recipient_checks.pcre,
 check_client_access hash:$config_directory/access,


reject_invalid_hostname,
reject_invalid_helo_hostname


These are redundant


reject_non_fqdn_helo_hostname
reject_unauth_pipelining,


Why?


reject_unknown_reverse_client_hostname


You might want reject_unknown_client_hostname instead. Either way,  
this is probably not the best thing if you are accepting mail for  
others. You WILL lose email that they will consider to be legitimate.   
While it is nice to be able to say "Your network is misconfigured" the  
truth is, if you're handling mail for anyone else you need to be as  
accepting as is reasonably possible.



reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,


I would be very very careful about using spamcop if you are accepting  
mail for others.



permit



In general you want to structure the order from 'cheapest' to most  
'expensive'. Everything before permit_myneworks is stuff that should  
be rejected no matter who is sending it, which is why I have  
invalid_hostname there. Then any other checks that are cheap, followed  
by any checks that requires has/mysql/cidr/pcre lookups because these  
are slightly more expensive. Last of all is the RBLs (well, RBL in my  
case, I only use zen).


--
Growing up leads to growing old, and then to dying/And dying to me
don't sound like all that much fun.

Re: v2.5.5 showq and postcat date/time stamp discrepancy

[Ben Winslow]

On Tue, 10 Mar 2009 10:36:25 -0400 (EDT)
wie...@porcupine.org (Wietse Venema) wrote:

> This may very well be a Debian bug where they run daemons chrooted
> but don't provide the correct timezone file inside the jail.

Just for reference, the postfix 2.5.5-1.1 package in Debian -- if any
services in master.cf are chrooted -- copies the following files into
the chroot:

/etc/ssl/certs/ca-certificates.crt (if smtpd?_use_tls = yes)
/etc/passwd (if local_recipient_maps contains (proxy:)?unix:passwd.byname)
/etc/localtime
/etc/services
/etc/resolv.conf
/etc/hosts
/etc/nsswitch.conf
/etc/nss_mdns.config
/usr/lib/zoneinfo/localtime (plus a symlink to this file in /etc)
/lib/libnss_*so*

I've dropped the full init script into http://www.themuffin.net/j/tmp/postfix 
if you care about the details.

FWIW, my test system uses the system-wide timezone (US/Central) in the output 
from mailq and the timezone from $TZ (US/Eastern) for the output from postcat.  
This is, IMO, the correct behavior.

>   Wietse

-- 
Ben Winslow 

Re: smtpd_recipient_restrictions Check

[Victor Duchovni]

On Tue, Mar 10, 2009 at 02:28:00PM -0600, LuKreme wrote:

> On 10-Mar-2009, at 09:59, Linux Addict wrote:
>> smtpd_recipient_restrictions =
>> reject_non_fqdn_sender,
>> reject_non_fqdn_recipient,
>> reject_unknown_sender_domain,
>> reject_unknown_recipient_domain,
>
> I have reject_invalid_hostname here as well (before permit_mynetworks)

This is unwise, SASL authenticated MUAs can easily have bogus HELO names.

>> permit_mynetworks,
>> permit_sasl_authenticated,
>> reject_unauth_destination,
>> reject_unlisted_recipient,
>
> I have reject_unlisted_sender instead, followed by:

It is reasonable to reject unknown recipients early, this is a cheap check,
and your spam stats are much more accurate when you only count mail to
real recipients.

>
>> reject_unknown_reverse_client_hostname
>
> You might want reject_unknown_client_hostname instead.

No, too aggressive.

>> reject_rbl_client zen.spamhaus.org,
>> reject_rbl_client bl.spamcop.net,
>
> I would be very very careful about using spamcop if you are accepting mail 
> for others.

>From all reports, it is pretty safe these days.

-- 
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: virtual_alias_maps

[LuKreme]

On 10-Mar-2009, at 12:41, Victor Duchovni wrote:

On Tue, Mar 10, 2009 at 12:33:52PM -0600, LuKreme wrote:


Could I simply change my virtual_alias_maps definition above to
virtual_alias_domains? I don't think so. At least how this is  
setup, the

mysql_virtual_alias.maps.cf returns the alias (forwarding alias) of
accounts that have an alias set in postfix admin, which is (at least
technically) what hash:($config_directory/virtual returns as well.


The recommended approach for those ready to move beyond 1.1 compatible
settings is:

   virtual_alias_domains = ... explicit list of domains or tables ...
   virtual_alias_maps = ... tables ...

if the number of virtual alias domains is small (1-10) and stable,
avoid tables entirely just list them in main.cf. Yes you can rely
on the backwards compatible interface, but it is more confusing and
in many cases less efficient.


Well, "more confusing" is relative. The old way is less confusing *to  
me* because I'm familiar with it.


I could certainly

# grep DOMAIN virtual | awk '{print $1}'

and put that list into main.cf in a virtual_alias_domains declaration.  
In fact, there's probably no reason NOT to do this, as most of my  
domains have been moved over to mysql virtual mailboxes -- other than  
not being sure what other impact this might have (that is, what other  
settings I might need to change).


I'm willing to be convinced though, I don't foresee any reason why the  
number of virtual_alias_domains would ever increase.


--
Hey, how come Andrew gets to get up? If he gets up, we'll all get
up! It'll be anarchy!

Re: Mac OSX error logs

[LuKreme]

On 10-Mar-2009, at 13:37, Rupert Reid wrote:


Hello All,

I am running postfix (apple version) with MAC OSX10.4.11 client.  I  
found the following entries in the "Console/501/console.log".  I am  
concerned but do not know what it means.  The var/log/mail.log does  
not show any errors and seem to be sending/receiving mail without  
problem.  Below is the output of postconf -n.  I would be grateful  
if anyone could:


a. Tell me what the console.log means


the permissions on /var/mail/ are wrong


b. Should I be concerened and what should I do about it


sudo chmod 1777 /var/mail/

it should look like this:

$ ls -lsd /var/mail/
2 drwxrwxrwt  2 root  mail  1536 Mar 10 14:58 /var/mail/

(note the 't')

Also, you might want to man chmod and man 2 chmod and look for "sticky"

If mode ISVTX (the `sticky bit') is set on a directory, an
unprivileged user may not delete or rename files of other
users in that directory. The sticky bit may be set by any
user on a directory which the user owns or has appropriate
permissions.  For more details of the properties of the
sticky bit, see sticky(8).

--
All our loves are first loves

Re: virtual_alias_maps

[Victor Duchovni]

On Tue, Mar 10, 2009 at 02:46:29PM -0600, LuKreme wrote:

>> The recommended approach for those ready to move beyond 1.1 compatible
>> settings is:
>>
>>virtual_alias_domains = ... explicit list of domains or tables ...
>>virtual_alias_maps = ... tables ...
>>
>> if the number of virtual alias domains is small (1-10) and stable,
>> avoid tables entirely just list them in main.cf. Yes you can rely
>> on the backwards compatible interface, but it is more confusing and
>> in many cases less efficient.
>
> Well, "more confusing" is relative. The old way is less confusing *to me* 
> because I'm familiar with it.

Explicit settings are always more clear than implicit settings. Even if
you just set:

virtual_alias_domains = $virtual_alias_maps

and repeat the default, but see below...

> I could certainly
>
> # grep DOMAIN virtual | awk '{print $1}'
>
> and put that list into main.cf in a virtual_alias_domains declaration. In 
> fact, there's probably no reason NOT to do this

Actually you SHOULD do this unless you find a reason to NOT do it.

> as most of my domains have 
> been moved over to mysql virtual mailboxes -- other than not being sure 
> what other impact this might have (that is, what other settings I might 
> need to change).

None, but the trivial-rewrite service will be saddled with one less
MySQL lookup to determine the address class of a domain. Ideally you
also move virtual_mailbox_domains to its own parameter also, and
don't rely on implicit lookups of that in virtual_mailbox_maps, and
avoid tables when possible.

-- 
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: v2.5.5 showq and postcat date/time stamp discrepancy

[Wietse Venema]

Ben Winslow:
> FWIW, my test system uses the system-wide timezone (US/Central)
> in the output from mailq and the timezone from $TZ (US/Eastern)
> for the output from postcat.  This is, IMO, the correct behavior.

I hadn't thought of that (system versus user time zone). It could
explain the original problem report. The difference is really an
accident of implementation.

When the mail system is running, the mailq command connects to a
showq daemon which reports times according to the system time zone.

When the mail system is stopped, the super-user can still execute
the mailq command. In this case, mailq executes the showq program
directly, and will report times according to the "user" time zone.

Wietse

Re: virtual_alias_maps

[LuKreme]

On 10-Mar-2009, at 15:22, Victor Duchovni wrote:

None, but the trivial-rewrite service will be saddled with one less
MySQL lookup to determine the address class of a domain. Ideally you
also move virtual_mailbox_domains to its own parameter also, and
don't rely on implicit lookups of that in virtual_mailbox_maps, and
avoid tables when possible.



OK OK, so I go from this:

virtual_alias_maps =
hash:$config_directory/virtual,
pcre:$config_directory/virtual.pcre,
mysql:$config_directory/mysql_virtual_alias_maps.cf

to this:

virtual_alias_maps =
pcre:$config_directory/virtual.pcre,
mysql:$config_directory/mysql_virtual_alias_maps.cf
virtual_alias_domains=[list of domains extracted from virtual]

(That is to say, i add the domains to the v_a_d declaration and remove  
the hash lookup for the maps from the v_a_m declaration)



--
I can't die, I haven't seen The Jolson Story  - Jetboy

Re: virtual_alias_maps

[Victor Duchovni]

On Tue, Mar 10, 2009 at 03:57:04PM -0600, LuKreme wrote:

> OK OK, so I go from this:
>
> virtual_alias_maps =
> hash:$config_directory/virtual,
> pcre:$config_directory/virtual.pcre,
> mysql:$config_directory/mysql_virtual_alias_maps.cf
>
> to this:
>
> virtual_alias_maps =
> pcre:$config_directory/virtual.pcre,
> mysql:$config_directory/mysql_virtual_alias_maps.cf
>
> virtual_alias_domains=[list of domains extracted from virtual]

Yes, provided the latter contains only "domain anything" entries and no
"address rewrite-address" entries.

> (That is to say, i add the domains to the v_a_d declaration and remove the 
> hash lookup for the maps from the v_a_m declaration)

Yes, provided of course the hash table only contained domains. Or could
just set:

virtual_alias_domains = hash:$config_directory/virtual

virtual_alias_maps =
pcre:$config_directory/virtual.pcre,
mysql:$config_directory/mysql_virtual_alias_maps.cf

hash tables are fine in the context of virtual_alias_domains, while
MySQL/LDAP/... are not recommended.

-- 
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: virtual_alias_maps

[LuKreme]

On 10-Mar-2009, at 16:06, Victor Duchovni wrote:

On Tue, Mar 10, 2009 at 03:57:04PM -0600, LuKreme wrote:

virtual_alias_domains=[list of domains extracted from virtual]


Yes, provided the latter contains only "domain anything" entries and  
no

"address rewrite-address" entries.


virtual_alias_domains=virtual.tld, mydomain,tld, johndoe.tld

...enabling soft-bounce... :)

(That is to say, i add the domains to the v_a_d declaration and  
remove the

hash lookup for the maps from the v_a_m declaration)


Yes, provided of course the hash table only contained domains. Or  
could

just set:

   virtual_alias_domains = hash:$config_directory/virtual


Ah... er... OK, now you lost me again.  What in $DEITY's name would be  
the point of that? Wouldn't I still have to then have


domain.tld anything

in $config_directory/virtual?


--
Maybe I should have seen it as some kind of sign,
except I don't believe in them no more; no no, but
I believe these things I can't forget, tho I don't
see you anymore.

Re: virtual_alias_maps

[Victor Duchovni]

On Tue, Mar 10, 2009 at 04:22:00PM -0600, LuKreme wrote:

>> Yes, provided of course the hash table only contained domains. Or could
>> just set:
>>
>>virtual_alias_domains = hash:$config_directory/virtual
>
> Ah... er... OK, now you lost me again.  What in $DEITY's name would be the 
> point of that? Wouldn't I still have to then have
>
> domain.tld anything
>
> in $config_directory/virtual?

Yes, you would, but the point is that the mysql and pcre tables used to
rewrite recipients are no longer used when determining the address class
of domains in trivial-rewrite, and it is now clear where alias domains
are defined.

You can use hash tables if you want Postfix to automatically notice that
the table has changed without a reload. If the list is very stable, main.cf
is just fine, but both are equally sensible. The point to separate the
domains from the addresses, the format of the domains: inline vs. indexed
file is up to you.

-- 
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: virtual_alias_maps

[mouss]

LuKreme a écrit :
> On 9-Mar-2009, at 15:58, mouss wrote:
>> you must understand the difference between
>> virtual_mailbox_domains
>> and
>> virtual_alias_domains
> 
> I understand the difference, I have virtual_mailbox_domains assigned and
> I don't have virtual_alias_domains :)
> 

then set
virtual_alias_domains =
explicitely


> Actually, isn't virtual_mailbox_domains default value ($virtual_maps)
> built from the contents of $config_directory/virtual?
> 

default values are found by running 'postconf -d'.

$ postconf -d virtual_mailbox_domains
virtual_mailbox_domains = $virtual_mailbox_maps
$ postconf -d virtual_mailbox_maps
virtual_mailbox_maps =

Re: hold all relayed mail by default

[mouss]

Charles Marcus a écrit :
> On 3/9/2009 6:12 PM, mouss wrote:
>>> I only said it was an interesting idea, and wondered if it could be
>>> automated... I'm still not sure it *should* be done... :)
> 
>> it can be automated. the hard part is to define the criteria (when to
>> keep, when to "release") and how to recall (how does user tell the
>> system that he wants to recall a message,
> 
> Well, release after expiry time is easy - as for how the user recalls,
> one way would be to define a special email address (ie,
>  where example.com is your domain, and tell the user
> to simply go to their 'Sent' folder, click the 'Reply button for the
> message they want to recall, and change the destination address to
> . The magic, of course, would be the script that
> processes these requests...
> 

it's not that hard. the hard part is to make sure that how recalls only
recalls his own mail. This is easy via a web interface which requires
user authentication (aka webmail). if everything is done by mail, then
it's a bit harder unless you force authentication (sasl).

Re: about relay server

[mouss]

tom lee a écrit :
> On Tue, Mar 10, 2009 at 12:01 AM, ram  wrote:
>> On Mon, 2009-03-09 at 23:40 -0700, tom lee wrote:
>>> hello,
>>>
>>> I checked the doc about the mail relay in postfix and still not
>>> clear about two issues.
>>>
>>> I have mail sending from machine A to machine B,  machine B is a relay
>>> server forwarding the email to machine C (target machine).
>>>
>>> I want to make sure there is no emails bouncing back from either
>>> machine B or machine C to machine A.
>>> can it be done?
>>>
>>> If machine C is down,  relay machine B will spool all emails till
>>> machine C is up.
>>> what configuration adjustment should I make for relay machine B?
>>> is there a way to adjust the mail holding days in the relay machine B?
>> Do you want this limit for all mails , or only for mails to machine B ?
>>
>> http://www.postfix.org/postconf.5.html
>>
>> Look for
>> bounce_queue_lifetime
>> maximal_queue_lifetime
> 
> Ram,
> Thanks so much for your help.
> All mails sending from machine A via relaying machine B will arrive in
> machine C.
> I think I need to set up something in machine B so that there will be no mails
> bounce back to machine A.

if you want machine B to send no bounces, check whether
soft_bounce = yes
is good for you

> From your suggestion, I can see one way to do it is to set
> maximal_queue_lifetime and bounce_queue_lifetime to 30 days and run
> a script to delete all mails that is in the queue more than 15 day every day.
> Not sure if there is a better way to do it?
> 
> Tom

Re: Sensible config?

[mouss]

Brian Evans - Postfix List a écrit :
> Gaby Vanhegan wrote:
>> Is this sane or is it going to cause problems?
>>
>> /etc/postfix/main.cf:
>> ...
>> # Valid local users only exist in these locations
>> local_recipient_maps = proxy:unix:passwd.byname $alias_maps
>> $virtual_alias_maps
>> ...
>> # What are the domains that we handle mail for?
>> virtual_alias_domains = hash:/etc/postfix/virtual_domains
>> virtual_alias_maps = hash:/etc/postfix/virtual
>>
>> Should I be omitting the $virtual_alias_maps from the
>> local_recipient_maps or does it make no difference at all?
>>
> Do not include virtual_alias_maps in local_recipient_maps.
> virtual_alias_maps are checked globally for all Address Classes.
> 
> For more on Address Classes, see
> http://www.postfix.org/ADDRESS_CLASS_README.html

actually, this has nothing to do with classes.

virtual_alias_maps are _always_ used, so need not be specified in any
recipient maps.

to be clear, virtual_alias_maps apply to all mail, even for domains that
are not yours. for example
j...@yahoo.com  j...@gmail.com
will redirect mail as specified even if you are not yahoo.com.

Re: virtual_alias_maps

[LuKreme]

On 10-Mar-2009, at 15:57, LuKreme wrote:

virtual_alias_maps =
   pcre:$config_directory/virtual.pcre,
   mysql:$config_directory/mysql_virtual_alias_maps.cf
virtual_alias_domains=[list of domains extracted from virtual]



Ugh!

Seems $config_directory/ is not liked by mysql:

whew, it's always something :)

--
Satan oscillate my metallic sonatas

Re: virtual_alias_maps

[Victor Duchovni]

On Tue, Mar 10, 2009 at 05:47:22PM -0600, LuKreme wrote:

> On 10-Mar-2009, at 15:57, LuKreme wrote:
>> virtual_alias_maps =
>>pcre:$config_directory/virtual.pcre,
>>mysql:$config_directory/mysql_virtual_alias_maps.cf
>> virtual_alias_domains=[list of domains extracted from virtual]
>
>
> Ugh!
>
> Seems $config_directory/ is not liked by mysql:

No, mysql never sees the parameter. Main.cf parameters are expanded
first with macros replaced by their values. So if this did not work,
you have a typo of some sort, lack of leading whitespace on multi-line
settings, ...

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

changing sender null address...

[mmelyp]

Hi,

Let see how to explain this...

The issue is that I'm using sieve for my filtering rules, one of my  
rules is to reject a message and notify sender, in this step, postfix  
uses <> as mail from, this is a normal behavior i think; but in my  
scenario where i have one fake domain and using sender_canonical_maps  
for sender address mapping to real domains accounts, also using  
sender_dependent_relayhost_maps for using some relayhost attending the  
sender address (this is an amazing feature)
when postfix wants to send a  bounce message (notifying the rejected  
message), my mail system will always try to deliver it directly to the  
recipient server (i'm not using a relayhost)... i think i need to  
change <> to _real_send...@realdomain. I played with this parameters,  
without sucess:


address_verify_sender_dependent_relayhost_maps
empty_address_relayhost_maps_lookup_key

Also i tried in sender_canonical_maps file:

<>_real_send...@realdomain

I will still testing some other things.


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

Re: changing sender null address...

[Wietse Venema]

mme...@gmail.com:
> Hi,
> 
> Let see how to explain this...
> 
> The issue is that I'm using sieve for my filtering rules, one of my  
> rules is to reject a message and notify sender.

Don't do that.  By bouncing crap to the sender you are harassing
innocent people about mail that they did not send. If you ever
do this to me then you will be blacklisted.

Wietse

Re: about relay server

[tom lee]

On Tue, Mar 10, 2009 at 4:14 PM, mouss  wrote:

>> All mails sending from machine A via relaying machine B will arrive in
>> machine C.
>> I think I need to set up something in machine B so that there will be no 
>> mails
>> bounce back to machine A.
>
> if you want machine B to send no bounces, check whether
>        soft_bounce = yes
> is good for you

Thanks. this option should work.

For my case sending mail from A to C via relay machine B,
 machine A -> relay machine B -> Target machine C

the bounced email will be sent back to machine A, is it sent from
machine B or machine C?
I mean should I set soft_bounce in both machine B and machine C, or
just one of them?

Thanks.

tom.

override the catch-all ?

[Curtis]

I've got the catch-all feature explained here working just fine...

http://www.postfix.org/VIRTUAL_README.html

Is there an easy way to designate an explicit *invalid* email address so
that even though the catch-all is enabled for a domain, a specific email
address is considered invalid and is bounced at smtp?

Thanks,

Curtis

Re: v2.5.5 showq and postcat date/time stamp discrepancy

[Glen B]

Wietse Venema wrote:

Ben Winslow:
  

FWIW, my test system uses the system-wide timezone (US/Central)
in the output from mailq and the timezone from $TZ (US/Eastern)
for the output from postcat.  This is, IMO, the correct behavior.



I hadn't thought of that (system versus user time zone). It could
explain the original problem report. The difference is really an
accident of implementation.

When the mail system is running, the mailq command connects to a
showq daemon which reports times according to the system time zone.

When the mail system is stopped, the super-user can still execute
the mailq command. In this case, mailq executes the showq program
directly, and will report times according to the "user" time zone.

Wietse

  


 That appears to be the case but I'm not sure how to deal with it since 
I only have _one_ timezone configured on my server and showq is not 
chrooted. It's tough trying to obtain the queue contents from postcat 
when the message arrival scope can change based on service status. I 
considered reading the queue files directly but you've stated that the 
format is not documented and therefore should not be read/written 
directly. So, can I request a raw message dump tool that simply outputs 
the headers and data section? I'd be fine with a raw envelope used in 
SMTP DATA transactions. If this is possible with an existing tool then 
I'd be fine with that also. As it stands I can't rely on postcat output 
having an accurate local date/time.


Thanks,

GlenB

Re: override the catch-all ?

[Sahil Tandon]

On Mar 10, 2009, at 9:27 PM, Curtis wrote:


I've got the catch-all feature explained here working just fine...

http://www.postfix.org/VIRTUAL_README.html

Is there an easy way to designate an explicit *invalid* email  
address so that even though the catch-all is enabled for a domain, a  
specific email address is considered invalid and is bounced at smtp?


Use transport maps to direct messages for the specific email address  
to the error mailer.


http://www.postfix.org/transport.5.html
http://www.postfix.org/error.8.html

--
Sahil Tandon 

Re: override the catch-all ?

[Victor Duchovni]

On Tue, Mar 10, 2009 at 10:23:30PM -0400, Sahil Tandon wrote:

> On Mar 10, 2009, at 9:27 PM, Curtis wrote:
>
>> I've got the catch-all feature explained here working just fine...
>>
>> http://www.postfix.org/VIRTUAL_README.html
>>
>> Is there an easy way to designate an explicit *invalid* email address so 
>> that even though the catch-all is enabled for a domain, a specific email 
>> address is considered invalid and is bounced at smtp?
>
> Use transport maps to direct messages for the specific email address to the 
> error mailer.
>
>   http://www.postfix.org/transport.5.html
>   http://www.postfix.org/error.8.html

This works because smtpd(8) policy is applied to input address before
rewriting. One can also enhance the rewriting tables:

virtual:
@example.comcatch...@example.com
bo...@example.com   nosuchu...@address.invalid

transport:
bo...@example.com   error:5.1.1 Invalid recipient address
address.invalid error:5.1.1 Invalid recipient address

this bounces the address when submitted locally.

-- 
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: v2.5.5 showq and postcat date/time stamp discrepancy

[Glen B]

Glen B wrote:

Wietse Venema wrote:

Ben Winslow:
 

FWIW, my test system uses the system-wide timezone (US/Central)
in the output from mailq and the timezone from $TZ (US/Eastern)
for the output from postcat.  This is, IMO, the correct behavior.



I hadn't thought of that (system versus user time zone). It could
explain the original problem report. The difference is really an
accident of implementation.

When the mail system is running, the mailq command connects to a
showq daemon which reports times according to the system time zone.

When the mail system is stopped, the super-user can still execute
the mailq command. In this case, mailq executes the showq program
directly, and will report times according to the "user" time zone.

Wietse

  


 That appears to be the case but I'm not sure how to deal with it 
since I only have _one_ timezone configured on my server and showq is 
not chrooted. It's tough trying to obtain the queue contents from 
postcat when the message arrival scope can change based on service 
status. I considered reading the queue files directly but you've 
stated that the format is not documented and therefore should not be 
read/written directly. So, can I request a raw message dump tool that 
simply outputs the headers and data section? I'd be fine with a raw 
envelope used in SMTP DATA transactions. If this is possible with an 
existing tool then I'd be fine with that also. As it stands I can't 
rely on postcat output having an accurate local date/time.


Thanks,

GlenB



Update: /etc/default/rcS had UTC=yes configured so it was defaulting to 
UTC if no timezone was set. Why no TZ was set in the chroot, I'm 
clueless. Maybe it's something else I'm totally unaware of and will find 
out later in life? Now.. things have flipped. mailq shows localtime when 
services are running but UTC when not. I'm losing my marbles now, I 
think. I'll post back if I find a resolution. Otherwise, thanks for the 
help! It's still broken, but at least I know it's not the Postfix code 
as I originally had thought.


GlenB

Re: virtual_alias_maps

[LuKreme]

With these settings

virtual_alias_maps =
   pcre:$config_directory/virtual.pcre,
   mysql:$config_directory/mysql_virtual_alias_maps.cf
virtual_alias_domains = hash:/usr/local/etc/postfix/virtual

I get

mail postfix/smtpd[36156]: NOQUEUE: reject: RCPT from  
lists.php.net[216.92.131.4]: 450 4.1.1 : Recipient  
address rejected: User unknown; from=> to= proto=ESMTP helo=


$ postmap -q krem...@kreme.com hash:/usr/local/etc/postfix/virtual
krem...@covisp.net

with THESE settings, all mail is delivered properly:

virtual_alias_maps =
   hash:/usr/local/etc/postfix/virtual
   pcre:$config_directory/virtual.pcre,
   mysql:$config_directory/mysql_virtual_alias_maps.cf
#virtual_alias_domains =

No changes to any files other than that one change to main.cf.

--
The Germans wore gray, you wore blue.

Re: virtual_alias_maps

[Victor Duchovni]

On Tue, Mar 10, 2009 at 09:30:01PM -0600, LuKreme wrote:

> With these settings
>
> virtual_alias_maps =
>pcre:$config_directory/virtual.pcre,
>mysql:$config_directory/mysql_virtual_alias_maps.cf
> virtual_alias_domains = hash:/usr/local/etc/postfix/virtual
>
> I get
>
> mail postfix/smtpd[36156]: NOQUEUE: reject: RCPT from 
> lists.php.net[216.92.131.4]: 450 4.1.1 : Recipient 
> address rejected: User unknown; 
> from= 
> to= proto=ESMTP helo=

This happens when the recipient is not found in virtual_alias_maps,
because likely you not only moved the virtual domains, but you also
moved rewrites for some users along with them.

>
> $ postmap -q krem...@kreme.com hash:/usr/local/etc/postfix/virtual
> krem...@covisp.net

You are supposed to now have just the domains here, and the user mappings
in virtual_alias_maps. I did say multiple times that this setting depends
on *ONLY* the domains being listed in this file. Otherwise use two files:

/etc/postfix/virtual_alias_domains:
example.com virtual alias domain
example.net virtual alias domain

/etc/postfix/virtual:
j...@example.comj...@somewhere
f...@example.netf...@somewhere

And thus:

virtual_alias_domains = hash:/etc/postfix/virtual_alias_domains
virtual_alias_maps = hash:/etc/postfix/virtual,
... more tables for virtual(5) rewrites ...

>
> with THESE settings, all mail is delivered properly:
>
> virtual_alias_maps =
>hash:/usr/local/etc/postfix/virtual
>pcre:$config_directory/virtual.pcre,
>mysql:$config_directory/mysql_virtual_alias_maps.cf
> #virtual_alias_domains =
>
> No changes to any files other than that one change to main.cf.

Of course, now the user mappings are back. The fix is to keep the users
in virtual_alias_maps and move JUST the DOMAINS to a new table. Do take
some time to understand the reasons for everything have seen.

-- 
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: virtual_alias_maps

[Sahil Tandon]

On Mar 10, 2009, at 11:30 PM, LuKreme wrote:


With these settings

virtual_alias_maps =
  pcre:$config_directory/virtual.pcre,
  mysql:$config_directory/mysql_virtual_alias_maps.cf
virtual_alias_domains = hash:/usr/local/etc/postfix/virtual

I get

mail postfix/smtpd[36156]: NOQUEUE: reject: RCPT from  
lists.php.net[216.92.131.4]: 450 4.1.1 :  
Recipient address rejected: User unknown; from=> to= proto=ESMTP helo=


Postfix is working as expected; you removed the mapping from krem...@kreme.com 
 -> krem...@covisp.net by excluding that hash table from  
virtual_alias_maps.  As documented, valid recipient addresses are  
listed with the virtual_alias_maps parameter, so with the above change  
to your main.cf, Postfix no longer accepts mail from krem...@kreme.com.



$ postmap -q krem...@kreme.com hash:/usr/local/etc/postfix/virtual
krem...@covisp.net


The lookup key for virtual_alias_DOMAINS should be a domain name, not  
full address.  Are you going to reply with some more sarcastic  
pedantry? :-)


--
Sahil Tandon 

Re: virtual_alias_maps

[Sahil Tandon]

On Mar 10, 2009, at 11:48 PM, Sahil Tandon wrote:

[...]

 so with the above change to your main.cf, Postfix no longer accepts  
mail from krem...@kreme.com.


s/from/for/

--
Sahil Tandon 

postfix xforward queueid patch

[saguto yin]

hi, folks

this is a simple patch to make postfix 2.5.6 send queueid by xforward
command to next-hop, hope this can be ...

BTW: server side queueid parse does not  done in this patch.

good luck.

saguto yin

cut--
diff -ruN postfix-2.5.6/src/global/mail_proto.h
xfer-queueid-postfix-2.5.6/src/global/mail_proto.h
--- postfix-2.5.6/src/global/mail_proto.h 2007-12-13 04:28:28.0
+0800
+++ xfer-queueid-postfix-2.5.6/src/global/mail_proto.h 2009-03-11
14:18:21.0 +0800
@@ -217,6 +217,7 @@
 #define XFORWARD_DOMAIN  "SOURCE"/* origin type */
 #define XFORWARD_DOM_LOCAL "LOCAL" /* local origin */
 #define XFORWARD_DOM_REMOTE "REMOTE"/* remote origin */
+#define XFORWARD_QUEUEID "QUEUEID"/* queueid origin */

 #define XFORWARD_UNAVAILABLE "[UNAVAILABLE]" /* attribute unavailable */

diff -ruN postfix-2.5.6/src/smtp/smtp.h
xfer-queueid-postfix-2.5.6/src/smtp/smtp.h
--- postfix-2.5.6/src/smtp/smtp.h 2008-01-09 22:04:37.0 +0800
+++ xfer-queueid-postfix-2.5.6/src/smtp/smtp.h 2009-03-11 14:18:35.0
+0800
@@ -119,6 +119,7 @@
 #define SMTP_FEATURE_PIX_NO_ESMTP (1<<16) /* PIX smtp fixup mode */
 #define SMTP_FEATURE_PIX_DELAY_DOTCRLF (1<<17) /* PIX smtp fixup mode */
 #define SMTP_FEATURE_XFORWARD_PORT (1<<18)
+#define SMTP_FEATURE_XFORWARD_QUEUEID (1<<19)

  /*
   * Features that passivate under the endpoint.
diff -ruN postfix-2.5.6/src/smtp/smtp_proto.c
xfer-queueid-postfix-2.5.6/src/smtp/smtp_proto.c
--- postfix-2.5.6/src/smtp/smtp_proto.c 2008-01-09 22:04:37.0 +0800
+++ xfer-queueid-postfix-2.5.6/src/smtp/smtp_proto.c 2009-03-11
14:18:36.0 +0800
@@ -271,6 +271,7 @@
  XFORWARD_PROTO, SMTP_FEATURE_XFORWARD_PROTO,
  XFORWARD_HELO, SMTP_FEATURE_XFORWARD_HELO,
  XFORWARD_DOMAIN, SMTP_FEATURE_XFORWARD_DOMAIN,
+ XFORWARD_QUEUEID, SMTP_FEATURE_XFORWARD_QUEUEID,
  0, 0,
 };
 SOCKOPT_SIZE optlen;
@@ -1239,6 +1240,12 @@
DEL_REQ_ATTR_AVAIL(request->client_port) ?
   request->client_port : XFORWARD_UNAVAILABLE, "");
  }
+ if (session->features & SMTP_FEATURE_XFORWARD_QUEUEID) {
+  vstring_strcat(next_command, " " XFORWARD_QUEUEID "=");
+  xtext_quote_append(next_command,
+   DEL_REQ_ATTR_AVAIL(request->queue_id) ?
+  request->queue_id : XFORWARD_UNAVAILABLE, "");
+ }
  if (session->send_proto_helo)
   next_state = SMTP_STATE_XFORWARD_PROTO_HELO;
  else