Re: [Mailman-Users] The economics of spam
I would willingly pay a hundredth of a cent (or so) per email sent if
it would reduce spam to near-zero.
According to this study, $0.0001 per email sent would more than wipe
out the spammers' profit, but sending legit email to every one of my
couple-dozen Mailman lists would only cost about a dime. I wouldn't
even bother to pass that cost on to my customers.
:::: Every time I see an adult on a bicycle, I no longer despair for
the human race. - H.G. Wells ::::
:::: Jan Steinman, EcoReality <http://www.EcoReality.org> ::::
Jan Steinman writes:
I would willingly pay a hundredth of a cent (or so) per email sent if
it would reduce spam to near-zero.
Only problem is, you'll have to go to the bank and fill out the electronic funds transfer form for each $.00001 you pay.
Nanopayments are not a solved problem.
On 23 Dec 08, at 10:45, Stephen J. Turnbull wrote:
I agree that the banking industry is too horribly inefficient to
handle nanopayments. If they claim it costs them $25 to handle a
bounced cheque, I can't imagine what they'd claim it costs to accept a
$0.00001 payment. They've grown fat and lazy. Don't look to them for
any innovation that doesn't involve barely-legal Ponzi schemes.
Besides, individuals wouldn't be doing the payments, their providers
would. The key is SMTP servers -- THEY would be the ones that would
have to handle the accounting. And arguably, they might be the ones
receiving payment anyway, since they are the ones ultimately bearing
the cost. (I'd love to get $0.00001 for every spam my SMTP server
passes -- would much more than pay for the email all my customers send
out.)
So I think the key to nanopayments is to cut the banks right out of
the process. All of the accounting is already in SMTP -- you just have
to add billing and collection. Someone write it up as RFC 5821,
please? :-)
But this is getting way OT, and we aren't going to solve the problem
on this list.
:::: The reasonable man adapts himself to the world; the unreasonable
one persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw ::::
:::: Jan Steinman, EcoReality http://www.EcoReality.org ::::
Jan Steinman wrote:
And how does this work when the actual spam message is sent by a malware infected computer belonging to an arguably innocent user and is sent by direct SMTP to the recipient's MX?
Of course, if you're suggesting that there be some clearing house mechanism whereby no MTA accepts mail without a payer, that might work although I suspect the spammers will figure a way for someone else to pay the bill and the net effect will be to just require people like me to go through extra steps to set up a payment account.
Also, such a scheme is fraught with all the problems that currently affect SPF, DKIM, etc with forwarded mail.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, 2008-12-23 at 11:24 -0800, Mark Sapiro wrote:
Also, such a scheme is fraught with all the problems that currently affect SPF, DKIM, etc with forwarded mail.
It's always amazing to me that Internet e-mail works at all these days, what with spam, viruses, large software companies trying to dilute/pervert the standard, etc. That it still works is a testament to the technical wisdom and insight of the "founding fathers" (Gordon, Resnick, et al) who developed the RFCs on which it's based.
When a lot of people think of the Internet, they think of the web, but as an IPP I can tell you this. If someone's website goes down they call you and complain. If their email goes down they come looking for you with a rope and a lawyer! Fortunately, I've never had to deal with the latter.
-- Lindsay Haisley | "In an open world, | PGP public key FMP Computer Services | who needs Windows | available at 512-259-1190 | or Gates" | http://pubkeys.fmp.com http://www.fmp.com | |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 23, 2008, at 2:24 PM, Mark Sapiro wrote:
Bill the OS vendor of the infected machine. :)
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSVFCKnEjvBPtnXfVAQJaWwP/dFAasxAfhIa1Cw+niJ1asqEDilWBkpiO ymbcQyI4EL5ZsYBd1GftnOnimkigFuKCw5A1897T3LuTcmWd/BGcjqcU1CqsDzoS ARqZG9XQ99Jwfij9UbVci8Cel+FjYMys/DxuleWGwqb0u+OEHwkCk9iKsU0C1mNW dYbAtc0NWos= =UoLu -----END PGP SIGNATURE-----
Barry Warsaw writes:
Bill the OS vendor of the infected machine. :)
In my case that was Linus and Debian, although the fault belonged to the authors of Smail 3.1.100 who documented and parsed an option to deny all forwarding, but didn't implement it.
And the primary maintainer of a piece of software which AFAIK continues to be a source of backscatter might want to be a little careful about suggesting that vendors be billed ....
on 12/23/08 2:14 PM, Stephen J. Turnbull said:
We give the list owners and site administrator the option of choosing how to configure their lists. So, the choice of who to send the bill to would end there.
And to really solve the backscatter issue in this case would require that we integrate tightly enough into the MTA that the processing could be done while the sender is held open. The options in that space are mostly specific to a given MTA, although postfix also supports the sendmail milter interface in addition to the preferred policyd method.
If you wanted to be of service to the community, you could always write a milter in Python that would go through all the same checks that Mailman would do and indicate back to the MTA whether or not the message would be accepted.
-- Brad Knowles <brad@shub-internet.org> If you like Jazz/R&B guitar, check out LinkedIn Profile: my friend bigsbytracks on YouTube at <http://tinyurl.com/y8kpxu> http://preview.tinyurl.com/bigsbytracks
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 24, 2008, at 2:33 AM, Brad Knowles wrote:
Mailman 3 will also probably support LMTP as the default local
delivery mechanism, which I think will address the same issues.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iEYEARECAAYFAklSMFsACgkQ2YZpQepbvXHehQCfYvTn9DFyP5KUS93w/xKRiJPu MEEAniqBkukvZVHYe4kDrU6bl4RU9CdS =4YZz -----END PGP SIGNATURE-----
Brad Knowles writes:
Sorry, no. In a fair world that might be true, but in our world (at least the U.S.) there's the small problem of the legal concept called "attractive nuisance" and liability for future damages due to systems installed from past versions, not upgraded or configured appropriately.
So I don't think we even want to joke about financial penalties for spamming, because in the end it's applications like Mailman and this list itself that will end up as collateral damage in any such solution.
First I'd have to find out what those checks are, especially since in my own case a lot of mail gets discards by humans.
Economics is what I do for a living; giving free advice in the "dismal science" may be the best contribution I can make.
On Thu, 2008-12-25 at 00:06 +0900, Stephen J. Turnbull wrote:
Charging (someone) per email, while it's an attractive concept, seems to be kind of a technological mismatch. There are paradigms that can be associated with hard-copy paper mail that just don't apply to email. For instance, how do you deal appropriately with DSNs in such a system? How about mail addressed to "postmaster" which, by RFC, must be supported. Email has evolved more along the lines of the TCP/IP packet paradigm rather than that associated with postal hard-copy snail-mail. There are aspects of email that resemble ICMP packets far more than they resemble Christmas cards.
-- Lindsay Haisley | "It is better to bite | PGP public key FMP Computer Services | a single cannibal than | available at 512-259-1190 | to curse the doggies" | http://pubkeys.fmp.com http://www.fmp.com | -- John Day |
On 24 Dec 2008 at 11:11, Lindsay Haisley wrote:
I'm not sure these are fatal-flaw problems -- the hard-copy paper mail world *does* have sort-of equivalent processes. I don't understand exactly the problem with DSNs -- as I understand it, they are under the control of the sender and so the sender should pay [same as with the USPS: if you send stuff on the cheap, if it can't be delivered it is thrown away; if you pay more, they'll send you back an NDR. Why can't something similar fit into a server-to-server clearing? As for mail to postmaster, it must be supported but why must it be free? USmail to postmaster requires a stamp...
Actually, this is backwards. email *started* that way [remember that forwarding was provided for and there was even that cute explicit-routing form of email address] and has, IMO, evolved off into needing to be *more*like* Christmas cards.
/Bernie\
-- Bernie Cosell Fantasy Farm Fibers mailto:bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <--
Bernie Cosell writes:
I'm not sure these are fatal-flaw problems
They're not.
[same as with the USPS
Aye, there's the rub. The USPS is, even today, a state(-protected) monopoly. Email is not, and cannot be, unless you make the whole Internet a state monopoly.
Why, Lindsay, I'm shocked. I thought you didn't know the jargon!<wink>
Including a national monopoly email provider, I guess? What I interpret Lindsay to be saying is that for Christmas cards you can treat the USPS as a well-behaved black box (in the systems analysis sense; it may or may not do the job it claims to do at all well, but you can figure out what job it reliably does). In particular you can determine that a piece of mail was properly paid for by the addressee because each and every one has postage *attached*, not merely "accounted for" somewhere. This is not true for ICMP or for email as currently designed; there is no way to determine the provenance of a packet in general.
Sure, you can redesign email to require a secure, authenticated connection. But that's not the current design. Nor will a secure, authenticated connection that carries postage be acceptable in the market. Price competition will quickly drive postage actually paid to zero, and all that will happen is that the email network will become disconnected (as we are currently observing, anyway): a "backbone cabal" of email providers will evolve, and people with Linux boxes etc will set up wildcat SMTP networks along the lines of the old UUCP network.
Well, Comcast just blocked port 25 at my house and required to use port 587 for outgoing mail. I guess charging money per email is next?
port 25 is dead dropped to my non-comcast server as well. Also comcast rep writes: I have included the current list of blocked ports for you below:
67 68 135 137 138 139 445 512 520 1080
Al
----- Original Message ----- From: "Stephen J. Turnbull" <stephen@xemacs.org> To: "Bernie Cosell" <bernie@fantasyfarm.com> Cc: <mailman-users@python.org> Sent: Wednesday, December 24, 2008 8:29 PM Subject: Re: [Mailman-Users] The economics of spam
Alex writes:
Well, Comcast just blocked port 25 at my house and required to use port 587 for outgoing mail. I guess charging money per email is next?
No, why do you think that follows? Blocking port 25 simply means that you can't spam without going through Comcast. If they thought that charging money made sense, they'd simply charge you for throughput on that port, or maybe by the SYN packet.
Anyway, this is way off topic, and I'm going to shut up now on this list. If people have a more appropriate forum, I'd happily accept an invite.
Steve aka "Unwelcome Guest" :-) on alioth and /.
On Thu, 2008-12-25 at 10:29 +0900, Stephen J. Turnbull wrote:
To carry this analogy a bit further, here's an idea. IPv6 provides a substantial improvement in flexibility over IPv4, and the upgrade path from IPv4 to IPv6 is clear and relatively seamless. Would it not be possible to establish a dual-key cryptographic packet signature protocol for email sent using IPv6, applied at a packet level, and this signature could be authenticated against a private key, present only (or indicating) if the email sent using these packets has been been paid for?
For v4 systems behind a IPv6->IPv4 gateway the v6 wrapper would be stripped away and the encapsulated email would be delivered normally, along with all the spam sent to it. For SMTP servers that are truly v6-aware and running on a v6 network it would be possible to verify the payment signature contained in the packet extensions and discriminate between paid-for email and spam.
Perhaps the payment-autentication system could be developed in the context of a distributed database resembling that used for DNS, or more like DNSSEC, perhaps.
Piggybacking this SMTP extension on the top of the already robust IPv6 standard would provide the flexibility for system that were not IPv6 aware to opt out of the signature system and accept _all_ email. The logical key here is that it's up to the _originating_ SMTP system to obtain a cryptographic key and negotiate payment. It's up to the _receiving_ system to decide whether to discriminate between paid-for email and unpaid email, so as to reject it, pre-tag it, or deal with it in some other fashion with the (v4) default being to treat all inbound email as it's treated now.
This would not require a re-design of SMTP, only an extension of it.
If this were feasible, it would certainly spur the deployment of IPv6 which could stand a kick in the ass.
-- Lindsay Haisley |"Fighting against human | PGP public key FMP Computer Services | creativity is like | available at 512-259-1190 | trying to eradicate |<http://pubkeys.fmp.com> http://www.fmp.com | dandelions" | | (Pamela Jones) |
Lindsay Haisley writes:
I don't deny that technologically you could do this, but the question remains: who would actually pay?
Again, assuming that traffic patterns stay the same, this is all very nice for AOL, which would have a substantial positive balance of payments. But it would suck rotten eggs for open source projects, whose primary interaction with the mail system is to host mailing lists that on average must have tiny inward flow and significant outward flow.
Will traffic patterns stay the same? I think not. If AOL refuses mail without postage, delivery from my lists (not to mention from listmaster) to @aol.com addresses will stop. They can try to bill me, in which case they have no legal way to enforce since I haven't negotiated a contract with them. And I will simply unsubscribe all existing AOL addresses and bar them from subscribing in the future.
I don't know what will happen to Gmail, Hotmail, Yahoo, and other freemail services.
On 25 Dec 2008 at 12:41, Stephen J. Turnbull wrote:
This is wildly offtopic for this list and I, too, am going to stop prolonging it, but I'll just mention that this is the *CRUX* of the problem: what do you do if you want to let a "white hat" server that sends a million messages a month do so unencumbered but still somehow penalize/charge a "black hat" spamhaus.
I *THINK* that the folks here, earlier, said that they'd be willing to pay to have a global/overall email system that was essentially spam free, and that means that the 'white hat' folks running mailing lists would have to figure out what to do. There are three obvious choices [this no matter what scheme is used to set up pay-for-play]:
- be on a hosting server that out of the goodness of their hearts will eat the costs,
- have the list admins eat the cost [e.g., if SUN "bankrolls" the Java mailing list or something like that], or
- have the lists go to a subscription basis.
On (3), since we were proposing one-one-hundredth of a [US] cent per message, that means that for me to sign up for this list [what: a thousand messages a year?] it would cost me something like a dime a year to subscribe. I'd pay that.
This re-emphasizes that whatever criticisms you've made of various
schemes for effecting this kind of thing, you basically have a
fundamental philsophical refusal to accept the approach at all.
Basically, you *INSIST* that you be permitted to send your email for
free, regardless of the distributed costs. I don't see why email should
be free [and indeed, our experience with spammers would seem to indicate
that email-all-you-want-for-free is an idea that probably should have
died when NSF opened the net to outsiders]
/Bernie\
-- Bernie Cosell Fantasy Farm Fibers mailto:bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <--
on 12/24/08 11:12 PM, Bernie Cosell said:
This is wildly offtopic for this list and I, too, am going to stop prolonging it,
If you want to continue this conversation, try the IETF/IRTF Anti-Spam Research Group. John Levine has mentioned that everyone over there is going through the e-postal solution right now, and I'm sure you'd have plenty of other people to discuss the subject with.
-- Brad Knowles <brad@shub-internet.org> If you like Jazz/R&B guitar, check out LinkedIn Profile: my friend bigsbytracks on YouTube at <http://tinyurl.com/y8kpxu> http://preview.tinyurl.com/bigsbytracks
On 25 Dec 2008 at 10:29, Stephen J. Turnbull wrote:
Bernie Cosell writes:
What I was suggesting was not to model it on the USPS directly but on the *international* postal system. What I had in mind was the rough analog of considering each SMTP server as being sort-of a country-unto-itself and so settling its "international" email accounts with other SMTP servers in sort of the way the USPS and CanadaPost and RoyalMail and .. all do.
Right, and in my model I can treat *my* SMTP server as a well-behaved black box.
This is an unnecessary frill and a relic of the 1800s. All that's required is that the sending SMTP server and the receiving SMTP server keep accounts. But note that this is *exactly* what has to happen with international mail. CanadaPost doesn't [directly] get any of my 57cents [or whatever it is] when I send a letter from the US to Canada -- it is accounted for and the USPS [as I understand it] "banks" the extra 15 cents and then clears accounts with CanadaPost at some interval [annually?]. Nobody transfer "micropayments" across the border.
Not at all true. Email isn't transmitted by IP packets, it is transmitted by TCP connections from one SMTP server to another and so provenance isn't in question. A receiving SMTP server knows *exactly* which SMTP server is sending the message and could easily
- decide whether or not to accept the connection based on whether the sending-server was a "deadbeat" or not, and & 2) keep a record [that'd be matched by the outgoing logs at the sending SMTP server] of the traffic so that at some interval the two could rectify accounts.
Note that in what I was suggesting, the receiving SMTP server doesn't know or care what _individual_ sent the message, only that it came from SMTP-server-X. SMTP-server-X can decide how *IT* wants to pass on the cost of sending the message [or not!] to whomever *it* accepted the message from, be it one of their customers or some other SMTP server.
I doubt that. If google and AOL and just a few others refuse email from any SMTP server that doesn't have a transfer-account-in-good-standing, I doubt that the 'wildcatters' will get very far. I'm not convinced that the scheme will work, but it really doesn't require any changes in SMTP or required assured-authenications or micropayments or anything along those lines, and so it *might* work.
Note, too, that 'satellite' SMTP servers can play along if they choose : if I'm mycompany.com and I don't want the bother of having a lot of email transfer payment accounts with SMTP servers around the world, there's room for a "paypal" like enterprise: I sign up with them, I use *THEM* as a relaying-smtp server [basically exactly like the way individual customers use their ISP's outgoing SMTP server] and my "email paypal" would handle all of the accounts with the other SMTP servers and I could just settle with my 'relay' by whatever contractual arrangement I'd made.
/Bernie\
-- Bernie Cosell Fantasy Farm Fibers mailto:bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <--
On 23 Dec 2008 at 14:55, Barry Warsaw wrote:
Maybe, or the customer's ISP [which permitted the outgoing SMTP connection].
It is actually, I think, an interesting legal question: who should be responsible [in a get-sued way] for damages caused by [what is arguably] a user's negligence in the use of their computer? Or the vendor's negligence in selling a defective/toodangerous product? And not just for spam: what about the zombies in a bot net that cause *real* financial harm to a third party: should the owners of the infected machines bear any responsibility for the damage that's caused?
/Bernie\
-- Bernie Cosell Fantasy Farm Fibers mailto:bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <--
On 24 Dec 2008 at 3:45, Stephen J. Turnbull wrote:
My thought on this [from years ago -- I haven't pondered it much recently] was that using the international postal-service model would likely work; basically convert the problem from nanopayments between individuals to bulk payments between servers. The US and Canada don't tranfer back and forth to each other so many cents for each letter, they just aggregate them and come to a settlement in bulk.
What I think would work would be to have the *servers* keep cross- accounts of mail sent and received and the payments would only have to flow in the sent-more to sent-less direction and would only have to happen occasionally to balance the books. That would also leave open [and irrelevant in the large] how the various servers recouped those costs from their customers. If a particular server refused to pay their bill, you'd just refuse to accept any more email from them until they paid up.
/Bernie\
-- Bernie Cosell Fantasy Farm Fibers mailto:bernie@fantasyfarm.com Pearisburg, VA --> Too many people, too few sheep <--
On Tue, Dec 23, 2008 at 10:15:43AM -0800, Jan Steinman wrote:
I would willingly pay a hundredth of a cent (or so) per email sent if it would reduce spam to near-zero.
This is a thoroughly-discredited, utterly broken idea which, unfortunately, seems to keep coming back like a bad penny. It is based on the ludicrous notion that abusers -- who have consistently demonstrated themselves to be willing to spam, hijack computer systems, purloin ASNs, craft spyware, release viruses, send junk faxes, etc. -- will, for absolutely no reason whatsoever, suddenly and magically behave honestly and pay to send mail.
Please. Put a stake through the heart of this idiocy and let's not ever mention it again.
---Rsk
participants (10)
-
Alex
-
Barry Warsaw
-
Barry Warsaw
-
Bernie Cosell
-
Brad Knowles
-
Jan Steinman
-
Lindsay Haisley
-
Mark Sapiro
-
Rich Kulawiec
-
Stephen J. Turnbull