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

Re: route to address

> mea@nic.funet.fi
> >   Could you send me the  rrouter.cf  code lines you refer to above ?
> I don't have them any more, and I don't miss them.  I just stuck an
> extra ssift or two into rrouter().
> Not at all scalable and I soon tired of editing rrouter.cf every time
> I needed to change an alias, so I hacked a 'fqaliases' thing and when
> you added fqdnaliases I started using it.
> The other day I added a similar ugly hack near the end of fqdnalias.cf
> to provide semi-meaningful bounces for virtual domains:

	For this you can use routes database!

> 	# Didn't match, bounce perhaps?
> 	ssift "$lcaddress" in
> 	(.+)@kde.org
> 		return (((error badkde "$address" $A)))
> 		;;
> [ ... more lines, one per domain ... ]
> 	.*
> 		return 1 # Not in  uu@hh  form!
		--------------- won't happen, tested at the
				begining of fqdn_neighbour()

> 		;;
> 	tfiss
> 	return 1
> }
> Being able to bounce mail like that is useful (to me).

	Yes, but it is simpler when you use routes:

		kde.org		error!badkde

	The trick is, that fqdnalias processing happens
	before anything else, and the routes sometime
	after it, thus you can do fall-back route of domains
	to channels, like to the error -- and it does scale ;-)

	It would scale better, if the error channel were
	smarter -- to be able to express some more generic
	thing, like:

		error!novirtdomainuser!"customized message text"

	from which the channel is 'error', and the channel
	parameter ("host" part) is "novirtdomainuser", which
	is a file name in "$MAILSHARE/forms/" directory.
	Then the extra arguments could be used in the error
	reports -- somehow.

	There could even be a way to report an error without
	doing error report generation by the error channel
	program.  Something in style of:
		error!-!"customized message text"
	which would use DSN mechanisms to do the reporting.

> --Arnt

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