Re: opt-out registry comments

William Stucke <[email protected]>
Newsgroups gmane.org.operators.ioz
Message-ID <CE47256D74A915449FA1A181FB094A6961B27A28@ICASASTNMB01.icasa.local>
Hi Bretton,

> So far we have my proposed costs for part of item 1, and a rough estimate of how long it takes to press delete. The rest is awfully complicated.

Indeed. Perhaps worse than you thought ;-)

The models below seem to (largely) look at the cost of spam from a consumer's point of view.

When looking at it from the Server's PoV, then other issues come into play. Specifically, including the interactions on the "standard port 25" with a Mail Server, the process can be roughly characterised as follows: -

1	Initial TCP 3-way handshake
2	Initiation of SMTP (Port 25) communication
3	Request to send message, passing headers to receiving MTA
4	Accept sender
5	Accept recipients
6	Accept of request
7	Transfer of data - "body" of message
8	Closing of session
9	Post-receipt message filtering
10	Delivery of message to mailbox.

Many anti-spam measures will either postpone (greylist) or refuse a connection at any of steps 1, 2, 3, 4, 5 and 6 above, before any actual message has been received. The "bandwidth cost" argument falls away in this case, as (usually) the average message body size >> message header size. 

Nevertheless, there is a finite limit to the number of simultaneous sessions that a specific machine (hardware, memory, OS, CPU and pipe combination) can handle, and exceeding this requires the purchase of "bigger iron" or maybe simply another machine. The same argument applies to the CPU-intensive post-processing stage, which may include Bayesian Filtering and virus scanning, for example.

While I would caution against attempting to include any kind of cost for "CPU cycles" when considering the end-user (what's his machine going to do when it's not processing spam? Run a screen saver?) it may be a valid cost at the server level - albeit as a crude step function which is poorly correlated with a specific cost-per-spam-message.

Because a large proportion of spam is rejected before step 6 in the model above (by Spam Assassin, ASSP, etc.), it's quite hard to quantify how much spam is actually received by the MTA, and the cost thereof on a per-message basis.

Even where the server-based anti-spam software used is "free" (Spam Assassin, ASSP, etc.), the cost of implementation and maintenance - man-hours - is significant. Back in the day when I used to do this for a teeny-weeny ISP, it took say 10 hours per month to do a fairly poor job of it. Large ISPs employ several people, full-time, just to look after their mail servers.

Consider: if 80% of all connection attempts are spam, then mail log files are 5 x larger than they would be without spam
If 90% of all connection attempts are spam, then log files are 10 times larger.
If 95% of all connection attempts are spam, then log files are 20 times larger.
If 98% of all connection attempts are spam, then log files are 50 times larger...

RICA obliges an ISP to store these log files for an extended period. Simply archiving them properly can take a lot of resources - maintenance time, disk space, etc.

BTW, a poster on (I think) Monday implied that ISPs "make money" from the customer receiving spam - presumably in terms of the minutely increased traffic paid for by the customer who's on a "capped" account. Maybe so, but overall, it's clear that spam is a significant cost to the ISP. What the ISP pays for, so does the consumer, eventually.

Kind regards,

William Stucke
ICASA Councillor
011-566-3009
[In my private capacity, as always]


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bretton Vine
Sent: 03 August 2011 01:12 AM
To: IOZ
Subject: Re: [IOZ] opt-out registry comments

On 2011/08/02 11:26 PM, Colin Alston wrote:
> Just because additional costs are unknown doesn't invalidate the 
> argument for bandwidth costs. The figures aren't represented as 
> anything more than bandwidth cost, and the model is simple - average 
> ingres spam per user * estimated users in SA * median size per message 
> * median cost.

So lets model the various scenarios that may apply.

1. just delete it

    (cost to receive spam) + (time to press delete)

    eg for 1 unsolicited email and 6 million recipients
       (6million*R0.00613) and (6million*1 second)
        = R36780 avg bandwidth charges and 69.44 days in sequential seconds
       or
        = R36780 avg bandwidth charges and 1'ish semi-parallel second

2. add to filters (manually or with levels of automation), then delete

    (time adding to filters) + (costs from 1.)

3. Report, filter, delete

    (time reporting spam to one or more entities) + (costs from 2.)

4. Unsubscribe, report, filter, delete

    (unsubscribe x number spam received, possibly with screenshots) +
    (costs from 3.)

5. complain on repeat spam after unsubscribe, report, filter, delete,

    (time spent lodging a complaint) + (costs from 4.)

6. Add yourself to a DNC list, get spam, unsubscribe, report, filter, delete

    (time adding addresses/numbers to 3rd party list) + (costs from 4.)

7. Buy an antispam solution, get false positives, lose a sale

   (cost of antispam) + (time spent diagnosing the problem) + (lost sale)

Any other models that apply?

How do we measure the cost of a person's time?
- do we use minimum wage?
- how do courts value a citizen's time? does it vary between say a doctor
  and a ward of the state?

How do we measure the cost of bandwidth?
- do we use what a consumer pays for 10mb increments of mobile data?
- do we use what TENET pays to Seacom to service a massive network?
- or the average/median cost to the consumer?

How do we measure the actual cost of spam in bandwidth?
- do we use average size * determined b/w cost?
- do we use overall size * determined b/w cost?

How do we cost antispam solutions?
- some are free, except for some time (eg spamassassin)
- others cost money

So far we have my proposed costs for part of item 1, and a rough estimate of how long it takes to press delete. The rest is awfully complicated.

--
Bretton
openpgp: http://bretton.hivemind.net/bretton_vine.asc

Co-existence / or no existence. - Piet Hein

_______________________________________________
IOZ mailing list
[email protected]
http://lists.internet.org.za/mailman/listinfo/ioz



_______________________________________________
IOZ mailing list
[email protected]
http://lists.internet.org.za/mailman/listinfo/ioz
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.