Re: [maybe OT] postfix HA

[Victor Duchovni]

On Wed, Mar 25, 2009 at 11:07:04PM +0100, mouss wrote:

> I am trying to "collect" methods to setup postfix in an HA
> configuration, for "outbound" relay (no MUA involved). a use case is
> using multiple postfix boxes to relay mail out for one or more exchange
> servers. there are many possibilities. which one is
> "good/recommended/easy/blahblah"? This is somewhat off topic since the
> problem is mostly on the client (exchange or other) side rather than
> postfix. but I think this is a real need. and if I get enough infos, I
> can aggregate them and submit that as a howto/readme.

If the Exchange servers are able to cache connections, just use equal
weight MX records. Otherwise, and perhaps in any case, configure low
SMTP connect and HELO timeouts, and set high (Exchange facing) smtpd(8)
process limits on the Postfix servers to ensure the that the total # of
available Postfix connections comfortably exceeds the Exchange outgoing
connection limit.

That's it, if all the Postfix servers are up all is well, and if one
is down or slow, Exchange uses the other one(s) with low additional
delay.

-- 
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: Piping /etc/aliases to newaliases

[Noel Jones]

Bryce Nesbitt wrote:

Dear Postfix Experts,

Is there a way to get a pipe going to newaliases / sendmail -I / postalias?

I felt a strong need to have end of line comment characters in 
/etc/aliases ;-).  So my first shot at that was:

   sed 's/#.*$//' aliases | newalises

Which failed spectacularly. And yes, I know that # is legal in email 
addresses, I accept the tradoff to get nice neat comments,

grepable by alias:

   # The fumble section of of our aliases
   #
   foo: fum  # requested by fumble on 20090101
   fiddle: fie,fie,foo   # per ticket #AZ-12313
   living: "danger#...@ly.com"   # Yeah, right



You can't pipe to newaliases.

You can use a proto file with comments and some script to 
create the input file that newaliases requires.  This seems a 
natural for a Makefile.


  -- Noel Jones

Re: [maybe OT] postfix HA

[Noel Jones]

mouss wrote:

I am trying to "collect" methods to setup postfix in an HA
configuration, for "outbound" relay (no MUA involved). a use case is
using multiple postfix boxes to relay mail out for one or more exchange
servers. there are many possibilities. which one is
"good/recommended/easy/blahblah"? This is somewhat off topic since the
problem is mostly on the client (exchange or other) side rather than
postfix. but I think this is a real need. and if I get enough infos, I
can aggregate them and submit that as a howto/readme.





Isn't this what MX records are for?

  -- Noel Jones

RE: [maybe OT] postfix HA

[MacShane, Tracy]

> -Original Message-
> From: owner-postfix-us...@postfix.org 
> [mailto:owner-postfix-us...@postfix.org] On Behalf Of J.P. Trosclair
> Sent: Thursday, 26 March 2009 11:05 AM
> To: mouss+nob...@netoyen.net
> Cc: postfix-users@postfix.org
> Subject: Re: [maybe OT] postfix HA
> 
> mouss wrote:
> > I am trying to "collect" methods to setup postfix in an HA 
> > configuration, for "outbound" relay (no MUA involved). a use case is

> > using multiple postfix boxes to relay mail out for one or more 
> > exchange servers. there are many possibilities. which one is 
> > "good/recommended/easy/blahblah"? This is somewhat off topic since
the 
> > problem is mostly on the client (exchange or other) side rather than

> > postfix. but I think this is a real need. and if I get enough infos,
I 
> > can aggregate them and submit that as a howto/readme.


We have an Exchange infrastructure (9 servers) with two Postfix servers
as the sole outbound MUAs in geographically-diverse sites. All we use is
simply a DNS round-robin alias that points to both Postfix servers,
which the external STMP connector for the Exchange org (and all the
servers inside it) is configured to use. Fairly standard setup - some
round-robin implementations can also do some smarts to determine which
hosts are actually up before returning the IP to the enquirer.

Since these are real SMTP connections, if the first host that is
resolved via the round-robin is unavailable, the Exchange server will
simply retry until get gets a host that replies.

If you want to direct outbound traffic via a specific Postfix
server/round robin alias for specific Exchange servers, and perhaps
another group of Exchange servers via a different outbound route, there
is no problem with setting up more than one SMTP connecter in the
Exchange org, and adding the appropriate servers/round-robin alias  to
that specific SMTP connector.

Re: [maybe OT] postfix HA

[J.P. Trosclair]

mouss wrote:

I am trying to "collect" methods to setup postfix in an HA
configuration, for "outbound" relay (no MUA involved). a use case is
using multiple postfix boxes to relay mail out for one or more exchange
servers. there are many possibilities. which one is
"good/recommended/easy/blahblah"? This is somewhat off topic since the
problem is mostly on the client (exchange or other) side rather than
postfix. but I think this is a real need. and if I get enough infos, I
can aggregate them and submit that as a howto/readme. 


OpenBSD has a protocol called CARP (Common Address Redundancy Protocol) 
that in a nutshell allows a virtual IP address to be shared among many 
systems. It can do load balancing and fail-overs and is pretty easy to 
work with from my experience. I've only used it in testing, so I can't 
speak for how it stands up to real world scenarios. It was developed to 
be an improvement over VRRP (previously mentioned in another email to 
this thread) and because of licensing issues with VRRP. CARP appears to 
be supported on FreeBSD and NetBSD also. There is a project for Linux 
called uCARP that implements a user-space daemon of this protocol. 
Here's some links for some more info:


