[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: route to address
> > 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
> 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()
> return 1
> Being able to bounce mail like that is useful (to me).
Yes, but it is simpler when you use routes:
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
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.
/Matti Aarnio <firstname.lastname@example.org>