On Mon, 2 Dec 2002, Wietse Venema wrote:

> Sofar I am looking at the following:
>
> change hash_queue_depth default
>
> The default depth of 2 subdirectory levels makes mailq
> unnecessarily slow for most sites. I am inclined to make the
> default 1, which sucks when your site has lots of mail queued.
>

This is OK. Setting it explicitly will not be an undue burden, but perhaps
it is time to bundle a VOLUME_README with discussion and recommended
settings for high volume sites.

I would like to have a separate (larger) hash queue depth for the hold
queue, but this is a new feature, so we can talk about it after 1.2.

> deprecate check_relay_domains
>
> This restriction should go away. As of version 1.2, any use of
> check_relay_domains should produce a warning and suggest using
> "reject_unauth_destination" instead, and this feature should
> be removed from the documentation.
>
> change smtpd_recipient_restrictions default
>
> As of version 1.2, replace the default from "permit_mynetworks,
> check_relay_domains" by "permit_mynetworks, reject_unauth_destination".
>

Yes, perhaps the warning should only be logged once per instance of
"smtpd" to conserve disk space. On the other hand making it really
annoying is more likely to get people to convert.

> keep HOLD/DISCARD actions
>
> I'm inclined to include these in the 1.2 release, even though
> their use in smtpd_xxx_restrictions is currently limited to
> access maps.
>

Thanks. I will be using this. Hopefully the hold queue hashing patch will
be in 1.2. Discard will be very valuable for blocking sender == recipient
spam.

> keep qmgr_clog_warn_time
>
> I'm inclined to include this in the 1.2 release. When this
> parameter setting is non-zero, the Postfix queue manager warns
> when mail for some destination is piling up in the active queue,
> and suggests a variety of remedies to speed up delivery (increase
> per-destination concurrency limit, increase active queue size,
> use a separate delivery transport, increase per-transport
> process limit). The heuristics and recommendations are a bit
> questionable, but I haven't heard any complaints, which means
> either people don't read their logs or the suggestions actually
> help.
>

Yes. With the warnings explained in more detail in VOLUME_README.

> snapshot only: sender-based routing
>
> I'm inclined to not include this in the 1.2 release. With
> sender_based_routing=yes, Postfix will choose the delivery
> transport and "nexthop" host by looking at the sender address
> instead of the recipient.

Yes, I don't think the semantics are simple enough yet.

>
> If you found other problematic default settings or features in
> recent snapshots, now is a good time to let me know.
>

I think that Postfix should eventually deprecate the new multiple service
instance parameters (cleanup_service_name=cleanup2) and replace it with
better support for multiple Postfix instances.

The unspeakable acts performed on master.cf to get the current recipes
working are difficult to explain and hard to upgrade (if master.cf needs
to be machine edited).

Multiple instances are easier to manage IMHO, generate cleaner logs, and
allow separate inspection of pre and post content filter queues.

So I would tentatively recommend not promoting multiple services to
official status.

A middle ground may be to only promote variable cleanup service names,
because hosting multiple virtual domains on distinct IP addresses with
different "smtpd" daemons and different header/body checks is not too
unreasonable.

I would remove support for:

#define VAR_BOUNCE_SERVICE "bounce_service_name"
#define VAR_DEFER_SERVICE "defer_service_name"
#define VAR_PICKUP_SERVICE "pickup_service_name"
#define VAR_QUEUE_SERVICE "queue_service_name"
#define VAR_REWRITE_SERVICE "rewrite_service_name"
#define VAR_SHOWQ_SERVICE "showq_service_name"
#define VAR_ERROR_SERVICE "error_service_name"
#define VAR_FLUSH_SERVICE "flush_service_name"

As multiple instance support is not in any snapshot, again it is not
realistic in 1.2. My patches for this don't touch anything except
postfix-script, post-install and postfix-install, hopefully you would
consider them with some extra polish for the next round of post
1.2 snapshots.

Finally in the documentation department, the notes on the various domain
types should likely be included in a larger VIRTUAL_README.

-- 
	Viktor.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]