Jose-Marcio Martins da Cruz wrote:
Claudio Telmon wrote:
Jose-Marcio Martins da Cruz wrote:
official contact addresses of companies.
In fact, at our domain, few of these kind of adresses aren't protected.
Most of them are adresses of the kind "everybody in the engineering
department" (addresses which are of internal use only) "butterfly
research workgroup" (a closed group working on some particular subject)
and so. These are adresses which *are* protected and the concept of
consent-enable is materialized by checking if the SMTP client sending
messages to is in some known network or if the connection was
authenticated. But nothing prevents that this kind of consent should be
expanded. Either way, in an organisation like the ours, users couldn't
understand that the same consent system used for individual addresses
couldn't be used for collective addresses.
This is a very interesting case. I'll have to think at the implications
of it.
You got the message ! 8-)
So, I think I can give some answers now. There are many many different
cases, so I will only deal with the most (IMHO) representative ones, the
others should be very similar.
The main issues are:
- how people are added to the list of correspondents for shared address;
- how to send messages to the shared address
- how to send answers from the shared address
I can see two kinds of "shared addresses": addresses that are
forwarded/expanded to a group of actual recipients, and "shared
mailboxes" where many people can read messages. In many cases, this
second case means that the shared mailbox is accessed through a web
interface, and this solves many problems (e.g. tokens stay with the
interface/mailbox, whoever uses it). This is the case of many CRM tools.
Problems may arise with people accessing a shared mailbox through
personal MUAs.
With respect to "adding people to the list of correspondents", while the
decision about adding people can be complex (unanimity, majority, etc),
from a technical perspective, what matters is who is entitled to push
tokens to the MTA for that address: whoever can push tokens can add
correspondents.
There are two main cases which may cause some problems, while some
others are very similar. Most cases shouldn't be a problem.
1. "Forwarding style" shared address. Sender A, with a consent-enabled
address and not being part of the group, writes to the shared address.
The message will carry a valid token to be used in answers. In "mailing
list style" addresses, this token wouldn't be forwarded to the group,
but this would mean that nobody could send answers, so in this case the
token must be forwarded with the message. This is just a matter of
configuration of the forwarding agent. B, member of the group, could
send answers either from a personal address (providing to A a token for
this personal address) or from the shared address. In this last case, B
must be able to push a token for the shared address on the MTA. This is
consistent: B can use a consent-enabled address as sender only if he can
push tokens for that address. All this means that the choice to forward
or not to forward tokens must be configurable in forwarding agents.
Note that B may already own a personal token for A, due to a personal
contact. In this case, B may be required to hold different tokens for
the same correspondent. Privacy and anonymity issues are not different
from those already discussed in the paper.
Note also that all members of the shared address group would share the
same tokens for the shared address correspondents, which is consistent
with the concept of shared address, but nonetheless reduces the ability
to point out how these tokens could have been compromised/exposed by one
of these persons.
2. "Shared mailbox style" shared address, accessed through personal MUA.
Again, A sends a message to the shared address. Problems may arise if B
downloads the message to its MUA and then deletes it from the mailbox,
since the other members of the group wouldn't receive the token required
to send messages to A. In this case, B should respond with its own
personal address as sender, since otherwise other members of the group
could be required to deal with subsequent messages, which are from a
sender they can not send messages to. This is usually consistent, since
other members of the group would miss some of the answers anyway, unless
these are sent in Cc: to the shared address. Should B be required to
answer from the shared address, then in this very specific case a way to
share A's token would be required. Note that since the problem is with
A's token, not enabling consent for the shared address won't solve the
problem. Note also that the whole problem depends on B deleting the
message from the mailbox, so that other members can't access it and
collect the token.
The same problem may arise with new members of the group accessing the
shared address, be it "forwarding" or "shared mailbox" style: they will
miss the tokens provided to the address by correspondents before then,
so once added to the group they will need to receive a full set of
tokens, e.g. within a message confirming their inclusion in the group.
As usual, it's up to A to decide if messages conforming the "consent
request" constraints, but not carrying tokens, can be delivered, in
order to deal with correspondents not implementing the consent
framework, including shared addresses.
So, all in all, I think that the shared address case can be dealt with
in the framework, only some specific cases may require a way to share
tokens.
--
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