What am I missing?
A crazy client? ;-) One of my account holders needs this functionality; and having reviewed what he wants to do, it *is* logical, although I'd probably have done it differently. Design decisions aside, though; he's able to run it in sendmail elsewhere (and already in production, so definitely no design changes). And I'm not about to install that pandora's box. Finding that Courier doesn't support wildcard dns records, adding ".domain.com" support to Courier would round out the feature set in such ways that both make sense and allow for additional configurations to be migrated to Courier that otherwise can't be.
Using hosted domains, you can assign all the aliases you need... Can't even
see a reason to structure your setup this way, but assuming there is one,
there can't possibly be an unlimited number of domains - so just plug them
into the hosted file by script like I'm sure many of us do and rebuild the
DB.
But there *can* be an unlimited number of subdomains -- wildcard dns lets you say *.domain.com resolves to anything; e.g. with *.foobar.com resolving 10.147.31.3, you can then mail user@<something>.foobar.com, where <something> can be anything dynamic and used programatically very much like dash extension's user-<something> (think .courier-default and $EXT2, $EXT3, etc.). I'm not a huge fan (or even a small fan!) of wildcard dns; it's sloppy and hackish; but if a client decides to use it, I sure don't like not being able to meet the client's needs simply because Courier doesn't support it (without good cause).
The only other time I've seen something similar requested had to do with the
postmaster account - can I ask the reasoning behind the existance of the
structure you are seeking?
I've probably answered this above; but will give a specific example. This is simplified but analogous to what my client's doing in sendmail: define addresses in the format [EMAIL PROTECTED]; define token as being a unique key which the user can set reject/accept rules through some web interface/sql db; route all email for "[EMAIL PROTECTED]" to a script that examines the hostname, extracts token, looks it up in the sql db, and determines if email, based on token, should be accepted or rejected. This picture is slightly more complicated because <user> is also defined in the db; but that's just a mater of placing a call to his script in the .courier-default file under "[EMAIL PROTECTED]".
As I've said, it's not the way I'd have designed it; dash-extensions would be symmetric. But it *is* logical, in the tmtowtdi sense, and I haven't seen any reason why it shouldn't be supported or allowed (although I'm all ears!).
Thoughts? I presume at this point that it's not a conf error on my part, and that Courier really doesn't support this (Sam, correct me?). More importantly, is their support for (or objections to?) adding this into Courier?
best, Jeff
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
