ietf-asrg
[Top] [All Lists]

[Asrg] Authorized forwarding, was Microsoft takes over...

2011-10-30 07:11:41
On 29/Oct/11 11:16, Paul Smith wrote:

I've been thinking about forwarding

If you have A -> B, then server B forwards to server C, C can't do any
authentication based on A, because A doesn't know about the forwarding
(or it would, presumably, just send to C directly).

Correct.  One may still be able to tell whether a message originated
at A, though.

So, all sender domain authentication fails (without return path
rewriting)

That's the turn point.  We pine for domain authentication looking
forward to reckoning domain's reputation.  So far so good.  But a
simpler SMTP-AUTH suffices for authenticating a specific sender that
had been authorized beforehand.

So, what you need is for C to be able to give B an authentication key
for the forwarding. Then, B could pass that back to C with the message
(possibly as a parameter to the RCPT command).

For SMTP AUTH, it is a parameter to the MAIL command.  After having
authenticated, B can use message-specific authorizations by

 MAIL FROM:<author@A.example> AUTH=forwarder@B.example

C can check B is authorized, but must trust B uses authorizations
properly; that is, according to the message stream for which the
authorization was granted.

The issue with this is that user intervention would be needed - so
every time a user wants to subscribe to a mailing list,or set up a
forwarding to their gmail account, they would need to go to the
destination server, get a key from it, and give it to the
forwarding server. This could show consent for any anti-spamming
legislation, but could also be too complicated for many users to
handle.

Exactly.  If law-makers had been clever, they would have provided for
a protocol to exchange the consent automatically.  Something similar
to paying with a credit card via a bank site.  Users would need to
tell only their domain name to the mailing list manager, or gmail
account.  The wannabe forwarder B would redirect them to their server
C where they can authenticate, configure any detail such as the target
folder, and grant their consent back to B.

The authentication key would need to allow B to send *anything* to C
for the relevant recipient, so ideally the key that C gives would be
specific to B (to allow it to be revoked in the case of abuse)

Yes.  For non-transferable consent, the user's server C can pass an
opaque local-part to the wannabe forwarder B.  That way, B won't even
know the full email address of the user.

Technically this wouldn't need to be hard at all, it's just the manual
requirement for key exchange that would be an issue for many people.

It is easy technically, but not politically.  In Europe, a
consent-exchange protocol would get some traction if it could replace
the tedious paperwork that Directive 95/46/EC requires.  For that,
we'd need the Art.29 Working Party to participate in an IETF Working
Group so as to standardize and bless that protocol at the same time.
Not an easy task.

-- 
http://fixforwarding.org/

_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg