Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)
david20_at_alpha2.mdx.ac.uk
Date: 10/04/03
- Next message: John Johnstone: "Re: SMTP receiver logs"
- Previous message: Keith Parris: "Re: Sun takes a hit"
- In reply to: david20_at_alpha1.mdx.ac.uk: "Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)"
- Next in thread: david20_at_alpha2.mdx.ac.uk: "Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 3 Oct 2003 23:32:16 +0000 (UTC)
In article <bli3vb$92j$1@news.mdx.ac.uk>, david20@alpha2.mdx.ac.uk writes:
>In article <blhfnf$hak$1@n.ruf.uni-freiburg.de>, gartmann@non.immunbio.mpg.de.sens (Christoph Gartmann) writes:
>>In article <blh75m$t7p$1@news.mdx.ac.uk>, david20@alpha1.mdx.ac.uk writes:
>>>So your not charging for mail at all. Your just adding an extra premium on
>>>traffic charges for shipping a particular type of packet - whether it is
>>>part of a valid transaction, lost packet - about to be dropped when it's TTL
>>>runs out, retransmitted packet because it didn't arrive within the timeout
>>>period etc etc
>>
>>But in most cases this packet will be part of a successfully transmitted
>>e-mail.
>>
>>>You can get back maybe as far as the ISP on that basis. The ISP would have a
>>>hell of a job charging individual users on that basis.
>>>Individual user sent a mail message is understandable to the end user.
>>>Individual sent a packet - which then had to be retransmitted - so you pay for
>>>two mail messages isn't.
>>>
>>>So to cover itself the ISP increases it's monthly connection charge.
>>>The end user sees no difference - this has no effect on SPAM just increases
>>>connection charges up and down the line.
>>
>>This is true for a normal end-user but not for a spammer. I'm quite confident
>>that the ISP will charge every user that exceeds a certain mail limit. This
>>will happen in GB as well as in Brazil. This is what I want.
>>
>
>Sorry I doubt it will have any effect other than raising connection fees.
>
Just thought of another flaw with this approach of looking for <CR>.<CR>
packets.
Encryption. A fair number of systems are now encrypting the whole virtual
SMTP connection between their central mailhubs and any other central mailhubs
which support TLS/SSL with SMTP. Admittedly the number of systems currently
doing this is relatively small but it is growing.
Since the whole virtual connection is encrypted you cannot look into the
packets for a sequence such as <CR>.<CR>
Admittedly you might be able to get around this by looking instead for the
initial setting up of the encrypted channel but this gets messy as their
is more than one way of setting this up and you would also still need to be
looking for normal unencrypted smtp mail.
David Webb
VMS and Unix team leader
CCSS
Middlesex University
>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
- Next message: John Johnstone: "Re: SMTP receiver logs"
- Previous message: Keith Parris: "Re: Sun takes a hit"
- In reply to: david20_at_alpha1.mdx.ac.uk: "Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)"
- Next in thread: david20_at_alpha2.mdx.ac.uk: "Re: Fee Based Email (From Re: Process's PreciseMail AntiSpam...)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|