Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ? (solved !)

[Alexander Grüner]

Hi,

just for info, it has been fixed on saturday.

postconf | grep mail_ver
mail_version = 2.5.6

rpm -qa | grep postfix
postfix-2.5.6-5.6.1

Nessus scan is fine.

Best regards,
Alexander

Re: NOQUEUE: reject: RCPT from unknown[xxxx.xxxx.xxxx.xxx]: 554

[Ralf Hildebrandt]

* motty.cruz :
> Hello, 
> 
> One of our clients is trying to send us email and this is what I see in the
> Logs:
> 
>  
> 
> # grep -i "u...@tld.com" /var/log/maillog | more
> 
> Apr 25 06:49:01 host postfix/smtpd[27269]: NOQUEUE: reject: RCPT from
> unknown[xxx.xxx.xxx.xxx]: 554 5.7.1 Client host rejected: cannot find your
> hostname, [xxx.xxx.xxx.xxx];

...

reject_unknown_client,<--- That's it

-- 
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  ralf.hildebra...@charite.de | http://www.charite.de

Gateway Spam Recipient Restrictions?

[Fire walls]

  Had been reading a postfix manuals and info from Internet.

  I'm running spam server with FreeBSD 8.2 + Postfix 2.8.x, single domain.

  Internet -->spam server--> mail server -->Internal Network.

  The gateway is working, but I still doing changes to block most of the
spam that touch my server, I'm working right now just with Postfix, latter I
will continue with clamais,amavis,sa.

  Now, I want to use the smtpd_recipient_restrictions -> reject_rbl_client
blackholes.

I want to enable zen spamhaus org

  But once I reload or restart Postfix, the function of this feature is to
check if the from is in the list right?

smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_invalid_hostname,
reject_non_fqdn_helo_hostname,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
check_recipient_access
pcre:/usr/local/etc/postfix/recipient_checks.pcre,
check_helo_access hash:/usr/local/etc/postfix/helo_checks,
check_sender_access hash:/usr/local/etc/postfix/sender_checks,
check_client_access hash:/usr/local/etc/postfix/client_checks,
reject_rbl_client zen spamhaus org,
check_policy_service inet:192 168 40 5:10023,
permit

But my log don't show any info about went postfix check spamhaus, my fw
won't show any blocks.

Next,for a gateway spam server, the _rbl_client is better to be in the
smtpd_recipients_restrictions?

Do I'm wrong or something is not working as desire?

Thanks for your time
-- 
:-)

Postfix 2.7.0 and yaa 0.3

[Peter L. Hansen]

Hi List,

Iam having trouble trying to adding autoreply/autoresponder/outofoffice 
functionality to our setup.


It seems that the best option is to use "yaa". Other suggestions are 
welcome.


I have a postfix setup with virtual users in mysql, and found followed 
the guide on

http://www.howtoforge.com/autoresponders_for_virtual_postfix_users

Added to master.cf:
yaa unix-   n   n   -   -   pipe
user=nobody

argv=/usr/local/postfix-tools/yaa-0.3/bin/yaa.pl


And a VirtualTransport for my autosponder domain to "yaa:" in mysql as 
usual.

Configured yaa.conf properly. (i can link to pastebin if needed).

But i fear that yaa is no longer compatible with postfix 2.7?

As my testing shows the following log:

Apr 26 11:08:23 mail03 postfix/smtpd[25357]: connect from 
localhost[127.0.0.1]
Apr 26 11:08:40 mail03 postfix/smtpd[25357]: 4772F18C080: 
client=localhost[127.0.0.1]
Apr 26 11:08:47 mail03 postfix/cleanup[25361]: 4772F18C080: 
message-id=<20110426090840.4772f18c...@mail03.tigermedia.eu>
Apr 26 11:08:47 mail03 postfix/qmgr[24596]: 4772F18C080: 
from=, size=374, nrcpt=2 (queue active)
Apr 26 11:08:47 mail03 postfix/virtual[25362]: 4772F18C080: 
to=, relay=virtual, delay=12, delays=12/0.02/0/0.02, 
dsn=2.0.0, status=sent (delivered to maildir)
Apr 26 11:08:47 mail03 yaa.pl[25364]: Warning: setting empty lookup 
query order for attribute 'rewrite_recipient'.
Apr 26 11:08:47 mail03 yaa.pl[25364]: Warning: setting empty lookup 
query order for attribute 'rewrite_sender'.
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Processing new request, 
id 5352879
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Warning: Your MTA does 
not provide Delivered-To header. Yaa will have to rely on message 
headers which are very easy to fake. You've been warned.
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Warning: Your MTA 
violates RFC 822 by not adding Return-Path header in message. Yaa will 
have to rely on message headers which are very easy to fake. You've been 
warned.
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Message sender: 
pe...@tigermedia.dk, recipients:

Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Processing complete.
Apr 26 11:08:47 mail03 postfix/pipe[25363]: 4772F18C080: 
to=, orig_to=, relay=yaa, 
delay=13, delays=12/0.02/0/0.23, dsn=2.0.0, status=sent (delivered via 
yaa service)

Apr 26 11:08:47 mail03 postfix/qmgr[24596]: 4772F18C080: removed
Apr 26 11:08:48 mail03 postfix/smtpd[25357]: disconnect from 
localhost[127.0.0.1]



My local fake domain is "autoresponder.dk" and testing with autoreply on 
pe...@r12.dk.


I see the two warnings, and fear that the warnings are the cause for no 
"recipients" in yaa?

Can i configure postfix to send the proper headers?


Thanks,
Peter Hansen

Re: Postfix 2.7.0 and yaa 0.3

[Michael Tokarev]

26.04.2011 13:28, Peter L. Hansen wrote:
> Hi List,
> 
> Iam having trouble trying to adding autoreply/autoresponder/outofoffice
> functionality to our setup.
> 
> It seems that the best option is to use "yaa". Other suggestions are
> welcome.
> 
> I have a postfix setup with virtual users in mysql, and found followed
> the guide on
> http://www.howtoforge.com/autoresponders_for_virtual_postfix_users
> 
> Added to master.cf:
> yaa unix-   n   n   -   -   pipe
> user=nobody
>
> argv=/usr/local/postfix-tools/yaa-0.3/bin/yaa.pl
> 
[]
> Apr 26 11:08:47 mail03 yaa.pl[25364]: Warning: setting empty lookup
> query order for attribute 'rewrite_recipient'.
> Apr 26 11:08:47 mail03 yaa.pl[25364]: Warning: setting empty lookup
> query order for attribute 'rewrite_sender'.
> Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Processing new request,
> id 5352879
> Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Warning: Your MTA does
> not provide Delivered-To header. Yaa will have to rely on message
> headers which are very easy to fake. You've been warned.
> Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Warning: Your MTA
> violates RFC 822 by not adding Return-Path header in message. Yaa will
> have to rely on message headers which are very easy to fake. You've been
> warned.


Please read the pipe(8) manpage, especially the "flags=.." section.

/mjt

Re: Postfix 2.7.0 and yaa 0.3

[Peter L. Hansen]

Hi Michael,

Thanks for the pointer. Much better now.

I got i working now .. somewhat.

It seems it will use my u...@fake.tld as the lookup key and as the 
sender of the reply.


According to the documentation
http://cml.dokuro.org/howto/yaa.txt

