Zhou, Yan | 1 Oct 2010 01:02

RE: LDAP trouble with Postfix

Thanks, Jeroen, see my comment below.

> > postmap -qv  test.medplus.com ldap:acceptdomains
> > postmap: fatal: open database  test.medplus.com.db: No such file or
> > directory
> >
> 

This is the output of postmap -vq  test.medplus.com  ldap:acceptdomains

It does query into LDAP but returns nothing when the same LDAP query
returns value in another LDAP browser.

postmap: dict_open: ldap:acceptdomains
postmap: dict_ldap_lookup: In dict_ldap_lookup
postmap: dict_ldap_lookup: No existing connection for LDAP source
acceptdomains, reopening
postmap: dict_ldap_connect: Connecting to server
ldap://hub-dev-app01.dev.medplus.com:389/
postmap: dict_ldap_connect: Actual Protocol version used is 2.
postmap: dict_ldap_connect: Binding to server
ldap://hub-dev-app01.dev.medplus.com:389/ as dn
postmap: dict_ldap_connect: Successful bind to server
ldap://hub-dev-app01.dev.medplus.com:389/ as
postmap: dict_ldap_connect: Cached connection handle for LDAP source
acceptdomains
postmap: dict_ldap_lookup: acceptdomains: Searching with filter
(domainname=test.medplus.com)
postmap: dict_ldap_get_values[1]: Search found 0 match(es)
postmap: dict_ldap_get_values[1]: Leaving dict_ldap_get_values
(Continue reading)

Victor Duchovni | 1 Oct 2010 01:51
Favicon

Re: Relay queue behavior

On Thu, Sep 30, 2010 at 03:55:50PM -0700, Yang Zhang wrote:

> After a relay serving as a backup MX enqueues a message because the
> primary is down, and then the relay is reloaded with a different
> configuration such that it no longer is relaying mail, will Postfix
> still continue to attempt forwarding the already-queued messages?

Yes, of course. Mail comes in, and then it goes out. The two activities
are largely decoupled.

--

-- 
	Viktor.

Frank Bonnet | 1 Oct 2010 15:43
Picon
Picon
Favicon

Greylisting or not ?

Hello

I actually use postgrey as greylisting utility

I have no experience with other greylisting softwares
but Postfix "gurus" advice would be greatly appreciated
to compare and eventually change for another software.

Thanks a lot

lst_hoe02 | 1 Oct 2010 16:12
Picon
Favicon

Re: Greylisting or not ?

Zitat von Frank Bonnet <f.bonnet <at> esiee.fr>:

> Hello
>
> I actually use postgrey as greylisting utility
>
> I have no experience with other greylisting softwares
> but Postfix "gurus" advice would be greatly appreciated
> to compare and eventually change for another software.

We also use Postgrey

Works stable and as expected and saved us from blocking dynamic IPs per RBLs.

What is always recommended:
- Use auto-whitelist=1 and a very long purge delay for the client list
- Use more than some seconds as greylist delay

Regards

Andreas

Attachment (smime.p7s): application/pkcs7-signature, 6046 bytes
Noel Jones | 1 Oct 2010 17:06

Re: Greylisting or not ?

On 10/1/2010 8:43 AM, Frank Bonnet wrote:
> Hello
>
> I actually use postgrey as greylisting utility
>
> I have no experience with other greylisting softwares
> but Postfix "gurus" advice would be greatly appreciated
> to compare and eventually change for another software.
>
> Thanks a lot

What you use depends greatly on what your needs and 
expectations are.

I don't know of any "bad" greylisting software, but some of 
the choices may be inappropriate for particular sites (eg. too 
simple for a large multi-MX site, too complex for a home/hobby 
site with an inexperienced admin).

What are you looking for? Some feature that postgrey doesn't 
seem to support?

If you don't have any problem with postgrey, no need to 
change.  If you just want to experiment, pick something and 
try it out.

   -- Noel Jones

Kris Deugau | 1 Oct 2010 17:15
Picon

Re: Postscreen update

Stan Hoeppner wrote:
> I was going by information I received from another list.  I don't use
> the data feed service.  Does this include the CBL data set within Zen?

Yes;  CBL is a subset of XBL.  It's not provided separately, at least 
not by Spamhaus.  XBL alone is at least ~50x the size (on-disk) of the 
other Zen subcomponents (PBL being the next largest).

> I would make an educated guess that the size of the CBL data set would
> be over 100MB alone.  25 million 32bit IP addresses (4 bytes) would be
> 100MB, if my math is correct.  25 million bot infected hosts around the
> world seems like a very conservative estimate.

Since Spamhaus ZEN is intended to be used as a no-FP blocklist, it's 
probably a lot less aggressive about listing these than some other lists 
might be.

> Yeah, running the Spamhaus zones on local rbldnsd instances on each MX
> would require some distribution magic, as you state.  Never done this
> myself.  I'd be more inclined to go the route you've taken, if I were
> ever in a position to manage such a thing.

The "magic" amounts to a couple of crontab entries:

*/5 * * * * root rsync /path/to/spamhaus-in resolver1::rbldns
*/5 * * * * root rsync /path/to/spamhaus-in resolver2::rbldns