http://www.openbsd.org/faq/faq6.html#CARP
http://www.freebsd.org/doc/en/books/handbook/carp.html
http://www.netbsd.org/docs/guide/en/chap-carp.html
http://www.ucarp.org/project/ucarp
http://www.countersiege.com/doc/pfsync-carp/

Re: [maybe OT] postfix HA

[Reinaldo de Carvalho]

On Wed, Mar 25, 2009 at 7:07 PM, mouss  wrote:
> I am trying to "collect" methods to setup postfix in an HA
> configuration, for "outbound" relay (no MUA involved). a use case is
> using multiple postfix boxes to relay mail out for one or more exchange
> servers. there are many possibilities. which one is
> "good/recommended/easy/blahblah"? This is somewhat off topic since the
> problem is mostly on the client (exchange or other) side rather than
> postfix. but I think this is a real need. and if I get enough infos, I
> can aggregate them and submit that as a howto/readme.
>

# apt-cache show vrrpd

Description: Virtual Router Redundancy Protocol user-space implementation
 This package provides an implementation of VRRPv2 as specified in rfc2338.
 It runs in the Linux kernel's userspace (as root).
 .
 VRRP can be used to setup high-availability services in Debian since two
 machines can use the same (virtual) IP address which is transfered upon
 failover. Some kernel features need to be enabled (please read the FAQ)



VRRPD use multicast packet to detect master is down. When multcast
packets from master (bigger priority) stop, slave set IP and MAC
address from master.

Its very simple and usefull.

-- 
Reinaldo de Carvalho
http://korreio.sf.net
http://python-cyrus.sf.net

Re: Piping /etc/aliases to newaliases

[Wietse Venema]

Bryce Nesbitt:
> Dear Postfix Experts,
> 
> Is there a way to get a pipe going to newaliases / sendmail -I / postalias?

All the supported features are in the DOCUMENTATION.

Wietse

> I felt a strong need to have end of line comment characters in 
> /etc/aliases ;-).  So my first shot at that was:
> sed 's/#.*$//' aliases | newalises
> 
> Which failed spectacularly. And yes, I know that # is legal in email 
> addresses, I accept the tradoff to get nice neat comments,
> grepable by alias:
> 
> # The fumble section of of our aliases
> #
> foo: fum  # requested by fumble on 20090101
> fiddle: fie,fie,foo   # per ticket #AZ-12313
> living: "danger#...@ly.com"   # Yeah, right
> 
> 
> 

Re: Upgrade questions.

[Wietse Venema]

c...@digital-journal.com:
> Hello,
>   I'm considering upgrading Postfix on a Centos box from version
> postfix-2.3.3-2.1.el5_2 to a rpm compiled for another Centos box
> postfix-2.5.6-1.sasl2.rhel5.
> 
> The older version was installed as a part of the Virtualmin add-on package
> and uses Procmail for deliveries to virtual users and has Mailman
> incorporated as well, both of which I'm not familiar with.
> My question; is the master.cf file from the older version usable in the
> newer one? I feel more comfortable modifying the main.cf than the master
> and would like to leave that file as-is if possible.

Please see the RELEASE_NOTES files for incompatible changes. This
project takes pride in providing documentation, out of respect
for its users.

Wietse

Upgrade questions.

[chas]

Hello,
  I'm considering upgrading Postfix on a Centos box from version
postfix-2.3.3-2.1.el5_2 to a rpm compiled for another Centos box
postfix-2.5.6-1.sasl2.rhel5.

The older version was installed as a part of the Virtualmin add-on package
and uses Procmail for deliveries to virtual users and has Mailman
incorporated as well, both of which I'm not familiar with.
My question; is the master.cf file from the older version usable in the
newer one? I feel more comfortable modifying the main.cf than the master
and would like to leave that file as-is if possible.

thanks,
Chas.

Piping /etc/aliases to newaliases

[Bryce Nesbitt]

Dear Postfix Experts,

Is there a way to get a pipe going to newaliases / sendmail -I / postalias?

I felt a strong need to have end of line comment characters in 
/etc/aliases ;-).  So my first shot at that was:

   sed 's/#.*$//' aliases | newalises

Which failed spectacularly. And yes, I know that # is legal in email 
addresses, I accept the tradoff to get nice neat comments,

grepable by alias:

   # The fumble section of of our aliases
   #
   foo: fum  # requested by fumble on 20090101
   fiddle: fie,fie,foo   # per ticket #AZ-12313
   living: "danger#...@ly.com"   # Yeah, right

Re: check_recipient_access does not seem to be working for me

[mouss]

Xn Nooby a écrit :
> I'm using Postfix on RHEL5.
> 
> I want my local users to only be able to send and receive emails from
> users on another mail server, I do not want local users to be able to
> email eachother. I have not been able to prevent local users from
> emailing eahcother. It seems my check_recipient_access is not working.
> 
> My logic is as follows:
>   check_sender_access will allow all emails from "@other-domain"
>   check_recipient_access will allow all emails to "@other-domain"
>   check_recipient_access will reject all other emails
> 
> Does this look correct?
> 
> 

this means

allow if: sender is allowed  OR recipient is allowed

which is not what you want.

you want AND instead of OR. for that, you need RESTRICTIONS CLASSES.

Re: spam check only local destinations

[mouss]

Georgy Goshin a écrit :
> 
> 
>>
>> what do you really mean?
>>
> 
> I really mean that the server is a relay for some domains and a local
> mailserver for one domain, so I need to check mails with spamassassin
> only mails that came here and not to check relayed mails.
> 

so you want per recipient filtering. the problem here is when mail comes
in for multiple recipients.

1- if it's ok to filter mail if one of the recipient is local
(eventhough other recipients may belong to other domains), you can use
check_recipient_access:

content_filter =

smtpd_sender_restrictions =
check_recipient_access hash:/etc/postfix/filter

== filter:
example.com FILTER spamfilter:nexthop

2- otherwise, you need multiple postfix instance (run postfix twice) and
use transport_maps instead of content_filter.

In (1), a multi-recipient message is not split into local and relay
copies. it's passed to the filter as soon as one of the recipients is
local (is *...@example.com).

In (2), the message is split: one copy is sent to "local" users after
filtering. another copy is relayed without filtering.

[maybe OT] postfix HA

[mouss]

I am trying to "collect" methods to setup postfix in an HA
configuration, for "outbound" relay (no MUA involved). a use case is
using multiple postfix boxes to relay mail out for one or more exchange
servers. there are many possibilities. which one is
"good/recommended/easy/blahblah"? This is somewhat off topic since the
problem is mostly on the client (exchange or other) side rather than
postfix. but I think this is a real need. and if I get enough infos, I
can aggregate them and submit that as a howto/readme.

Re: spam check only local destinations

[Georgy Goshin]

what do you really mean?



I really mean that the server is a relay for some domains and a local 
mailserver for one domain, so I need to check mails with spamassassin only 
mails that came here and not to check relayed mails.



Thanks,
G 

Re: Am I a backscattered email source?

[mouss]

Ivan Ricotti a écrit :
> Hello Ralf,
> 
> thanks for your reply!
> 
> Ralf Hildebrandt wrote:
>>  reject_rbl_client cbl.abuseat.org,
>>  reject_rbl_client sbl.spamhaus.org,
>>
>> can be merged into:
>>  reject_rbl_client zen.spanhaus.org
>>
> 
> ok, thanks.
> 

and put that before spamcops list.

also remove reject_unauth_pipelining. it's useless in
smtpd_recipient_restrictions. you can put it under
smtpd_data_restrictions. but it won't catch a lot of junk...

Here is a "better" ordering of your checks:

smtpd_recipient_restrictions =
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_invalid_hostname,


now, depending on your setup, I would remove
reject_unknown_recipient_domain and reject_unknown_sender_domain.

>>> Now in my /var/log/mail.info I have a lot of lines like this:
>>>
>>> Mar 25 11:35:10 athene postfix/smtpd[24933]: NOQUEUE: reject: RCPT from
>>> unknown[92.101.112.32]: 554 5.7.1 Service unavailable; Client host
>>> [92.101.112.32] blocked using bl.spamcop.net; Blocked - see
>>> http://www.spamcop.net/bl.shtml?92.101.112.32;
>>> from= to=
>>> proto=SMTP helo=
>>>
>>> Now I fear to be source of backscatter emails. Is that my case?
>> No.
>>
> 
> Wow! That's a very good news!
> Could I ask you why? What I missed?
> 

reject != bounce

- reject means that postfix says: I don't want you message. go away.
This is done while the smtp client ("the other side") is connected.

- bounce means: postfix says "ok. I accept your message. I'll take care
of it", then later for some reason, the message can't be delivered.
since postfix accepted the message, it needs to generate a bounce. and
the bounce will go to the original envelope sender. unfortunately, this
sender may have been forged. in which case, the bounce goes to an
innocent who never asked for it. this is backscatter.

Re: spam check only local destinations

[mouss]

Georgy Goshin a écrit :
> Hi,
> 
> I'm checking mail with spamassassin with this conf:
> 
> smtp  inet  n   -   n   -   -   smtpd
>  -o content_filter=spamfilter:dummy
> 

consider using amavisd-new instead of a wrapper.

> 
> How to check only local destination?
> 

what do you really mean?

if you only want to filter "inbound mail", you can exclude mynetworks
and sasl authenticated mail from filtering. or do you want somlething else?

Re: /etc/aliases is not applied

[Stephen Carville]

On Wed, Mar 25, 2009 at 1:20 PM, Brian Evans - Postfix List
 wrote:

> We prefer 'postconf -n' for a reason.  It makes for a much shorter email

Next time I will use the -n switch.

>> local_recipient_maps = proxy:unix:passwd.byname $alias_maps
>> mydestination = $myhostname, localhost.$mydomain, localhost
>> mydomain = lereta.com
>> myhostname = scaciio01.lereta.com
>> myorigin = $mydomain
> When unqualified domains are given to postfix from the sendmail(1)
> command, myorigin is appended.
> Your myorigin is not in mydestination so it relays to wherever
> lereta.com normally goes.
> alias_maps are only applied to items delivered using local(8) delivery
> agent.
> local(8) delivers to destinations located in mydestination.

Jeez!  I must have looked at that 100+ times today and I didn't see
it.   I changed myorigin to $myhostname and all is working correctly
again.  This was driving me and the other mail admin (he's a Sendmail
guy) buggy.  I knew it should work but  it didn't.

Thank you very much...

-- 
Stephen Carville

Re: Postfix and LDAP disabled user

[Victor Duchovni]

On Wed, Mar 25, 2009 at 04:20:24PM -0300, M. Rodrigo Monteiro wrote:

> Hi!
> 
> I'm reading the "Postfix: The Definitive Guide". Great book, BTW.
> In the LDAP configuration, I realise that the filter for the active
> users is "(&(mail=%s)(accountStatus=active))".

There is no default LDAP schema in Postfix, this is just an example.
You can put anything you want in your LDAP queries.

> In my LDAP schema (from Ubuntu slapd - core.schema, cosine.schema,
> nis.schema, misc.schema - and from Ubuntu Samba samba.schema) don't
> have the accountStatus attribute.
> When the user become disabled, what I saw in his attribute is the
> sambaAcctFlags changing from [U] to [UD]. I guess the D is for
> disabled.
> My question is: how can Postfix verify if the user is disabled in this
> configuration? Or should I change someting?