It should be alias_user@your_domain.tld instead of 
alias_user@reply.your_domain.tld (fake)



Example:

Apr 26 11:54:34 mail03 yaa.pl[28380]: 3019529: Processing new request, 
id 3019529
Apr 26 11:54:34 mail03 yaa.pl[28380]: 3019529: Message sender: 
pe...@tigermedia.dk, recipients: pe...@autoresponder.dk
Apr 26 11:54:34 mail03 yaa.pl[28380]: 3019529: Recipient 
pe...@autoresponder.dk has autoresponder turned on.
Apr 26 11:54:34 mail03 postfix/smtpd[28381]: connect from 
localhost[127.0.0.1]
Apr 26 11:54:34 mail03 postfix/smtpd[28381]: B208D18C081: 
client=localhost[127.0.0.1]
Apr 26 11:54:34 mail03 postfix/cleanup[28377]: B208D18C081: 
message-id=<1479391657.17787@mail03>
Apr 26 11:54:34 mail03 postfix/qmgr[28372]: B208D18C081: 
from=, size=658, nrcpt=1 (queue active)
Apr 26 11:54:34 mail03 postfix/smtpd[28381]: disconnect from 
localhost[127.0.0.1]
Apr 26 11:54:34 mail03 yaa.pl[28380]: 3019529: Successfuly sent 
autoresponse from pe...@autoresponder.dk to pe...@tigermedia.dk.

Apr 26 11:54:34 mail03 yaa.pl[28380]: 3019529: Processing complete.
Apr 26 11:54:34 mail03 postfix/pipe[28379]: 6259018C080: 
to=, orig_to=, relay=yaa, 
delay=12, delays=11/0.03/0/0.41, dsn=2.0.0, status=sent (delivered via 
yaa service)




I know that, maybe this is yaa specific..
I cant see why the recipient is pe...@autoresponder.dk (fake tld) 
instead of pe...@r12.dk (the real email)?


Any help is appreciated

/ Peter




Den 26-04-2011 11:36, Michael Tokarev skrev:

26.04.2011 13:28, Peter L. Hansen wrote:

Hi List,

Iam having trouble trying to adding autoreply/autoresponder/outofoffice
functionality to our setup.

It seems that the best option is to use "yaa". Other suggestions are
welcome.

I have a postfix setup with virtual users in mysql, and found followed
the guide on
http://www.howtoforge.com/autoresponders_for_virtual_postfix_users

Added to master.cf:
yaa unix-   n   n   -   -   pipe
 user=nobody

argv=/usr/local/postfix-tools/yaa-0.3/bin/yaa.pl


[]

Apr 26 11:08:47 mail03 yaa.pl[25364]: Warning: setting empty lookup
query order for attribute 'rewrite_recipient'.
Apr 26 11:08:47 mail03 yaa.pl[25364]: Warning: setting empty lookup
query order for attribute 'rewrite_sender'.
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Processing new request,
id 5352879
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Warning: Your MTA does
not provide Delivered-To header. Yaa will have to rely on message
headers which are very easy to fake. You've been warned.
Apr 26 11:08:47 mail03 yaa.pl[25364]: 5352879: Warning: Your MTA
violates RFC 822 by not adding Return-Path header in message. Yaa will
have to rely on message headers which are very easy to fake. You've been
warned.


Please read the pipe(8) manpage, especially the "flags=.." section.

/mjt

Re: Make local tempfail when LDAP is down

[jeffrey j donovan]

On Apr 25, 2011, at 10:22 PM, William Ono wrote:

