Authorized forwarding, was Microsoft takes over...

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:<[email protected]> [email protected]

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/