[cap-talk] charging for spam. What are the implications

Valerio Bellizzomi devbox at selnet.org
Thu Jan 25 15:14:27 CST 2007


On 25/01/2007, at 12.40, Rob Meijer wrote:

>On Thu, January 25, 2007 06:13, John McCabe-Dansted wrote:
>> On 1/25/07, Valerio Bellizzomi <devbox at selnet.org> wrote:
>>> >Most mail servers will deliver such mail to user devbox, but pass
>>> >   devbox+key819f6d46104b2a7acacb47ad9fc92438 at selnet.org
>>> >as the "to" address to the mail client.
>>> >
>>> >It is much easier to install new software on our own machine if we
>>> >don't have to upgrade all the servers we use first :)
>>>
>>> This requires a mail client that can interpret such address format,
>>> doesn't it ?
>>
>> Yes. And Ideally it would be integrated into your web-browser so that
>> whenever you are asked to submit your email address, you could easily
>> generate a new cap.
>>
>>> Perhaps this could be done with filtering rules,
>>
>> Yes. Sounds like a pain though.
>>
>>> issue: the mailman server will reject a message from this address
since
>>> it
>>> is not subscribed.
>>
>> If the mail client was semi-smart it could automatically use the same
>> +key  as the one that it received the subscription email on.
>
>It would be important to be able to bind both the From/Reply-To fields to
>a specific key.
>
>It would be interesting to as proof of concept patch an open source mail
>client to :
>
>A For outgoing e-mail:
>1) Preserve the key in reply e-mails.
>2) For outgoing mail that doesn'n meet 1, lookup the proper 'From' and
>  'Reply-T'o keys to use for (sets of) targets in a list of issued keys.
>3) For outgoing e-mail that doesn't meet either 1 or 2 use
>   key=digest(secret,targets,sequence) for the automatic creation of
>   keys for further outgoing e-mail to any distinctly new set of targets.
>   Store this key into the list of keys retrievable for both A2 and B1.
>
>B For incomming e-mail:
>1) Accept any incoming e-mail that uses a key found in the list of keys.
>2) Put all other mail into a NOTAUTHORIZED folder. (Dropping might be a
>   cleaner solution, but one that will scare of some people)

For B2 it could be made a selectable option in the mail client,
"Move to NOTAUTHORIZED folder" or "Drop".

>
>C Allow some way to 'revoke' a key resulting in:
>1) Send a notification to the original key-holders that their key is
being
>   revoked.
>2) Remove the key from the list of keys.
>
>If we could pick an open source project for this that would be open to
>include the patches in the main distro, this might well be worth the
>trouble.
>
>Rob
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk





More information about the cap-talk mailing list