> Hello all,
> 
> Yes, this again. I promise it's slightly different this time.
> 
> I have users in LDAP and they're brought in as local users by
> libnss-ldapd. With local_recipient_maps set to use a LDAP map instead of
> unix:passwd.byname, smtpd correctly tempfails incoming mail when the
> LDAP service is unavailable. This is all working fine.
> 
> However, for mail that originates on the mail host, e.g. by mail(1),
> when an LDAP outage causes local users to disappear (getent passwd
> username returns no results with exit code 2) local bounces the mail as
> user unknown. While this is not surprising behaviour, it is not the
> desired behaviour, either.
> 
> I was hoping that setting mailbox_transport_maps to the same LDAP map as
> local_recipient_maps would cause local to tempfail rather than bounce in
> this case. It turns out that it does not.
> 
> Digging into the code, in deliver_mailbox() I see a call to maps_find()
> that isn't followed by a check on dict_errno. I think this is a bug. If
> maps_find() sets dict_errno to DICT_ERR_RETRY, deliver_mailbox() should
> fail the delivery and expect a retry later. But my C is very rusty and
> this is not trivial code so I haven't gotten any further than that.
> 
> local/mailbox.c:280 in deliver_mailbox():
> 
>/* The -1 is a hint for the down-stream deliver_completed() function. */
>if (*var_mbox_transp_maps
>&& (map_transport = maps_find(transp_maps, state.msg_attr.user,
>  DICT_FLAG_NONE)) != 0) {
>state.msg_attr.rcpt.offset = -1L;
>*statusp = deliver_pass(MAIL_CLASS_PRIVATE, map_transport,
>state.request, &state.msg_attr.rcpt);
>return (YES);
>}
>if (*var_mailbox_transport) {
>...
> 
> Is there a better way to do what I'm trying to do, which is to tempfail
> instead of bounce when LDAP/NSS is not working correctly? (I appreciate
> that it's not Postfix's fault that NSS isn't distinguishing not found
> from an error, but that doesn't help me get this working.)
> 
> If you're curious, nscd is not a complete solution here (though I am using
> it) because, after a cold start, it's likely that Postfix on one host will
> come up before the LDAP service on another host. They're both virtual
> machines on the same hardware. It's not ideal but this is too small of a
> shop to do anything bigger than that.
> 
> Thanks.
> 

greetings

for ldap transport I added an ldap attribute " mailHost " then did my transport 
map based on the entry

transport_maps = ldap:/etc/postfix/primary_transport, 
ldap:/etc/postfix/secondary_transport

server_host = 10.1.1.15 
search_base = dc=myldapserver,dc=my,dc=domain,dc=com
query_filter = (mail=%s)
result_attribute = mailHost
result_filter = smtp:[%s]
bind = no

Re: Make local tempfail when LDAP is down

[Wietse Venema]

William Ono:
> Hello all,
> 
> Yes, this again. I promise it's slightly different this time.
> 
> I have users in LDAP and they're brought in as local users by
> libnss-ldapd. With local_recipient_maps set to use a LDAP map instead of
> unix:passwd.byname, smtpd correctly tempfails incoming mail when the
> LDAP service is unavailable. This is all working fine.

That is because the POSTFIX LDAP client queries the LDAP server.
The POSTFIX LDAP client works correctly: when the LDAP server fails
to respond, the POSTFIX LDAP client returns a temporary error.

> However, for mail that originates on the mail host, e.g. by mail(1),
> when an LDAP outage causes local users to disappear (getent passwd
> username returns no results with exit code 2) local bounces the mail as
> user unknown. While this is not surprising behaviour, it is not the
> desired behaviour, either.

This is a bug in the SYSTEM NSS LDAP client. The SYSTEM NSS LDAP
client works incorrectly: when the LDAP server fails to respond,
the SYSTEM NSS LDAP client returns a NOTFOUND result.

Go file a bug report with your operating system vendor. This bug
has been around forever, and unless someone pulls the hands from
under their buttocks and fixes this, the bug will make life miserable
for generations of mail admins.

Wietse

Re: all header_checks works with postmap -q, but not all work when processing actual mail

[b...@bitrate.net]

On 2011.04.25 14.41, mouss wrote:

you are not testing the same data. you test a "pcre" file, but your
postfix uses two regexp files.


sigh.  that was it, thank you.  same problem as my last question, all over 
again.  i switched to pcre, but neglected to update main.cf to reflect that.

Re: Gateway Spam Recipient Restrictions?

[Noel Jones]

On 4/26/2011 3:00 AM, Fire walls wrote:


   Had been reading a postfix manuals and info from Internet.

   I'm running spam server with FreeBSD 8.2 + Postfix 2.8.x,
single domain.

   Internet -->spam server--> mail server -->Internal Network.

   The gateway is working, but I still doing changes to block
most of the spam that touch my server, I'm working right now
just with Postfix, latter I will continue with clamais,amavis,sa.

   Now, I want to use the smtpd_recipient_restrictions ->
reject_rbl_client blackholes.

I want to enable zen spamhaus org

   But once I reload or restart Postfix, the function of this
feature is to check if the from is in the list right?

smtpd_recipient_restrictions =
 permit_mynetworks,
 reject_unauth_destination,
 reject_non_fqdn_hostname,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_invalid_hostname,
 reject_non_fqdn_helo_hostname,
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,
 check_recipient_access
pcre:/usr/local/etc/postfix/recipient_checks.pcre,
 check_helo_access
hash:/usr/local/etc/postfix/helo_checks,
 check_sender_access
hash:/usr/local/etc/postfix/sender_checks,
 check_client_access
hash:/usr/local/etc/postfix/client_checks,
 reject_rbl_client zen spamhaus org,


It must have periods in it,
 reject_rbl_client zen.spamhaus.org

Without the periods it will create an error in your maillog. 
If there is no error, then either this isn't the config you're 
really using, or one of your earlier rules is returning OK or 
permit.




 check_policy_service inet:192 168 40 5:10023,


Does this policy service work as expected?  It doesn't have 
any periods in the IP address and should also generate an error.



 permit

But my log don't show any info about went postfix check
spamhaus, my fw won't show any blocks.


Next time show us "postconf -n" output rather than random 
snippings.


Enable query logging in your DNS server to see if spamhaus.org 
lookups are being performed.




Next,for a gateway spam server, the _rbl_client is better to
be in the smtpd_recipients_restrictions?


Most people put it in smtpd_recipient_restrictions, just after 
reject_unauth_destination and an optional check_client_access 
whitelist.


smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unauth_destination
# uncomment next line if you need a client whitelist
# check_client_access cidr:/etc/postfix/client_whitelist.cidr
  reject_rbl_client zen.spamhaus.org
  ... other local restrictions ...


where the optional client_whitelist contains IPs of clients 
you want mail from that might otherwise be rejected by zen (or 
other local rules).



  -- Noel Jones

Not Using reverse DNS

[Dan Lists]

I am seeing the following in my logs:

Apr 26 10:18:43 mailhost postfix/smtpd[46627]: connect from
unknown[98.118.152.26]

However, the IP does resolve:

mailhost # host 98.118.152.26
26.152.118.98.in-addr.arpa domain name pointer onlinecourseevaluations.com.

mailhost # host onlinecourseevaluations.com
onlinecourseevaluations.com has address 98.118.152.28
onlinecourseevaluations.com mail is handled by 10 aspmx4.googlemail.com.
onlinecourseevaluations.com mail is handled by 10 aspmx5.googlemail.com.
onlinecourseevaluations.com mail is handled by 2 aspmx.l.google.com.
onlinecourseevaluations.com mail is handled by 5 alt1.aspmx.l.google.com.
onlinecourseevaluations.com mail is handled by 5 alt2.aspmx.l.google.com.
onlinecourseevaluations.com mail is handled by 10 aspmx2.googlemail.com.
onlinecourseevaluations.com mail is handled by 10 aspmx3.googlemail.com.

Why isn't postfix using the hostname returned by the reverse DNS
lookup?  Is it because the forward and reverse DNS do not match?  I
thought I've seen cases where forward and reverse did not match but it
still showed a hostname for the client.

I've checked google and the mailing list archives, and none of the
things I saw apply here.  I am not in a chroot environment, and I am
running a local caching DNS server.  This is happening across a
cluster of 5 servers, and the load is fine on all the servers.  Other
clients are resolving as expected.

Thanks for your input,

Dan

Re: Make local tempfail when LDAP is down

[William Ono]

On Tue, Apr 26, 2011 at 08:44:05AM -0400, Wietse Venema wrote:
> That is because the POSTFIX LDAP client queries the LDAP server.
> The POSTFIX LDAP client works correctly: when the LDAP server fails
> to respond, the POSTFIX LDAP client returns a temporary error.
> 
> > However, for mail that originates on the mail host, e.g. by mail(1),
> > when an LDAP outage causes local users to disappear (getent passwd
> > username returns no results with exit code 2) local bounces the mail as
> > user unknown. While this is not surprising behaviour, it is not the
> > desired behaviour, either.
> 
> This is a bug in the SYSTEM NSS LDAP client. The SYSTEM NSS LDAP
> client works incorrectly: when the LDAP server fails to respond,
> the SYSTEM NSS LDAP client returns a NOTFOUND result.

Yes, exactly so, as I acknowledged further down. However, continuing
from my original email:

> > I was hoping that setting mailbox_transport_maps to the same LDAP map as
> > local_recipient_maps would cause local to tempfail rather than bounce in
> > this case. It turns out that it does not.

So, no, the local(8) LDAP client does NOT work correctly.

-- 
William Ono 

Re: Not Using reverse DNS

[/dev/rob0]

On Tue, Apr 26, 2011 at 10:49:03AM -0500, Dan Lists wrote:
> I am seeing the following in my logs:
> 
> Apr 26 10:18:43 mailhost postfix/smtpd[46627]: connect from
> unknown[98.118.152.26]
> 
> However, the IP does resolve:
> 
> mailhost # host 98.118.152.26
> 26.152.118.98.in-addr.arpa domain name pointer onlinecourseevaluations.com.
> 
> mailhost # host onlinecourseevaluations.com
> onlinecourseevaluations.com has address 98.118.152.28

26 != 28

> Why isn't postfix using the hostname returned by the reverse DNS
> lookup?  Is it because the forward and reverse DNS do not match?  I

Yes.

> thought I've seen cases where forward and reverse did not match but 
> it still showed a hostname for the client.

No.
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Re: Gateway Spam Recipient Restrictions?

[Fire walls]

On Tue, Apr 26, 2011 at 6:16 AM, Noel Jones  wrote:

> On 4/26/2011 3:00 AM, Fire walls wrote:
>
>>
>>   Had been reading a postfix manuals and info from Internet.
>>
>>   I'm running spam server with FreeBSD 8.2 + Postfix 2.8.x,
>> single domain.
>>
>>   Internet -->spam server--> mail server -->Internal Network.
>>
>>   The gateway is working, but I still doing changes to block
>> most of the spam that touch my server, I'm working right now
>> just with Postfix, latter I will continue with clamais,amavis,sa.
>>
>>   Now, I want to use the smtpd_recipient_restrictions ->
>> reject_rbl_client blackholes.
>>
>> I want to enable zen spamhaus org
>>
>>   But once I reload or restart Postfix, the function of this
>> feature is to check if the from is in the list right?
>>
>> smtpd_recipient_restrictions =
>> permit_mynetworks,
>> reject_unauth_destination,
>> reject_non_fqdn_hostname,
>> reject_non_fqdn_sender,
>> reject_non_fqdn_recipient,
>> reject_invalid_hostname,
>> reject_non_fqdn_helo_hostname,
>> reject_unknown_sender_domain,
>> reject_unknown_recipient_domain,
>> check_recipient_access
>> pcre:/usr/local/etc/postfix/recipient_checks.pcre,
>> check_helo_access
>> hash:/usr/local/etc/postfix/helo_checks,
>> check_sender_access
>> hash:/usr/local/etc/postfix/sender_checks,
>> check_client_access
>> hash:/usr/local/etc/postfix/client_checks,
>> reject_rbl_client zen spamhaus org,
>>
>
> It must have periods in it,
>
> reject_rbl_client zen.spamhaus.org
>
> Without the periods it will create an error in your maillog. If there is no
> error, then either this isn't the config you're really using, or one of your
> earlier rules is returning OK or permit.
>
> My settings  have period,I just remove from here,sorry:

reject_rbl_client zen.spamhaus.org
check_policy_service inet:192.168.40.5:10023

>
>
>  check_policy_service inet:192 168 40 5:10023,
>>
>
> Does this policy service work as expected?  It doesn't have any periods in
> the IP address and should also generate an error.
>
> Yes,works.


>  permit
>>
>> But my log don't show any info about went postfix check
>> spamhaus, my fw won't show any blocks.
>>
>
> Next time show us "postconf -n" output rather than random snippings.
>
> Enable query logging in your DNS server to see if spamhaus.org lookups are
> being performed.
>
>
> If I test the domain in my dns server an resolve without issue.

dig spamhaus.org


>
>> Next,for a gateway spam server, the _rbl_client is better to
>> be in the smtpd_recipients_restrictions?
>>
>
> Most people put it in smtpd_recipient_restrictions, just after
> reject_unauth_destination and an optional check_client_access whitelist.
>
>
> smtpd_recipient_restrictions =
>  permit_mynetworks
>  reject_unauth_destination
> # uncomment next line if you need a client whitelist
> # check_client_access cidr:/etc/postfix/client_whitelist.cidr
>
>  reject_rbl_client zen.spamhaus.org
>  ... other local restrictions ...
>
>
> where the optional client_whitelist contains IPs of clients you want mail
> from that might otherwise be rejected by zen (or other local rules).
>
>
>  -- Noel Jones
>

I want to add, that I can receive mails from know outside users and they
pass all the rules but never see my server check the spamhaus.org or my
default log level won't show them?

Peter I will remove some checks, I have a lot.

Thanks!!!

-- 
:-)

Re: (WTF) Re: Increase the speed of mails sending in postfix.

[Lorens Kockum]

On Mon, Apr 25, 2011 at 12:23:13PM +0200, Reindl Harald wrote:
> as long as you starting threads with single liners like
> 
> * How can I send 10 mails using postfix in 5 minutes
> * How can I increase mail sending speed in postfix

He's been asking the same question since April 5th. Each time he
got a selection of good answers; helpful, detailed, polite. I
don't think there's any more anyone can do except trade money
for time. Unless he's a spammer, of course, in which case one's
imagination is the only limit.

Stop sending, yet allow queuing of messages

[Jeff Bernier]

Hello,

I have looked for, but cannot find help on doing the following:

I would like to temporarily stop Postfix from sending queued messages, but
allow it to continue queuing additional new messages, also to be temporarily
held.

My goal is to be able to watch the mail queue fill up with messages for a
time. Is this possible?

Thanks,
Jeff

Re: Stop sending, yet allow queuing of messages

[/dev/rob0]

On Tue, Apr 26, 2011 at 01:24:06PM -0400, Jeff Bernier wrote:
> I have looked for, but cannot find help on doing the following:
> 
> I would like to temporarily stop Postfix from sending queued 
> messages, but allow it to continue queuing additional new messages, 
> also to be temporarily held.
> 
> My goal is to be able to watch the mail queue fill up with messages 
> for a time. Is this possible?

defer_transports = smtp
and add others as desired or dictated by your configuration.

http://www.postfix.org/postconf.5.html#defer_transports
-- 
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header

Postfix w/TLS, virtual domain, non-unix account

[Mike]

I've got postfix working with TLS in a virtual domain configuration.
The postfix server is accepting mail with no problems; per log:

Apr 26 06:05:23 sato postfix/smtpd[26962]: connect from
mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:05:23 sato postfix/smtpd[26962]: setting up TLS connection
from mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:05:23 sato postfix/smtpd[26962]:
mail-iy0-f180.google.com[209.85.210.180]: TLS cipher list
"ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5"
Apr 26 06:05:23 sato postfix/smtpd[26962]: SSL_accept:before/accept
initialization
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 read client hello A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write server hello A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write certificate A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write server done A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 flush data
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 read
client key exchange A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 read finished A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write
change cipher spec A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 write finished A
Apr 26 06:05:24 sato postfix/smtpd[26962]: SSL_accept:SSLv3 flush data
Apr 26 06:05:24 sato postfix/smtpd[26962]:
mail-iy0-f180.google.com[209.85.210.180]: save session
E5A2DA12F11C1EA1AB910C8F09FB58861FF2A0=smtp to smtpd cache
Apr 26 06:05:24 sato postfix/tlsmgr[26964]: put smtpd session
id=E5A2DA12F11C1EA1AB910C8F09FB58861FF2A0=smtp [data 127 bytes]
Apr 26 06:05:24 sato postfix/tlsmgr[26964]: write smtpd TLS cache
entry E5A2DA12F11C1EA1AB910C8F09FB58861FF2A0=smtp: time=1303812324
[data 127 bytes]
Apr 26 06:05:24 sato postfix/smtpd[26962]: Anonymous TLS connection
established from mail-iy0-f180.google.com[209.85.210.180]: TLSv1 with
cipher AES128-SHA (128/128 bits)
Apr 26 06:05:24 sato postfix/smtpd[26962]: 80D101840715:
client=mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:05:24 sato postfix/cleanup[26967]: 80D101840715:
message-id=
Apr 26 06:05:24 sato postfix/qmgr[26958]: 80D101840715:
from=, size=1564, nrcpt=1 (queue active)
Apr 26 06:05:24 sato postfix/virtual[26968]: 80D101840715:
to=, relay=virtual, delay=0.36,
delays=0.28/0.04/0/0.05, dsn=2.0.0, status=sent (delivered to maildir)
Apr 26 06:05:24 sato postfix/qmgr[26958]: 80D101840715: removed
Apr 26 06:05:54 sato postfix/smtpd[26962]: disconnect from
mail-iy0-f180.google.com[209.85.210.180]
Apr 26 06:09:14 sato postfix/anvil[26965]: statistics: max connection
rate 1/60s for (smtp:209.85.210.180) at Apr 26 06:05:23
Apr 26 06:09:14 sato postfix/anvil[26965]: statistics: max connection
count 1 for (smtp:209.85.210.180) at Apr 26 06:05:23
Apr 26 06:09:14 sato postfix/anvil[26965]: statistics: max cache size
1 at Apr 26 06:05:23


I now want to connect to postfix server and try to send email.
Using Thunderbird 3.1 email client and adding u...@example.com account.
Tbird tries to auto-configure the connection to the mail server. It
appears to "find" or connect to the smtp outgoing server, but the
incoming server fails. I've tried many different settings for the
incoming server: pop, imap, ports 110,143,587,993,995; I've tried
addressing the incoming server as mail.example.com, example.com, etc.
Everything has failed thus far.

I've been reviewing the postfix TLS and basic configuration docs., but
I'm not progressing.
Looking for guidance how to properly connect an email client to the
postfix server.

postconf -n output:

command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
html_directory = /usr/doc/postfix-2.6.1/html
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/man
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = /usr/doc/postfix-2.6.1/README_FILES
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/postfix/mycert.pem
smtpd_tls_key_file = $smtpd_tls_cert_file
smtpd_tls_loglevel = 2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5
smtpd_tls_mandatory_protocols = TLSv1
smtpd_tls_security_level = encrypt
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_tls_session_cache_timeout = 7200s
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual
virtual_gid_maps = static:2000
virtual_mailbox_base = /var/mail/vmailbox
virtual_mailbox_domains = example.com
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 100
virtual_uid_maps = static:2000

Re: Postfix w/TLS, virtual domain, non-unix account

[Victor Duchovni]

On Tue, Apr 26, 2011 at 01:37:16PM -0400, Mike wrote:

> I've got postfix working with TLS in a virtual domain configuration.
> The postfix server is accepting mail with no problems; per log:
> 
> Apr 26 06:05:23 sato postfix/smtpd[26962]: connect from
> mail-iy0-f180.google.com[209.85.210.180]
> Apr 26 06:05:23 sato postfix/smtpd[26962]: setting up TLS connection
> from mail-iy0-f180.google.com[209.85.210.180]
> Apr 26 06:05:23 sato postfix/smtpd[26962]:
> mail-iy0-f180.google.com[209.85.210.180]: TLS cipher list
> "ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH:!aNULL:!MD5"
> [...]

Your TLS loglevel is too high.

> Apr 26 06:05:24 sato postfix/smtpd[26962]: Anonymous TLS connection
> established from mail-iy0-f180.google.com[209.85.210.180]: TLSv1 with
> cipher AES128-SHA (128/128 bits)

This is all that would be logged with "smtpd_tls_loglevel = 1", and it
is quite sufficient.

> I now want to connect to postfix server and try to send email.
> Using Thunderbird 3.1 email client and adding u...@example.com account.
> Tbird tries to auto-configure the connection to the mail server. It
> appears to "find" or connect to the smtp outgoing server, but the
> incoming server fails. I've tried many different settings for the
> incoming server: pop, imap, ports 110,143,587,993,995; I've tried
> addressing the incoming server as mail.example.com, example.com, etc.
> Everything has failed thus far.

Postfix is not a POP or IMAP server. Try dovecot, or similar.

-- 
Viktor.

Re: Postfix w/TLS, virtual domain, non-unix account

[Mike]

On Tue, Apr 26, 2011 at 1:58 PM, Victor Duchovni
 wrote:
>
> This is all that would be logged with "smtpd_tls_loglevel = 1", and it
> is quite sufficient.

Excellent, will do and thanks for letting me know I'm now ready to
configure an imap server.

Mike

Re: Make local tempfail when LDAP is down

[Wietse Venema]

William Ono:
> On Tue, Apr 26, 2011 at 08:44:05AM -0400, Wietse Venema wrote:
> > That is because the POSTFIX LDAP client queries the LDAP server.
> > The POSTFIX LDAP client works correctly: when the LDAP server fails
> > to respond, the POSTFIX LDAP client returns a temporary error.
> > 
> > > However, for mail that originates on the mail host, e.g. by mail(1),
> > > when an LDAP outage causes local users to disappear (getent passwd
> > > username returns no results with exit code 2) local bounces the mail as
> > > user unknown. While this is not surprising behaviour, it is not the
> > > desired behaviour, either.
> > 
> > This is a bug in the SYSTEM NSS LDAP client. The SYSTEM NSS LDAP
> > client works incorrectly: when the LDAP server fails to respond,
> > the SYSTEM NSS LDAP client returns a NOTFOUND result.
> 
> Yes, exactly so, as I acknowledged further down. However, continuing
> from my original email:
> 
> > > I was hoping that setting mailbox_transport_maps to the same LDAP map as
> > > local_recipient_maps would cause local to tempfail rather than bounce in
> > > this case. It turns out that it does not.
> 
> So, no, the local(8) LDAP client does NOT work correctly.

The LDAP client is OK, but the mailbox_transport_maps code is not.

Wietse

Re: Postfix 2.7.0 and yaa 0.3

[fakessh]

Le mardi 26 avril 2011 11:28, Peter L. Hansen a écrit :
> Hi List,
>
> Iam having trouble trying to adding autoreply/autoresponder/outofoffice
> functionality to our setup.
>

me i use sieve

> Can i configure postfix to send the proper headers?
>
>
> Thanks,
> Peter Hansen

-- 
 http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x092164A7
 gpg --keyserver pgp.mit.edu --recv-key 092164A7


pgp94Ff9DYJyg.pgp
Description: PGP signature

Re: Gateway Spam Recipient Restrictions?

[Noel Jones]

On 4/26/2011 11:51 AM, Fire walls wrote:

On Tue, Apr 26, 2011 at 6:16 AM, Noel Jones
mailto:njo...@megan.vbhcs.org>> wrote:

On 4/26/2011 3:00 AM, Fire walls wrote:


   Had been reading a postfix manuals and info from
Internet.

   I'm running spam server with FreeBSD 8.2 + Postfix
2.8.x,
single domain.

   Internet -->spam server--> mail server -->Internal
Network.

   The gateway is working, but I still doing changes
to block
most of the spam that touch my server, I'm working
right now
just with Postfix, latter I will continue with
clamais,amavis,sa.

   Now, I want to use the smtpd_recipient_restrictions ->
reject_rbl_client blackholes.

I want to enable zen spamhaus org

   But once I reload or restart Postfix, the function
of this
feature is to check if the from is in the list right?

smtpd_recipient_restrictions =
 permit_mynetworks,
 reject_unauth_destination,
 reject_non_fqdn_hostname,
 reject_non_fqdn_sender,
 reject_non_fqdn_recipient,
 reject_invalid_hostname,
 reject_non_fqdn_helo_hostname,
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,
 check_recipient_access
pcre:/usr/local/etc/postfix/recipient_checks.pcre,
 check_helo_access
hash:/usr/local/etc/postfix/helo_checks,
 check_sender_access
hash:/usr/local/etc/postfix/sender_checks,
 check_client_access
hash:/usr/local/etc/postfix/client_checks,
 reject_rbl_client zen spamhaus org,


It must have periods in it,

 reject_rbl_client zen.spamhaus.org


Without the periods it will create an error in your
maillog. If there is no error, then either this isn't the
config you're really using, or one of your earlier rules
is returning OK or permit.

My settings  have period,I just remove from here,sorry:

reject_rbl_client zen.spamhaus.org 
check_policy_service inet:192.168.40.5:10023




 check_policy_service inet:192 168 40 5:10023,


Does this policy service work as expected?  It doesn't
have any periods in the IP address and should also
generate an error.

Yes,works.


 permit

But my log don't show any info about went postfix check
spamhaus, my fw won't show any blocks.


Next time show us "postconf -n" output rather than random
snippings.

Enable query logging in your DNS server to see if
spamhaus.org  lookups are being
performed.


If I test the domain in my dns server an resolve without issue.

dig spamhaus.org 


Next,for a gateway spam server, the _rbl_client is
better to
be in the smtpd_recipients_restrictions?


Most people put it in smtpd_recipient_restrictions, just
after reject_unauth_destination and an optional
check_client_access whitelist.


smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unauth_destination
# uncomment next line if you need a client whitelist
# check_client_access cidr:/etc/postfix/client_whitelist.cidr

  reject_rbl_client zen.spamhaus.org 
  ... other local restrictions ...


where the optional client_whitelist contains IPs of
clients you want mail from that might otherwise be
rejected by zen (or other local rules).


  -- Noel Jones


I want to add, that I can receive mails from know outside
users and they pass all the rules but never see my server
check the spamhaus.org  or my default log
level won't show them?

Peter I will remove some checks, I have a lot.

Thanks!!!

--
:-)


Postfix does not log successful rbl checks.  The spamhaus site 
describes the procedure to check their service using dig or 
host.  Turn on query logging in your DNS server to verify that 
postfix is performing the rbl lookups.


If you have more questions, don't waste your and others time 
posting inaccurate and incomplete information.

http://www.postfix.org/DEBUG_README.html#mail


  -- Noel Jones

Re: Gateway Spam Recipient Restrictions?

[Fire walls]

On Tue, Apr 26, 2011 at 11:43 AM, Noel Jones  wrote:

> On 4/26/2011 11:51 AM, Fire walls wrote:
>
>> On Tue, Apr 26, 2011 at 6:16 AM, Noel Jones
>> mailto:njo...@megan.vbhcs.org>> wrote:
>>
>>On 4/26/2011 3:00 AM, Fire walls wrote:
>>
>>
>>   Had been reading a postfix manuals and info from
>>Internet.
>>
>>   I'm running spam server with FreeBSD 8.2 + Postfix
>>2.8.x,
>>single domain.
>>
>>   Internet -->spam server--> mail server -->Internal
>>Network.
>>
>>   The gateway is working, but I still doing changes
>>to block
>>most of the spam that touch my server, I'm working
>>right now
>>just with Postfix, latter I will continue with
>>clamais,amavis,sa.
>>
>>   Now, I want to use the smtpd_recipient_restrictions ->
>>reject_rbl_client blackholes.
>>
>>I want to enable zen spamhaus org
>>
>>   But once I reload or restart Postfix, the function
>>of this
>>feature is to check if the from is in the list right?
>>
>>smtpd_recipient_restrictions =
>> permit_mynetworks,
>> reject_unauth_destination,
>> reject_non_fqdn_hostname,
>> reject_non_fqdn_sender,
>> reject_non_fqdn_recipient,
>> reject_invalid_hostname,
>> reject_non_fqdn_helo_hostname,
>> reject_unknown_sender_domain,
>> reject_unknown_recipient_domain,
>> check_recipient_access
>>pcre:/usr/local/etc/postfix/recipient_checks.pcre,
>> check_helo_access
>>hash:/usr/local/etc/postfix/helo_checks,
>> check_sender_access
>>hash:/usr/local/etc/postfix/sender_checks,
>> check_client_access
>>hash:/usr/local/etc/postfix/client_checks,
>> reject_rbl_client zen spamhaus org,
>>
>>
>>It must have periods in it,
>>
>> reject_rbl_client zen.spamhaus.org
>>
>>
>>
>>Without the periods it will create an error in your
>>maillog. If there is no error, then either this isn't the
>>config you're really using, or one of your earlier rules
>>is returning OK or permit.
>>
>> My settings  have period,I just remove from here,sorry:
>>
>> reject_rbl_client zen.spamhaus.org 
>>
>> check_policy_service inet:192.168.40.5:10023
>> 
>>
>>
>>
>>
>> check_policy_service inet:192 168 40 5:10023,
>>
>>
>>Does this policy service work as expected?  It doesn't
>>have any periods in the IP address and should also
>>generate an error.
>>
>> Yes,works.
>>
>>
>> permit
>>
>>But my log don't show any info about went postfix check
>>spamhaus, my fw won't show any blocks.
>>
>>
>>Next time show us "postconf -n" output rather than random
>>snippings.
>>
>>Enable query logging in your DNS server to see if
>>spamhaus.org  lookups are being
>>
>>performed.
>>
>>
>> If I test the domain in my dns server an resolve without issue.
>>
>> dig spamhaus.org 
>>
>>
>>
>>Next,for a gateway spam server, the _rbl_client is
>>better to
>>be in the smtpd_recipients_restrictions?
>>
>>
>>Most people put it in smtpd_recipient_restrictions, just
>>after reject_unauth_destination and an optional
>>check_client_access whitelist.
>>
>>
>>smtpd_recipient_restrictions =
>>  permit_mynetworks
>>  reject_unauth_destination
>># uncomment next line if you need a client whitelist
>># check_client_access cidr:/etc/postfix/client_whitelist.cidr
>>
>>  reject_rbl_client zen.spamhaus.org 
>>
>>  ... other local restrictions ...
>>
>>
>>where the optional client_whitelist contains IPs of
>>clients you want mail from that might otherwise be
>>rejected by zen (or other local rules).
>>
>>
>>  -- Noel Jones
>>
>>
>> I want to add, that I can receive mails from know outside
>> users and they pass all the rules but never see my server
>> check the spamhaus.org  or my default log
>>
>> level won't show them?
>>
>> Peter I will remove some checks, I have a lot.
>>
>> Thanks!!!
>>
>> --
>> :-)
>>
>
> Postfix does not log successful rbl checks.  The spamhaus site describes
> the procedure to check their service using dig or host.  Turn on query
> logging in your DNS server to verify that postfix is performing the rbl
> lookups.
>
> If you have more questions, don't waste your and others time posting
> inaccurate and incomplete information.
> http://www.postfix.org/DEBUG_README.html#mail
>
>
>  -- Noel Jones
>


  Sorry Sr.

-- 
:-)

Re: ldap transport lookups: any holes in my solution?

[John Baker]

On 04/25/2011 10:59 AM, Victor Duchovni wrote:

On Thu, Apr 21, 2011 at 02:59:27PM -0400, John Baker wrote:


There are several ways to make this work right including virtual aliases
but the cleanest way seemed to me to be a per user transport map lookups
for cloud users.

I think that per-user transport lookups are unwise.


Hi,

Thanks for the reply, could you tell me why per-user transports are 
unwise? Do they not scale well?  Our numbers are fairly low.

 - Map each user's primary email address to a "mailbox" address
   for delivery.

 - Use a different "mailbox domain" for different hosting environments.

 - If absolutely necessary (the destination only supports the primary
   address), reverse the mapping via smtp_generic_maps in the master.cf
   entry for the transport feeding the problem destination.

We only host one domain with a few thousand accounts and less than 1,000 
really active at any given time so I wonder if this would be overkill. 
Until now with our limited number of users we have had one final 
destination on a Linux machine with three other gateway servers existing 
to load balance spam checking and avoid congestion. Without spam and 
virus checking one simple machine would do.


