SV: [cooperation-wg] SMTP forwarding in the face of Data Protection Directive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi
Yes, agree with you. The idea is a shortcoming.

My experience says me that law seldom originates from (the need of) individual users or a protocol, byt by legal tradition in the legislation, i.e. eventually, interpretation by 27 member state (MS) legislations will go before directive intentions.

This means -if understood correctly - that the data consent procedure is decided upon in each and every MS. In other words, rule may actually vary a bit, which from a protocol view just will make the situation worse.

Therefore, I agree with Jim Reid on this:
" But how these get enacted and enforced in national law differs from country to country."

When interpreting this directive into Swedish law, lawyers currently discuss the criterias for what make an 'active consent' just active. Can the automation of consents by protocols be a way to meet legislators demands on active consent? In the end, it's an interpretation if automation is enough, and we'll probably have a ruling in this by national court, eventually.


/Staffan

Cell phone: + 46/0 73 317 39 67
Mail: staffan.jonson at iis.se


- -----Ursprungligt meddelande-----
Från: cooperation-wg-admin at ripe.net [mailto:cooperation-wg-admin at ripe.net] För Alessandro Vesely
Skickat: den 18 maj 2011 20:56
Till: cooperation-wg at ripe.net
Ämne: [cooperation-wg] SMTP forwarding in the face of Data Protection Directive

Hi all,
can a tool for lawfully acquiring a user's consent via the Internet
motivate SMTP operators to modify their procedures in such a way that
spam can be countered more effectively?  Let me please expand slightly
on this question, I'll try and be concise.

It is well known that the Simple Mail Transfer Protocol provides for
replacing the envelope recipient with one or more other email
addresses.  This server forwarding is not to be confused with manually
forwarding a message from a client.  Mailing lists and newsletters are
operated that way, as well as redirection configured by means of "dot
forward" static files.  Since email addresses are personal data, their
processing is covered by Directive 95/46/EC.

How is the data subject's consent acquired?  In response to the Data
Protection Directive, operators should have defined a protocol for
obtaining and keeping proof of the consent.  It never happened.  In
facts, it is very difficult to introduce new protocols for email --new
protocols for web operations come about much more frequently.

Evidence that consent has been granted can be provided by the data
subject's mail exchanger (MX, a.k.a. the user's incoming mail server).
 It can digitally sign a notification from the data processor.  That
way, the user's server becomes aware of a new wanted stream of
messages, and can whitelist it.  That is, it can skip anti-spam
checking for those messages.  As bulk messages account for a
significant part of legitimate mail, anti-spam measures could then be
significantly strengthened.

The users' advantage is to have an automatically maintained list of
subscriptions, and a uniform interface to manage them.  Currently,
users have to interact with what can be called a "time-distributed
database", in the sense that monthly or yearly they may receive
subscription reminders...

The obvious shortcoming of this idea is that mail server operators
simply won't install any new software if their systems can work
acceptably well without it.  However, acquiring written consent is
such a pain to many businesses that, perhaps, they will install that
software if it helps complying with privacy issues.  What do you think?

TIA for any comment


-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBTdTCazQ/UxhHDVilAQj/uQf/diTT50upnSEEzdZ1xwl+noBR8LT0nc04
m/jZPZllSNO6TOCCpzMDt43Q5zxWbF/ur3f6q2w/tfvs6EFwRi+gZ3cUV1eX9HR6
iaAMjfMHADhmOCWDwew9aMRLsXZTCfBpzAtpjXCIHYTpfX8Oi1R+igKq4+74jpyV
V9Mpxm1V65KxpB6otxVJ4jDV4JlYVUP/zR8+h6FWuCf7m/851Fkg2BMqLUXGw1TF
Wmjf21ykxzOgLaqyrPOtWw3MyUBJA9Mg7+8irZyzLDxXUTlxWy1CBKY8U/F4u0gO
XP7vtsUtBfpmf8295amxYZ4UKfT7vC8sPWOupOxUFtDalnT3CCc2Iw==
=BzQY
-----END PGP SIGNATURE-----


-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/cooperation-wg/attachments/20110519/e65f9444/attachment.html>