(I set up a script to only copy the actual zone data files - the inbound 
Spamhaus sync sometimes leaves extra files lying around, I have to build 
the local blacklist zone data from the database, and it's always nice to 
(Continue reading)

Rich Bishop | 1 Oct 2010 18:29
Picon
Favicon

Mail being deferred with unknown mail transport error

I have a RHEL5 machine running Redhat's build of postfix 2.3.3 and am having
problems with messages being sporadically deferred with 'unknown mail transport
error'.

The machine is a gateway for listserv, so it does receive lots of mail at
times. It appears that the problem is related to the amount of mail being queued
- if I do a postqueue -f, most of the problem messages are again deferred with
the same error. If I slowly put the back onto the queue with postsuper -r <qid>
; sleep 1 then most messages flow through without any problems.

I've done some debugging - postfix appears to be successfully looking up the
user in LDAP and getting a mailhost, but fails before it opens an smtp
connection to the mailhost. 

Here's some verbose output from qmgr:

Sep 30 20:22:18 jay postfix/qmgr[10510]: send attr address = <user1> <at> DREXEL.EDU
Sep 30 20:22:18 jay postfix/qmgr[10510]: private/rewrite socket: wanted attribute: flags
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute name: flags
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute value: 0
Sep 30 20:22:18 jay postfix/qmgr[10510]: private/rewrite socket: wanted attribute: transport
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute name: transport
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute value: smtp
Sep 30 20:22:18 jay postfix/qmgr[10510]: private/rewrite socket: wanted attribute: nexthop
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute name: nexthop
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute value: [<mailhost>.irt.drexel.edu]
Sep 30 20:22:18 jay postfix/qmgr[10510]: private/rewrite socket: wanted attribute: recipient
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute name: recipient
Sep 30 20:22:18 jay postfix/qmgr[10510]: input attribute value: <user1> <at> DREXEL.EDU
Sep 30 20:22:18 jay postfix/qmgr[10510]: private/rewrite socket: wanted attribute: flags
(Continue reading)

Stefan | 1 Oct 2010 18:29

RE: verify db with mysql

Hi list,

I'm in the process of adding write support to postfix's mysql client (you will 
find a patch against postfix-2.7.1 in the appendix). But I have two problems:
1) the dict_cache_clean_event writes _LAST_CACHE_CLEANUP_COMPLETED_ to the 
database. Is this the intended behaviour?

2) If I'm guessing right then the dict_cache_clean_event will iterate with 
help of dict->sequence through the database and will look for keys to expire. 
But I don't know how to implement this iteration/traverse process with mysql. 
My first thought was to use "SELECT * FROM verify" and mysql_use_result() but 
I'm wondering if there is a better solution.
Has anyone an idea of how to do this?

Thanks for your help and best regards
Stefan

> > by Stefan Jakobs on 2010-06-13T19:43:00+00:00
> > Hello list,
> > I refer to my question of august 2008
> > (http://archives.neohapsis.com/archives/postfix/2008-08/0747.html, and see
> > below).
> > What are the necessary steps to add update support to the mysql client
> > (Postfix 2.5.6 or newer)?
> > Has someone already done this and is willing to share the code?
> > Thanks for your help and kind regards
> > Stefan
> Wietse wrote on August 22nd 2008:
> Stefan Jakobs:
> I think this involves writing, testing, and documenting code. The
(Continue reading)

Wietse Venema | 1 Oct 2010 18:50

Re: Mail being deferred with unknown mail transport error

Rich Bishop:
> Sep 30 20:22:18 jay postfix/qmgr[10510]: qmgr_transport_throttle: transport smtp: status: 4.3.0
reason: unknown mail transport error
> Sep 30 20:22:18 jay postfix/qmgr[10510]: warning: transport smtp failure -- see a previous
warning/fatal/panic logfile record for the problem description

As the logfile says, search the logfile for warning/fatal/panic
records.

See http://www.postfix.org/DEBUG_README.html#logging
for instructions.

	Wietse

Wietse Venema | 1 Oct 2010 18:58

Re: verify db with mysql

Stefan:
> Hi list,
> 
> I'm in the process of adding write support to postfix's mysql client (you will 
> find a patch against postfix-2.7.1 in the appendix). But I have two problems:
> 1) the dict_cache_clean_event writes _LAST_CACHE_CLEANUP_COMPLETED_ to the 
> database. Is this the intended behaviour?

This record is needed by the cache cleanup pseudo-thread. This code
assumes that the verify(8) daemon is responsible for cleaning up
the verify(8) cache.

> 2) If I'm guessing right then the dict_cache_clean_event will iterate with 
> help of dict->sequence through the database and will look for keys to expire. 
> But I don't know how to implement this iteration/traverse process with mysql. 
> My first thought was to use "SELECT * FROM verify" and mysql_use_result() but 
> I'm wondering if there is a better solution.
> Has anyone an idea of how to do this?

Does the database support a first/next operation?

	Wietse

> Thanks for your help and best regards
> Stefan
> 
> > > by Stefan Jakobs on 2010-06-13T19:43:00+00:00
> > > Hello list,
> > > I refer to my question of august 2008
> > > (http://archives.neohapsis.com/archives/postfix/2008-08/0747.html, and see
(Continue reading)


Gmane