Adam Bradley wrote:
> I have a situation where email delivered to a single namespace needs to be
> delivered to a user who could be in one of a number of downstream system
> (but we don't know which one). I was wondering if I could use "Callback
> Verification" http://en.wikipedia.org/wiki/Callback_verification to achieve
> this?
>
> Ideally, I'd like to avoid the use of a look up table.
'A' user? I'd store it on-box and let the individual come fetch with
sync'ed IMAP (or even POP).
There is hardly an MUA still in common use that cannot easily handle
multiple account identities AND select among different source ID's and
their associated MTA's on the outbound. When responding to any of the
inbound messages, one needs but a mouse-tick to select among - lemme see
- down to a mere ten surviving outbound identities here now...
Problem solved for the single-user case?
Now - if an entire *community* of users, I'd stick an independent
web-managed DB in there and let the Luser's manage their own destination
'aliasing' changes.
Exim can DO all this internally by the sort of succesive callout/fail,
try again, in your Plan A ....but it is akin to drinking soup through a
sock, and not a clean one, either.
Some form - ANY form - of externally-managed lookup-table, DB, or such
is more efficient. User and group privs granted each managing daemon are
all one needs to keep Church and State from improper entanglements.
Exim doesn't really give a taxatwoshits if it is a flat file, DB, CDB,
LDAP, light or heavy SQL engine, nor where in internet time and space it
sits. All Exim needs is access and a reasonably reliable link.
You might also offload the whole can of worms onto the donwstreams by
attempting duplicate deliveries at each go with a chain of 'unseen'
routers, then simply dumping the NDR's from those who haveth not the
addressee. Best they be in advance agreement with this, though that is
also true of user-specific callouts if you don't want to be branded rude.
Bill
--
韓家標