You choose which LDAP queries to use and in what context. In fact
you should first test without LDAP at all, with indexed tables,
and then create LDAP tables that mimic the indexed files.

-- 
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: /etc/aliases is not applied

[Brian Evans - Postfix List]

Stephen Carville wrote:
> For some reason, my /etc/aliases file is not applied.  For example I
> have the entry
>
> root: unixad...@it.lereta.com
>
> $ postmap -q root hash:/etc/aliases
> unixad...@it.lereta.com
>
> However, if I send a mail to root
>
> $ mail -s "Test VIV" root
Sent as unqualified.
> My configuration:
>   
We prefer 'postconf -n' for a reason.  It makes for a much shorter email
> local_recipient_maps = proxy:unix:passwd.byname $alias_maps
> mydestination = $myhostname, localhost.$mydomain, localhost
> mydomain = lereta.com
> myhostname = scaciio01.lereta.com
> myorigin = $mydomain
When unqualified domains are given to postfix from the sendmail(1)
command, myorigin is appended.
Your myorigin is not in mydestination so it relays to wherever
lereta.com normally goes.
alias_maps are only applied to items delivered using local(8) delivery
agent.
local(8) delivers to destinations located in mydestination.

Brian

/etc/aliases is not applied

[Stephen Carville]

For some reason, my /etc/aliases file is not applied.  For example I
have the entry

root: unixad...@it.lereta.com

$ postmap -q root hash:/etc/aliases
unixad...@it.lereta.com

However, if I send a mail to root

$ mail -s "Test VIV" root 

scaciio01 postfix/cleanup[11600]: 14E5B1E20033:
message-id=<20090325180717.14e5b1e20...@scaciio01.lereta.com>

scaciio01 postfix/qmgr[11018]: 14E5B1E20033: from=,
size=300, nrcpt=1 (queue active)

scaciio01 postfix/smtp[11602]: 14E5B1E20033: to=,
orig_to=, relay=mail.totalflood.com[172.21.15.143]:25,
delay=0.19, delays=0.1/0.01/0.04/0.04, dsn=2.0.0, status=sent (250 Ok:
queued as 2C473540C0)

scaciio01 postfix/qmgr[11018]: 14E5B1E20033: removed

Any idea what I am doing wrong?

My configuration:

2bounce_notice_recipient = postmaster
access_map_reject_code = 554
address_verify_default_transport = $default_transport
address_verify_local_transport = $local_transport
address_verify_map =
address_verify_negative_cache = yes
address_verify_negative_expire_time = 3d
address_verify_negative_refresh_time = 3h
address_verify_poll_count = 3
address_verify_poll_delay = 3s
address_verify_positive_expire_time = 31d
address_verify_positive_refresh_time = 7d
address_verify_relay_transport = $relay_transport
address_verify_relayhost = $relayhost
address_verify_sender = postmaster
address_verify_sender_dependent_relayhost_maps =
$sender_dependent_relayhost_maps
address_verify_service_name = verify
address_verify_transport_maps = $transport_maps
address_verify_virtual_transport = $virtual_transport
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_mail_to_commands = alias, forward
allow_mail_to_files = alias, forward
allow_min_user = no
allow_percent_hack = yes
allow_untrusted_routing = no
alternate_config_directories =
always_bcc =
anvil_rate_time_unit = 60s
anvil_status_update_time = 600s
append_at_myorigin = yes
append_dot_mydomain = yes
application_event_drain_time = 100s
authorized_flush_users = static:anyone
authorized_mailq_users = static:anyone
authorized_submit_users = static:anyone
backwards_bounce_logfile_compatibility = yes
berkeley_db_create_buffer_size = 16777216
berkeley_db_read_buffer_size = 131072
best_mx_transport =
biff = yes
body_checks =
body_checks_size_limit = 51200
bounce_notice_recipient = postmaster
bounce_queue_lifetime = 5d
bounce_service_name = bounce
bounce_size_limit = 5
bounce_template_file =
broken_sasl_auth_clients = no
canonical_classes = envelope_sender, envelope_recipient,
header_sender, header_recipient
canonical_maps =
cleanup_service_name = cleanup
command_directory = /usr/sbin
command_execution_directory =
command_expansion_filter =
12345678...@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
command_time_limit = 1000s
config_directory = /etc/postfix
connection_cache_protocol_timeout = 5s
connection_cache_service_name = scache
connection_cache_status_update_time = 600s
connection_cache_ttl_limit = 2s
content_filter =
daemon_directory = /usr/libexec/postfix
daemon_timeout = 18000s
debug_peer_level = 2
debug_peer_list =
default_database_type = hash
default_delivery_slot_cost = 5
default_delivery_slot_discount = 50
default_delivery_slot_loan = 3
default_destination_concurrency_limit = 20
default_destination_recipient_limit = 50
default_extra_recipient_limit = 1000
default_minimum_delivery_slots = 3
default_privs = nobody
default_process_limit = 100
default_rbl_reply = $rbl_code Service unavailable; $rbl_class
[$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}
default_recipient_limit = 1
default_transport = smtp
default_verp_delimiters = +=
defer_code = 450
defer_service_name = defer
defer_transports =
delay_logging_resolution_limit = 2
delay_notice_recipient = postmaster
delay_warning_time = 0h
deliver_lock_attempts = 20
deliver_lock_delay = 1s
disable_dns_lookups = no
disable_mime_input_processing = no
disable_mime_output_conversion = no
disable_verp_bounces = no
disable_vrfy_command = no
dont_remove = 0
double_bounce_sender = double-bounce
duplicate_filter_limit = 1000
empty_address_recipient = MAILER-DAEMON
enable_original_recipient = yes
error_notice_recipient = postmaster
error_service_name = error
execution_directory_expansion_filter =
12345678...@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
expand_owner_alias = no
export_environment = TZ MAIL_CONFIG LANG
fallback_transport =
fallback_transport_maps =
fast_flush_domains = $relay_domains
fast_flush_purge_time = 7d
fast_flush_refresh_time = 12h
fault_injection_code = 0
flush_service_name = flush
fork_attempts = 5
fork_delay = 1s
forward_expansion_filter =
12345678...@%-_=+:,./abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
forward_path = $home/.forward${recipient_delimiter}${extension}, $home/.forward
frozen_delivered_to = yes
hash_queue_depth = 1
hash_queue_names = deferred, defer
header_address_token_limit = 10240
header_checks =
header_size_limit = 102400
helpful_warnings = yes
home_mailbox =
hopcount_lim

Postfix and LDAP disabled user

[M. Rodrigo Monteiro]

Hi!

I'm reading the "Postfix: The Definitive Guide". Great book, BTW.
In the LDAP configuration, I realise that the filter for the active
users is "(&(mail=%s)(accountStatus=active))".
In my LDAP schema (from Ubuntu slapd - core.schema, cosine.schema,
nis.schema, misc.schema - and from Ubuntu Samba samba.schema) don't
have the accountStatus attribute.
When the user become disabled, what I saw in his attribute is the
sambaAcctFlags changing from [U] to [UD]. I guess the D is for
disabled.
My question is: how can Postfix verify if the user is disabled in this
configuration? Or should I change someting?

Regards,
Rodrigo.


-- 
M. Rodrigo Monteiro
fale...@rodrigomonteiro.net
"Free as in Freedom, not free as in free beer"
"As we are liberated from our own fear, our presence automatically
liberates others"
Linux User # 403730

Re: VERPify recommendations

[Wietse Venema]

Steve Crawford:
> I haven't had much time to experiment with re-injection but my 
> experiments thus far have failed. Any pointers on how this would be 
> done? 

See: http://www.postfix.org/FILTER_README.html in particular the
section that shows how to inject mail with the Postfix sendmail
command.

Wietse

fatal: open lock file pid/master.pid: unable to set exclusive lock: Resource temporarily unavailable

[Rupert Reid]

Hello All,

I am running postfix (apple version) with MAC OSX10.4.11 client.  I  
found the following entries in the "console.log".


Mar 25 13:49:23 postfix/master[2077]: fatal: open lock file pid/ 
master.pid: unable to set exclusive lock: Resource temporarily  
unavailable
Mar 25 13:57:44 postfix/master[2096]: fatal: open lock file pid/ 
master.pid: unable to set exclusive lock: Resource temporarily  
unavailable
Mar 25 14:06:24 postfix/master[2113]: fatal: open lock file pid/ 
master.pid: unable to set exclusive lock: Resource temporarily  
unavailable
Mar 25 14:10:09 postfix/master[2122]: fatal: open lock file pid/ 
master.pid: unable to set exclusive lock: Resource temporarily  
unavailable
Mar 25 14:15:10 postfix/master[2130]: fatal: open lock file pid/ 
master.pid: unable to set exclusive lock: Resource temporarily  
unavailable
Mar 25 14:18:52 postfix/master[2140]: fatal: open lock file pid/ 
master.pid: unable to set exclusive lock: Resource temporarily  
unavailable


I did some research on the internet and I found:
Quote

Postfix on OSX: Fatal: Open Lock File pid/master.pid

You use OSX. You change the Postfix configuration, or maybe you  
install your own. You get this error throughout your mail.log:  
"fatal: open lock file pid/master.pid: unable to set exclusive lock:  
Resource temporarily unavailable"


I know you do, because I've seen you asking about it all over the  
Internets, and no one ever has an answer. Well, try this, because it  
worked for me (click through)...


Macintosh OSX 10.4 uses something called "launchd" to control daemons  
(among other things). This includes the default Postfix master  
executable.


When mail is received, the running Postfix master wants to handle it.  
But launchd wants to handle it, too. The result is that they both try  
to lock the master.pid file at the same time.


Try this command, as root (or use sudo):
#launchctl list

If you see "org.postfix.master" in the list of launchd jobs, then  
this is probably what is causing the lock errors in your logs.


To fix the problem, edit the org.postfix.master.plist file in /System/ 
Library/LaunchDaemons (as root or using sudo):

#nano -w /System/Library/LaunchDaemons/org.postfix.master.plist

Add the following two tags within the  container:
Disabled


Then Restart your Mac. Do not try to restart launchd by iteself, it  
will most likely put your system into an unusable state (at least, it  
buggered mine when I tried it).


After restart, try launchctl list again. There should be no  
org.postfix.master record. Use postfix start to launch the mail  
system, send yourself a test message, and check the logs. Good luck!

EndQuote

I would like some reassurance from this list that this is the problem  
and the appropriate action to correct it.


Below is the output of 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.domin1.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 = hash:/etc/postfix/virtual_alias_maps

Thanks Rupert

Re: Performance Concerns

[Victor Duchovni]

On Wed, Mar 25, 2009 at 10:30:26AM -0500, Noel Jones wrote:

> Jacky Chan wrote:
>> Hi all,
>> I am setup Postfix 2.5 to run on Linux box with 2 x 1.2 G PIII and 1280MB
>> RAM server.
>> I also setup a list of firewall rules (iptables) for restricting port 25
>> access.
>> In compare of own access table in Postfix, which way has better 
>> performance
>> when the server is high-loaded? I noticed that there were some discussion 
>> on
>> the performance of harddisk, but regarding to my assumption above, I think
>> hard disk performance may not be the biggest factor, is that true?
>> Best,
>> Jacky
>
> Postfix itself should run fine on such hardware.  If you add filtering such 
> as clamav and/or spamassassin you may have performance issues if you filter 
> more than a few thousand messages per day.

More than a few hundred thousand. 86,400 seconds in a day, very few filters
use more than 1 CPU second per message. Most filters comfortably handle ~20
messages per second, very fast ones may handle 100 msgs/sec. High latency
(but not CPU hungry) filters may need high concurrency.

Bottom line, a typical machine will handle a few hundred thousand messages
a day (traffic will typically be concentrated in a few peak hours).

-- 
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: VERPify recommendations

[Steve Crawford]

Noel Jones wrote:

Steve Crawford wrote:
While we do not manage a "mailing list" in the traditional sense, we 
do send a lot of emails (daily/weekly/monthly reports, instant-alert 
messages, etc.) where using VERP to track bounces could prove useful.


We run numerous projects with varying requirements and the messages 
could be generated by Perl, Python, Bash/mutt, etc. All 
inbound/outbound mail is routed through Postfix.


In my ideal world, I would find a magic setting that said, say, "use 
VERP for all messages from f...@pinpointresearch.com" or perhaps from 
some specific IP range. Digging through the docs and list archives 
indicates this does not exist


So I'm seeking recommendations/ideas...
Seems to me that if you want to use SMTP and you control the 
submitting software it should be easy enough to add XVERP to the MAIL 
FROM command:

http://www.postfix.org/VERP_README.html#smtp

Long delay from last message while out of town.

I had read that and it is easy if I netcat into Postfix and run the 
commands manually. But the other utilities do not understand XVERP. I 
tried fooling mutt into adding it but have been unable to get them to 
add the XVERP to the FROM - the usual result is that they misinterpret 
the XVERP as an additional from address.


If there were a _separate_ header, say "X-VERP: true", triggering VERP 
delivery would be easy with most of the utilities. The problem is that 
they don't understand the modification to the FROM command and try to 
munge and/or correct it into something it believes is correct. (If I'm 
missing something that is available in the standard mail utilities in 
Perl/Python/Ruby or mutt, please let me know.)


It wouldn't be safe to do this by sender address, but you could use a 
check_client_access table with a FILTER result pointing to a pipe 
transport that does a "sendmail -XV ..." reinjection. 



Actually, in our case all system-delivered messages, reports etc. come 
from a single standard address and VERPifying all of them would not hurt 
anything.


I haven't had much time to experiment with re-injection but my 
experiments thus far have failed. Any pointers on how this would be 
done? One possibility that would work for me is to have a VERPifying 
"pre-server". All messages going to that server would be VERPified and 
forwarded to the main mailserver. Any process needing VERP would simply 
send to that server instead of the main server.


Cheers,
Steve

check_recipient_access does not seem to be working for me

[Xn Nooby]

I'm using Postfix on RHEL5.

I want my local users to only be able to send and receive emails from
users on another mail server, I do not want local users to be able to
email eachother. I have not been able to prevent local users from
emailing eahcother. It seems my check_recipient_access is not working.

My logic is as follows:
  check_sender_access will allow all emails from "@other-domain"
  check_recipient_access will allow all emails to "@other-domain"
  check_recipient_access will reject all other emails

Does this look correct?


-
main.cf
-

...
relayhost = 192.168.1.5
...
smtpd_recipient_restrictions =
 check_sender_access regexp:/etc/postfix/check_sender_access.regexp,
 check_recipient_access regexp:/etc/postfix/check_recipient_access.regexp,
 check_relay_domains,
 reject_unauth_destination

-
/etc/postfix/check_sender_access.regexp contents:
-

/^...@other-domain\.com$/ OK

-
/etc/postfix/check_recipient_access.regexp contents:
-

/^...@other-domain\.com$/ OK
/.*/ REJECT



At one point, I changed check_sender_access.regexp to REJCT emails
from "@other-domain", and it worked. Emails got rejected. So I believe
that the check_sender_access.regexp files is working.

-
postconf -n
-


alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mime_header_checks = regexp:/etc/postfix/mime_header_checks.regexp
mydestination = $mydomain, $myhostname, localhost
myhostname = acmemail.acmecorp.local
mynetworks = 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
relayhost = 192.168.1.5
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_recipient_restrictions = check_sender_access
regexp:/etc/postfix/check_sender_access.regexp,
reject_unauth_destination,  check_recipient_access
regexp:/etc/postfix/check_recipient_access.regexp,
check_relay_domains,  reject
unknown_local_recipient_reject_code = 550
[r...@acmemail postfix]#

Re: Performance Concerns

[Noel Jones]

Jacky Chan wrote:

Hi all,

I am setup Postfix 2.5 to run on Linux box with 2 x 1.2 G PIII and 1280MB
RAM server.
I also setup a list of firewall rules (iptables) for restricting port 25
access.

In compare of own access table in Postfix, which way has better performance
when the server is high-loaded? I noticed that there were some discussion on
the performance of harddisk, but regarding to my assumption above, I think
hard disk performance may not be the biggest factor, is that true?

Best,
Jacky


Postfix itself should run fine on such hardware.  If you add 
filtering such as clamav and/or spamassassin you may have 
performance issues if you filter more than a few thousand 
messages per day.



  -- Noel Jones

Re: Am I a backscattered email source?

[Ralf Hildebrandt]

* Ivan Ricotti :

> >> Mar 25 11:35:10 athene postfix/smtpd[24933]: NOQUEUE: reject: RCPT from
> >> unknown[92.101.112.32]: 554 5.7.1 Service unavailable; Client host
> >> [92.101.112.32] blocked using bl.spamcop.net; Blocked - see
> >> http://www.spamcop.net/bl.shtml?92.101.112.32;
> >> from= to=
> >> proto=SMTP helo=
> >>
> >> Now I fear to be source of backscatter emails. Is that my case?
> > 
> > No.
> > 
> 
> Wow! That's a very good news!
> Could I ask you why? What I missed?

You're just rejecting the mail, not accepting it.

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
So unleash your nmap-from-hell and beware, you may tickle an obscure
bug in an ancient box hand-built by Seymour Cray himself, the only one
of its kind ever made, whose sole user pays the salaries of everyone
you ever met in the entire time you worked at the company, with money
he makes with an investment strategy hand-coded in assembler for this
special machine, by an analytic wizard who has since died. 

Re: Am I a backscattered email source?

[Ivan Ricotti]

Hello Ralf,

thanks for your reply!

Ralf Hildebrandt wrote:
>  reject_rbl_client cbl.abuseat.org,
>  reject_rbl_client sbl.spamhaus.org,
> 
> can be merged into:
>  reject_rbl_client zen.spanhaus.org
> 

ok, thanks.

>> Now in my /var/log/mail.info I have a lot of lines like this:
>>
>> Mar 25 11:35:10 athene postfix/smtpd[24933]: NOQUEUE: reject: RCPT from
>> unknown[92.101.112.32]: 554 5.7.1 Service unavailable; Client host
>> [92.101.112.32] blocked using bl.spamcop.net; Blocked - see
>> http://www.spamcop.net/bl.shtml?92.101.112.32;
>> from= to=
>> proto=SMTP helo=
>>
>> Now I fear to be source of backscatter emails. Is that my case?
> 
> No.
> 

Wow! That's a very good news!
Could I ask you why? What I missed?

Thanks in advance,
Ivan

-- 
Ivan Ricotti
--- 
eLabor sc - via G. Garibaldi 33, 56127 Pisa
tel: +39 050970363 web: http://www.elabor.biz
email: i...@elabor.homelinux.org
GnuPG KeyID: DFD581C5 - 13/11/2003

cannot configure postfix for sender-domain mailboxes

[John Goor]

Hi,

I want my Postfix to accept all email coming from one specific domain (or
multiple specified domains) and put these emails in the designated local
mailfolder.
Purpose is to "catch" all email sent by a specific host. (it is in a
test-setup).

I tried everything I could, using procmail, maildrop, studied the portfix
architecture but I'm afraid it's beyond my scope.
Every solution appeard to have some drawback I cannot work around. It seems
to be much trickier than it sounds.

Please, can anyone provide me with some clear instructions, of even better:
the ultimate solution?
Anything will do.

I'd be very grateful.

(using Ubuntu Jeos, 8.04)

Regards,
John

Re: Am I a backscattered email source?

[Ralf Hildebrandt]

* Ivan Ricotti :

>  smtpd_recipient_restrictions =
> reject_invalid_hostname,
> reject_non_fqdn_sender,
> reject_non_fqdn_recipient,
> reject_unknown_sender_domain,
> reject_unknown_recipient_domain,
> reject_unauth_pipelining,
> permit_mynetworks,
> reject_unauth_destination,
> reject_rbl_client bl.spamcop.net,
> reject_rbl_client cbl.abuseat.org,
> reject_rbl_client sbl.spamhaus.org,
> permit


 reject_rbl_client cbl.abuseat.org,
 reject_rbl_client sbl.spamhaus.org,

can be merged into:
 reject_rbl_client zen.spanhaus.org

> Now in my /var/log/mail.info I have a lot of lines like this:
> 
> Mar 25 11:35:10 athene postfix/smtpd[24933]: NOQUEUE: reject: RCPT from
> unknown[92.101.112.32]: 554 5.7.1 Service unavailable; Client host
> [92.101.112.32] blocked using bl.spamcop.net; Blocked - see
> http://www.spamcop.net/bl.shtml?92.101.112.32;
> from= to=
> proto=SMTP helo=
> 
> Good! I thougth, then I read this help on the postfix documentation page:
> 
>  What is backscatter mail?
> 
>  When a spammer or worm sends mail with forged sender addresses,
>  innocent sites are flooded with undeliverable mail notifications. This
>  is called backscatter mail. With Postfix, you know that you're a
>  backscatter victim when your logfile goes on and on like this:
> 
> Dec  4 04:30:09 hostname postfix/smtpd[58549]: NOQUEUE: reject:
> RCPT from xxx[x.x.x.x]: 550 5.1.1 :
> Recipient address rejected: User unknown; from=<>
> to= proto=ESMTP helo=
> 
>  What you see are lots of "user unknown" errors with "from=<>". These
>  are error reports from MAILER-DAEMONs elsewhere on the Internet.
> 
> ---
> 
> Now I fear to be source of backscatter emails. Is that my case?

No.

-- 
Ralf Hildebrandt
Postfix - Einrichtung, Betrieb und Wartung   Tel. +49 (0)30-450 570-155
http://www.computerbeschimpfung.de
I have never seen anything fill up a vacuum so fast and still suck.
-- Rob Pike, commenting on the X Window System. 

Am I a backscattered email source?

[Ivan Ricotti]

Hello,

