[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a) sender rewriting b) separate queues/manual queue runs



> Morning (or whatever),
> 
> 	Sorry for not solving this myself but I need to give Zmailer
> a try very quickly in order to decide whether to go on or not. Here
> are several questions, I couldnt find obvious answer for:
> 
> 	I need to do sender rewriting, like I have a lot of virtual
> domains for one machine and when users send their mail outside of
> it the sender information has to point back to the virtual domain
> associated with this sender. So we have relation between accounts
> names and fqdn addresses, the question is what part of configuration
> I have to do the rewriting in. I tried rrouter and crossbar but that
> gave me no result. On other hand I am able to rewrite all the
> addresses (sender AND recipient) in internet (rewriting procedure)
> but cannot tell whether I rewrite sender or recepient address
> there.  Any advice for the newbie? :-)

	You want to rewrite the VISIBLE headers ?  Not only
	the transport envelope ?

	For the rewrite functions there should be additional parameter
	for the call. ... and actually there even is.

	I made a small change to the script at  crossbar.cf,  just by
	adding second parameter.    The rest I leave for you.
	(Same can be done with all rewrite functions.)

# This is usually the default message-header address rewriting function.
# It is responsible for hostname hiding and qualification.

internet (address, hname) {
	# 'address' is the address we are rewriting
	# 'hname'   is the header whose address(es) we are rewriting;
	#           value here is usually: 'From', 'To', etc.

	#echo "rewrite: internet: $hname $address" >> /tmp/hdr.log


	address="$(canonicalize "$address")"	# Canonicalize does local
						# hostname hiding...
	sift "$address" in
	(.*)<@(.+)>(.*)
			#if [ $(deliver \2) ]; then	# hostname hiding
			#	address="\1@${mydomain}\3"
			#	break
			#fi
			address="\1@\2\3" # No hostname hiding...
			;;
	(.*)<(.+)>(.*)	address="\1\2\3" ;;		# defocus
	[^@]+		
		# This is a local part address w/o any domains!
		address="$(condquote "$address")"
		address="$address@$mydomain"	# add our hostname
		;;
	tfis

	return "$address"
}	# end of internet




> 	Next, what I need to do is to hold all the mail for certain
> customers until they establish connection and request to run the
> queue. I realized I can hold the queue with the hold command in
> scheduler.conf but how do I initiate queue run for certain domain
> manually? ETRN is not a solution for all of the customers we have.

	Don't use the hold channel, unless you absolutely have to.
	There are no good uses for it aside of recovering from
	system malfunctions.

	The way the ETRN works is to send a special message (file)
	to the scheduler so that it triggers the queue run for the
	given target domain.  Right now it supports only queue starts
	with exactly matching hostnames.  That is, you can not do:
		ETRN *.foo.nl.net
	to start queues to hosts:
		bar.foo.nl.net
		fii.foo.nl.net
		etc..
	all at once.  You have to tell all target host names.

	For the scheduler I would put special selectors for the
	long delay customers, like:

		smtp/*.foo.nl.net
			interval=1m
			retries="10 30 300"
			expiry=14d
			...

	That way, it will at first try immediately, then after 10
	minutes, then 30 minutes after that, and finally every 300
	minutes.

	Having a thousand messages there arriving every few minutes
	will start the timer over and over again, but in quiscent
	state it will quickly back off, and in any case it needs
	only resources of ONE process when it actively attempts sends.

	If you do not want this "instant retry at new arrival",
	perhaps I can add an option to control it.

> 	I feel this posting is really inappropriate here but I
> cannot think of any other place to ask these questions at the
> moment so thanks in advance,

	On the contrary, this is (IMO) exactly what this
	list is for.

> 							alexis
> -- 
> 		Yesterday dont matter when its gone

	/Matti Aarnio <mea@nic.funet.fi>