Jose-Marcio Martins da Cruz wrote:
Claudio Telmon wrote:
Jose-Marcio Martins da Cruz wrote:
I need some more clarification on this, maybe it's just me not knowing
enough about MTAs internals. As the border MTA receives a RCPT TO for
either of these addresses, it should be able to know if it is a valid
address. In my (very limited) experience, this means that each of these
addresses mut be defined as a valid address, the MTA doesn't have rules
to decide that since jose-marcio.martins_da_cruz is a valid address,
jose-marcio.martins must be valid too. So, if each of these addresses is
individually defined in some list/database accessed by the MTA, then
with the same rules, the related token database should be accessed too.
Should an "automatic aliasing" rule exist, then the same rule could
exist for the token database. Also, if "somewhere" an alias is defined
for an address, then the correspondent database could just be a pointer
to the database of the "main" address. This could even implement "chains
of aliases" as "chains of pointers to token databases".
The border MTA surely knows a list of valid addresses, but it may not
know, all the time, that all this addresses resolve to the same login -
sometimes some addresses are resolved in the final internal servers.
But well, you can find some organisations with this kind of thing
nowadays. Don't know if this shall be taken into account to design
future systems.
I think this is feasible with an appropriate address book manager.
Anyway, the load is for the MUA, not for the MTA, so the number of users
shouldn't matter.
Hmmm. If the border MTA accept and the MUA reject by lack of consent, a
bounce is generated.
Surely, but that's not what I mean. Once the address book manager knows
that it must handle a list of (receiver) addresses aliases that will
share the same tokens, it will push those tokens to the MTA, so that the
MTA will have a valid list of tokens for the various aliases and reject
messages as required.
--
Claudio Telmon
claudio(_at_)telmon(_dot_)org
http://www.telmon.org
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg