Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)

david20_at_alpha2.mdx.ac.uk
Date: 10/07/03 

Date: Tue, 7 Oct 2003 01:01:11 +0000 (UTC)

In article <blrfs6$8l3$1@n.ruf.uni-freiburg.de>, gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann) writes:
>In article <blpfc4$ohi$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:
>>This isn't the case. The TSL/SSL encryption is between central mailhubs it
>>is NOT end to end encryption of a mail message content like for instance PGP or
>>SMIME. To the end users sending or receiving the mail message their is no
>>indication that it has been encrypted in it travels - the sender just sends the
>>message. If SPAM is passed to central mailhub A destined for a user served by
>>central mailhub B then it will be passed along the encrypted channel.
>
>Ok, I understand. But as long as SPAM is sent to mailhub A the spammer will
>have to pay and there is no need for an additional fee. This will work as long
>as most e-mails crossing the net are still terminated with a <CR>.<CR> .
>
I don't see this with your scheme. International net company A is not going to
detect such mail and hence won't charge anybody for it.

>>How is central mailhub A supposed to know it is SPAM ? Please define SPAM
>>in an unambigouous manner which every recipient would agree on ?
>
>Defining SPAM is a real problem. If it would be easy there would be no need to
>force fee-based e-mails. But if the sender or sending host of an e-mail has to
>pay for each message there will be no need any more for mailhub A to detect
>SPAM.
>
>>The way SMTP with TSL works is one of two ways :-
>
>Thanks for the explanation.
>
>>In both these cases no intervening system will find any packet containing
>><CR>.<CR> which signals the end of the mail message - it is conceivable
>>that it might pickup encrypted packet(s) not meaning the end of the message
>>containing amongst other things the string <CR>.<CR>
>
>[...]
>
>>As I said you could get around this by looking for connections to port 465,
>>the STARTTLS command and unencrypted mail. But that is rather messy.
>
>If we assume that most messages still have the <CR>.<CR> bytes there is time to
>develop a better technical solution for the e-mail fee. It looks as if it is
>still doable.
>
You have a little while but support for TSL/SSL is growing rapidly - a number
of freeware MTA's such as EXIM support it as well as commercial MTAs and
also Microsoft Exchange - though according to my PMDF manual their version
is "different" hence PMDF has to provide an additional configuration keyword if
you want to support TSL communication to Microsoft Exchange systems as well as
standards compliant systems.

David Webb
VMS and Unix team leader
CCSS
Middlesex University

>Regards,
> Christoph Gartmann
>
>--
> Max-Planck-Institut fuer Phone : +49-761-5108-464 Fax: -452
> Immunbiologie
> Postfach 1169 Internet: gartmann@immunbio dot mpg dot de
> D-79011 Freiburg, Germany
> http://www.immunbio.mpg.de/home/menue.html