I probably should have been clearer about this but people want Google 
Apps since it's all the rage in Education now. I , for various reasons, 
have been skeptical of the free lunch and am proceeding with caution and 
moving slowly. Their recommended method for the transition is a "domain 
alias" that would be a completely virtual domain that only exists behind 
the scenes on servers to transport mail.  It looked to me like that was 
recommended because it's easy though not necessarily simple to setup. My 
boss wanted to do this with per-user mappings in /etc/alias on the 
current final destination to redirect mail to the google cloud. I didn't 
like that for a lot of reasons. As we were moving to ldap for alias and 
group mail checking anyhow the next step up from that was to use 
virtual_alias_maps to look to ldap and see if user had the apps domain 
for a final destination. In either of these aliases rewrite the address 
to match the "domain alias" that then has the appropriate next hop 
listed in the transport table. But I thought why not use the transport 
table mechanism to make a transport decision rather then add mechanisms 
for a virtual domain? It seemed cleaner particularly since we are not 
sure yet if we are in the long term transitioning or augmenting with a 
second possible final destination.


So guess the real question is if it's better for postfix to use an ldap 
lookup to decide the next hop and final destination with transport or to 
use setting like virtual_alias_maps or virtual_mailbox_domains to 
rewrite address after an ldap lookup to see whether or not the user is 
using Apps for Education to get their mail.

But we only have two possible final destinations and don't
want to end up with really large transport tables on different servers.

Your per-user primary ->  mailbox tables will be identical everywhere. The
transport mappings for the various "mailbox domains" may need to be
server-specific in some cases, but often do not. All each server needs to
know is which if any of the domains in question are its responsibility
(mydestination or virtual_mailbox_domains) and which are remote
(relay_domains). Then just define "relay_transport" and "virtual_transport"
appropriately.


We
also split our local and external smtp to reduce spam scan related
congestion so the next hop to the cloud is different depending in where the
mail is coming from. So I wanted a way to do one simple ldap look up that
would mean something different depending on the server.

Being too clever is often not a good idea, instead deploy the appropriate
table definition to the appropriate nodes.


query_filter = (uid=%u)
result_attribute = mailHost
result_format = smtp:[%s]

This can be a transport table for remote users, provided local users
never have "mailHost" set, but this fails badly when the same LDAP data
needs to work on the mailHost machine.


This seems to work great on my  test server. If the query filter is true it
delivers it to the next hop in the result_format and goes on to the domain
defaults in my regular transport file if not. I like this a lot because it
is very simple and uses an ldap attribute that can be multipurpose and the
same for every cloud user or mail server.

But as this seemed like an unintended use of result_format I wanted to be
sure that it won't cause any side effects before I put it into production.

Fixed result formats are intentionally supported.

Fixed "query_filter" values generate a warning that you probably are
not doing the right thing.




--
John Baker
Network Administrator
Marlboro College
Phone: 451-7551 Cell: 451-6748

Re: ldap transport lookups: any holes in my solution?

[Victor Duchovni]

On Tue, Apr 26, 2011 at 03:59:13PM -0400, John Baker wrote:

> On 04/25/2011 10:59 AM, Victor Duchovni wrote:
>> On Thu, Apr 21, 2011 at 02:59:27PM -0400, John Baker wrote:
>>
>>> There are several ways to make this work right including virtual aliases
>>> but the cleanest way seemed to me to be a per user transport map lookups
>>> for cloud users.
>> I think that per-user transport lookups are unwise.
>
> Hi,
>
> Thanks for the reply, could you tell me why per-user transports are unwise? 

The trivial-rewrite service, which is responsible for transport mappings,
is used pervasively in Postfix, including in the queue manager. I prefer
to not add dependencies on potentially unreliable services (LDAP) in
this code path. The handling of temporary LDAP failures is much more
graceful in cleanup(8) (virtual alias rewriting), where lookups can
tempfail. In the queue manager transport lookups canno be set aside,
the lookups retry indefinitely on error... Performance can in some cases
be impacted, but this is less likely, and I think reliability comes first.

Yes, per-user transports are easier to implement, you choose your own
pain thresholds.

-- 
Viktor.

Re: ldap transport lookups: any holes in my solution?

[Wietse Venema]

John Baker:
> On 04/25/2011 10:59 AM, Victor Duchovni wrote:
> > On Thu, Apr 21, 2011 at 02:59:27PM -0400, John Baker wrote:
> >
> >> There are several ways to make this work right including virtual aliases
> >> but the cleanest way seemed to me to be a per user transport map lookups
> >> for cloud users.
> > I think that per-user transport lookups are unwise.
> 
> Hi,
> 
> Thanks for the reply, could you tell me why per-user transports are 
> unwise? Do they not scale well?  Our numbers are fairly low.

The problem is that these lookups happen for each delivery, on
request by the queue manager.  

If you're doing per-user entries they will almost always be pulled
from a "network" database such as LDAP or *SQL, and those lookups
can become a queue manager performance bottleneck. This hurts
because there is only one queue manager process.

If you're doing domain-based transport mapping, the mapping can be
kept in a local file (hashed, a la Berkeley DB) and latency will
not be an issue.

Wietse

PATCH: Make local tempfail when LDAP is down

[Wietse Venema]

William Ono:
> I was hoping that setting mailbox_transport_maps to the same LDAP map as
> local_recipient_maps would cause local to tempfail rather than bounce in
> this case. It turns out that it does not.

The same error happens in mailbox_command_maps, mailbox_transport_maps,
and fallback_transport_maps. That's three for the price of one.

A variant of this occurs in the code that expands the owner-alias,
while returning non-deliverable mail to a local alias.

With the attached fix, Postfix should tempfail the delivery instead
of pretending that the lookup produced a "not found" result.

See attached file: 20110426-local-maps-find-patch.

Wietse
20110426

Bugfix: the local(8) delivery agent ignored table lookup
errors in mailbox_command_maps, mailbox_transport_maps,
fallback_transport_maps and (while bouncing mail to alias)
alias owner lookup. Problem reported by William Ono. Files:
local/command.c, local/mailbox.c, local/unknown.c,
local/bounce_workaround.c.

diff -cr -C4 /var/tmp/postfix-2.9-20110323/src/local/Makefile.in 
src/local/Makefile.in
*** /var/tmp/postfix-2.9-20110323/src/local/Makefile.in Sun Jan  9 17:12:05 2011
--- src/local/Makefile.in   Tue Apr 26 16:28:59 2011
***
*** 105,112 
--- 105,113 
  bounce_workaround.o: ../../include/attr.h
  bounce_workaround.o: ../../include/been_here.h
  bounce_workaround.o: ../../include/bounce.h
  bounce_workaround.o: ../../include/canon_addr.h
+ bounce_workaround.o: ../../include/defer.h
  bounce_workaround.o: ../../include/deliver_request.h
  bounce_workaround.o: ../../include/delivered_hdr.h
  bounce_workaround.o: ../../include/dict.h
  bounce_workaround.o: ../../include/dsn.h
diff -cr -C4 /var/tmp/postfix-2.9-20110323/src/local/bounce_workaround.c 
src/local/bounce_workaround.c
*** /var/tmp/postfix-2.9-20110323/src/local/bounce_workaround.c Sat Feb 13 
21:00:24 2010
--- src/local/bounce_workaround.c   Tue Apr 26 16:44:22 2011
***
*** 76,83 
--- 76,84 
  #include 
  #include 
  #include 
  #include 
+ #include 
  #include 
  #include 
  
  /* Application-specific. */
***
*** 96,126 
  if (var_ownreq_special) {
char   *stripped_recipient;
char   *owner_alias;
const char *owner_expansion;
  
  #define FIND_OWNER(lhs, rhs, addr) { \
lhs = concatenate("owner-", addr, (char *) 0); \
(void) split_at_right(lhs, '@'); \
rhs = maps_find(alias_maps, lhs, DICT_FLAG_NONE); \
  }
  
FIND_OWNER(owner_alias, owner_expansion, state.msg_attr.rcpt.address);
!   if (owner_expansion == 0
&& (stripped_recipient = strip_addr(state.msg_attr.rcpt.address,
(char **) 0,
*var_rcpt_delim)) != 0) {
myfree(owner_alias);
FIND_OWNER(owner_alias, owner_expansion, stripped_recipient);
myfree(stripped_recipient);
}
!   if (owner_expansion != 0) {
canon_owner = canon_addr_internal(vstring_alloc(10),
  var_exp_own_alias ?
  owner_expansion : owner_alias);
SET_OWNER_ATTR(state.msg_attr, STR(canon_owner), state.level);
}
myfree(owner_alias);
  }
  
  /*
   * Send a delivery status notification with a single recipient to the
--- 97,133 
  if (var_ownreq_special) {
char   *stripped_recipient;
char   *owner_alias;
const char *owner_expansion;
+   int saved_dict_errno;
  
  #define FIND_OWNER(lhs, rhs, addr) { \
lhs = concatenate("owner-", addr, (char *) 0); \
(void) split_at_right(lhs, '@'); \
rhs = maps_find(alias_maps, lhs, DICT_FLAG_NONE); \
  }
  
+   dict_errno = 0;
FIND_OWNER(owner_alias, owner_expansion, state.msg_attr.rcpt.address);
!   if ((saved_dict_errno = dict_errno) == 0 && owner_expansion == 0
&& (stripped_recipient = strip_addr(state.msg_attr.rcpt.address,
(char **) 0,
*var_rcpt_delim)) != 0) {
myfree(owner_alias);
FIND_OWNER(owner_alias, owner_expansion, stripped_recipient);
myfree(stripped_recipient);
}
!   if ((saved_dict_errno = dict_errno) == 0 && owner_expansion != 0) {
canon_owner = canon_addr_internal(vstring_alloc(10),
  var_exp_own_alias ?
  owner_expansion : owner_alias);
SET_OWNER_ATTR(state.msg_attr, STR(canon_owner), state.level);
}
myfree(owner_alias);
+   if (saved_dict_errno != 0)
+   /*

Re: PATCH: Make local tempfail when LDAP is down

[Victor Duchovni]

On Tue, Apr 26, 2011 at 05:19:13PM -0400, Wietse Venema wrote:

> diff -cr -C4 src/local/bounce_workaround.c src/local/bounce_workaround.c
> *** src/local/bounce_workaround.c Sat Feb 13 21:00:24 2010
> --- src/local/bounce_workaround.c Tue Apr 26 16:44:22 2011
> ***
> *** 96,126 
> [...]
> --- 97,133 
> [...]
> + if (saved_dict_errno != 0)
> + /* At this point, canon_owner == 0. */
> + return (defer_append(BOUNCE_FLAGS(state.request),
> +  BOUNCE_ATTR(state.msg_attr)));

Does this code path need to do anything to set an error reason? Something
along the lines of:

dsb_simple(state.msg_attr.why, "4.3.0",
   "owner alias lookup failure");

-- 
Viktor.

Re: Make local tempfail when LDAP is down

[Timo Sirainen]

On 26.4.2011, at 15.44, Wietse Venema wrote:

>> However, for mail that originates on the mail host, e.g. by mail(1),
>> when an LDAP outage causes local users to disappear (getent passwd
>> username returns no results with exit code 2) local bounces the mail as
>> user unknown. While this is not surprising behaviour, it is not the
>> desired behaviour, either.
> 
> This is a bug in the SYSTEM NSS LDAP client. The SYSTEM NSS LDAP
> client works incorrectly: when the LDAP server fails to respond,
> the SYSTEM NSS LDAP client returns a NOTFOUND result.

Just wondering: Is it really the nss-ldap code that is buggy or just the libc's 
getpwnam() call that is fundamentally broken? I recently changed Dovecot to use 
getpwnam_r() instead, since it allows proper error checking.

Re: Make local tempfail when LDAP is down

[Victor Duchovni]

On Wed, Apr 27, 2011 at 12:34:43AM +0300, Timo Sirainen wrote:

> > This is a bug in the SYSTEM NSS LDAP client. The SYSTEM NSS LDAP
> > client works incorrectly: when the LDAP server fails to respond,
> > the SYSTEM NSS LDAP client returns a NOTFOUND result.
> 
> Just wondering: Is it really the nss-ldap code that is buggy or just
> the libc's getpwnam() call that is fundamentally broken? I recently
> changed Dovecot to use getpwnam_r() instead, since it allows proper
> error checking.

Most likely a combination of both. It is not, for example, clear which
error returns from getpwnam_r() indicate a transient error, and which
"entry not found". This is an API problem.

Given the API, with a transient error, the library must keep trying until
the lookup succeeds, since there is no way to report a transient error.

-- 
Viktor.

Re: Make local tempfail when LDAP is down

[Timo Sirainen]

On 27.4.2011, at 0.53, Victor Duchovni wrote:

>> Just wondering: Is it really the nss-ldap code that is buggy or just
>> the libc's getpwnam() call that is fundamentally broken? I recently
>> changed Dovecot to use getpwnam_r() instead, since it allows proper
>> error checking.
> 
> Most likely a combination of both. It is not, for example, clear which
> error returns from getpwnam_r() indicate a transient error, and which
> "entry not found". This is an API problem.

It is clear. getpwnam_r() returns 0 both on success and "user not found", you 
just need to check if the result is NULL or not. If it returns anything else 
than 0 it's a transient error. If the NSS code internally messes this up, 
that's its fault then. But I think getpwnam_r() API is fine.

Re: Make local tempfail when LDAP is down

[Wietse Venema]

Timo Sirainen:
> On 27.4.2011, at 0.53, Victor Duchovni wrote:
> 
> >> Just wondering: Is it really the nss-ldap code that is buggy or just
> >> the libc's getpwnam() call that is fundamentally broken? I recently
> >> changed Dovecot to use getpwnam_r() instead, since it allows proper
> >> error checking.
> > 
> > Most likely a combination of both. It is not, for example, clear which
> > error returns from getpwnam_r() indicate a transient error, and which
> > "entry not found". This is an API problem.
> 
> It is clear. getpwnam_r() returns 0 both on success and "user not
> found", you just need to check if the result is NULL or not. If
> it returns anything else than 0 it's a transient error. If the
> NSS code internally messes this up, that's its fault then. But I
> think getpwnam_r() API is fine.

That would be an improvement over waiting until getpwnam() semantics
is restored. Now need to fing out when getpwnam_r() was introduced,
as I don't want to retroactively break supported systems.

Wietse