I'm having a lot of trouble with spam these days and since I'm running
our mail server administration I'm trying to figure out how to solve the
problem. Unfortunately I'm not so keen in sys administration...

To avoid receiving spam I added these lines to my main.cf configuration:

 smtpd_recipient_restrictions =
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
permit_mynetworks,
reject_unauth_destination,
reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client sbl.spamhaus.org,
permit

Now in my /var/log/mail.info I have a lot of lines like this:

Mar 25 11:35:10 athene postfix/smtpd[24933]: NOQUEUE: reject: RCPT from
unknown[92.101.112.32]: 554 5.7.1 Service unavailable; Client host
[92.101.112.32] blocked using bl.spamcop.net; Blocked - see
http://www.spamcop.net/bl.shtml?92.101.112.32;
from= to=
proto=SMTP helo=

Good! I thougth, then I read this help on the postfix documentation page:

 What is backscatter mail?

 When a spammer or worm sends mail with forged sender addresses,
 innocent sites are flooded with undeliverable mail notifications. This
 is called backscatter mail. With Postfix, you know that you're a
 backscatter victim when your logfile goes on and on like this:

Dec  4 04:30:09 hostname postfix/smtpd[58549]: NOQUEUE: reject:
RCPT from xxx[x.x.x.x]: 550 5.1.1 :
Recipient address rejected: User unknown; from=<>
to= proto=ESMTP helo=

 What you see are lots of "user unknown" errors with "from=<>". These
 are error reports from MAILER-DAEMONs elsewhere on the Internet.

---

Now I fear to be source of backscatter emails. Is that my case?
I also tried to write to my domain an email to an unexistent user and I
had this reply:

---

This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

 ab...@elabor.homelinux.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.1.1 :
Recipient address rejected: User unknown in virtual mailbox table (state
14).

   - Original message -

MIME-Version: 1.0
Received: by 10.103.246.1 with SMTP id y1mr4093237mur.116.1237976577631;
Wed, 25 Mar 2009 03:22:57 -0700 (PDT)
Date: Wed, 25 Mar 2009 11:22:57 +0100
Message-ID: <214f10...@mail.gmail.com>
Subject: test
From: Ivan Ricotti 
To: ab...@elabor.homelinux.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

---

So, I'm a bit confused now. Is my configuration correct or not?
What should I do?

Thanks for any help and sorry for my english,
Ivan

-- 
Ivan Ricotti
--- 
eLabor sc - via G. Garibaldi 33, 56127 Pisa
tel: +39 050970363 web: http://www.elabor.biz
email: i...@elabor.homelinux.org
GnuPG KeyID: DFD581C5 - 13/11/2003

Performance Concerns

[Jacky Chan]

Hi all,

I am setup Postfix 2.5 to run on Linux box with 2 x 1.2 G PIII and 1280MB
RAM server.
I also setup a list of firewall rules (iptables) for restricting port 25
access.

In compare of own access table in Postfix, which way has better performance
when the server is high-loaded? I noticed that there were some discussion on
the performance of harddisk, but regarding to my assumption above, I think
hard disk performance may not be the biggest factor, is that true?

Best,
Jacky
-- 
View this message in context: 
http://www.nabble.com/Performance-Concerns-tp22698113p22698113.html
Sent from the Postfix mailing list archive at Nabble.com.

spam check only local destinations

[Georgy Goshin]

Hi,

I'm checking mail with spamassassin with this conf:

smtp  inet  n   -   n   -   -   smtpd
 -o content_filter=spamfilter:dummy


How to check only local destination?


Thanks,
G.

Re: Postfix Email Journaling?

[Craig Theodore]

ok, yes I should I have mentioned, we currently use always_bcc and it
doesn't do proper envelope journalling. I've been doing some research, to
do the high tech version, I'd have to get a Sendmail Milter and follow the
workarounds (happy to do so) to make it work with Postfix?

cya

Craig


> On Wed, Mar 25, 2009 at 12:01:23PM +0530, ram wrote:
>
>>
>> On Wed, 2009-03-25 at 16:03 +1100, ctheod...@shakenbake.net wrote:
>> > Hi Everyone,
>> >
>> > We have a Email Archive system which is designed for a Email
>> Journaling (from Exchange). Is there a feature (perhaps a milter),
>> within Postfix that can achieve the same feature?
>> >
>> > note: using postfix-2.5.6 on Centos 5.2
>>
>> http://www.postfix.org/postconf.5.html
>>
>> look for always_bcc
>
> No, this does not journal the message envelope, which is what the OP is
> asking for. Low-tech ways of doing that have been posted here before.
>
> The key idea is to abuse per-recipient bcc via regexp tables.
>
> http://www.postfix.org/postconf.5.html#recipient_bcc_maps
>
> then a clever delivery agent (pipe) can combine the message content
> and original envelope in a suitable format.
>
> High-tech ways require custom SMTP content filters. There are probably
> archive milters also.
>
> --
>   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: fallback relay misc

[kemas]

Quoting Victor Duchovni :


On Tue, Mar 24, 2009 at 04:46:06PM +0700, ke...@auditsi.com wrote:



my question is, if some process (not because upgrading) in my
content-filter error, the mail then will be relayed to the 2nd instance
with no filter at all?
Is there option to control it for temporary?


Use a separate transport (not "smtp") for sending mail to the filter,
and in master.cf set:

master.cf:
scan unix ... smtp
-o smtp_fallback_relay=$pre_filter_fback_relay
scan unix ... smtp
-o smtp_fallback_relay=$post_filter_fback_relay

main.cf:
pre_filter_fback_relay=
post_filter_fback_relay=[fallback.example.com]



thanks Victor, I'll try this and get back to the list soon