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

Re: [Fwd: 2.99.57.pre3 router problem (pipe prediction wrong error)]




Hi,


The solution I've found to work is:

dlm_host="mydomain.co.uk"

\1 = $dlm_host (at this point)

if [ "xDARRYL" = "x$dlm_user" ]; then

	tmpal=()

	tmp=$(echo $dlm_user@once.$dlm_host | \

		maprrouter "$A" "$dlm_user" "$dlm_host" "$plustail" "$domain"

	)

	lappend tmpal $tmp

	tmp=$(echo copy_in_user@once.mydomain.co.uk | \

		maprrouter "$A" "$dlm_user" "$dlm_host" "$plustail" "$domain"

	)

	lappend tmpal $tmp

	return $tmpal

fi



Maybe the pipe prediction is some optimization in newer zmsh's.

I have no idea what I'm doing (this is normal with zmsh), but this seems 
to work the idea is borrowed from one of the aliases*.cf files.

Maybe I should check the result of each $tmp for errors before deciding 
to assign it to $tmpal ?


I must have read various fragments of zmailer documentation at differing 
points in my life but I've never had a clear picture of the router 
process and how it handles mail, how that mail processing hooks into 
various function entry points of zmsh.  The documentation I've seen is 
from the perspective if you install the default system how a sysadmin 
can configure it up to do the normal thing.

So I feel I'm always hacking in the darkness hoping the router process 
will put the mails in the right place, it would be really good to 
understand what if all the scripts were chucked away how would you start 
again ?

Most of the features I'd like to use but easily relate to local mail 
processing and the systems I use zmailer on deliver to POP3/IMAP 
accounts.  I'd like to have to concept of multi-user multi-homing 
without it expecting heratige Unixisms to exist like local userid / 
account a home directory.  So for example I can apply an aliases file 
configuration to a specific domain, check a .forward like profile for 
forwarding, setup auto-responders, even setup a procmail configuration 
to run in a sandbox.

A start would seem to be by isolating all the points where configuration 
data is needed from file existence checking and contents and providing a 
new database driver to do this job of providing the information wanted.

Then some work in the router to remove some of the bindings with the 
concept of local-name, so that the configuration and processing is 
completely dependent on the context created during the processing of the 
mail.

Thinking out aloud maybe whats needed is a two tier router, one like now 
that is for all submissions (SMTP, /usr/lib/sendmail, UUCP, etc... plus 
other networks).  This higher level understand different mail networks 
and does exactly what happens now.  Then a lower level router that does 
local/* processing that can base its processing on the context of the 
mail concerned.

Enough of me babbling...

Any thoughts,


-- 
Darryl L. Miles


-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi