Challenge-Response Email Service With Email Aliases?
W
mechanism to fight spam, but which also allows you to create aliases. I
want to be able to assign one alias to a given web site that I sign up for,
and if they start to spam then I can shut down that alias without affecting
other services. I can also use that alias to identify the source of the
problem.
spamarrest.com does most of this, but they have the most insane
implementation of aliases I have ever seen, where creating an alias
automatically turns off the spam filtering for that alias. I need a vendor
that maintains the full spam protection for all of the aliases.
--
W
Sam
> I am looking for a web-based email service that uses a challenge-response
> mechanism to fight spam, but which also allows you to create aliases. I
I'm sure there are quite a few of them; however most of them are widely
blacklisted, because "challenge-response" is considered to be an abusive
practice, subject to getting blacklisted with no notice given.
> spamarrest.com does most of this, but they have the most insane
> implementation of aliases I have ever seen, where creating an alias
And, they're also widely blacklisted, to boot.
> automatically turns off the spam filtering for that alias. I need a vendor
> that maintains the full spam protection for all of the aliases.
You also need to understand that return addresses on spam is forged. And the
next time you get a shitload of these challenges clogging your mailbox, from
a bunch of idiots, because some spammer sent out a huge spam run, with your
return address forged on it, maybe then you'll finally understand why this
is considered abuse, and why spamarrest and other similar crap is widely
blacklisted.
David F. Skoll
> I am looking for a web-based email service that uses a challenge-response
> mechanism to fight spam,
Challenge-Response is evil. Stay away from it.
> but which also allows you to create aliases. I want to be able to
> assign one alias to a given web site that I sign up for, and if they
> start to spam then I can shut down that alias without affecting
> other services. I can also use that alias to identify the source of
> the problem.
What you are looking for is our product, CanIt-PRO. It lets you
create "locked addresses" that look something like this:
5jmsk7f...@la.roaringpenguin.com
The *very first* time the address receives mail, the system "locks on"
to the sender or the sender's domain, and then no-one else can use
the address (they all get a "User Unknown" error.) Because the address
locks on to the first sender, you don't need to know ahead of time
the address of the person who'll be mailing you. And because of the
locking action, the address can't be given away or sold --- it won't work
for any other senders.
We do have a hosted version of CanIt as well. (But you need to have your
own domain name). Please visit http://www.roaringpenguin.com/ for
details.
Regards,
David.
D. Stussy
news:qOKdneJWb-mvoVvX...@giganews.com...
> I am looking for a web-based email service that uses a challenge-response
> mechanism to fight spam, but which also allows you to create aliases. I
> want to be able to assign one alias to a given web site that I sign up
for,
> and if they start to spam then I can shut down that alias without
affecting
> other services. I can also use that alias to identify the source of the
> problem.
Let us know when you find one so we can all blacklist it up front.
Read the archives of this group from about 2003 regarding how bad C/R is.
Andrzej Adam Filip
> W wrote:
>
>> I am looking for a web-based email service that uses a challenge-response
>> mechanism to fight spam,
>
> Challenge-Response is evil. Stay away from it.
I can "at once" produce many ways to make C/R *less* evil.
I can also "at once" produce a way to make C/R no evil but it would kill
main C/R "advantage" that it can work with "any challenged mail reader".
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Woman's advice has little value, but he who won't take it is a fool.
-- Cervantes
Peter N. M. Hansteen
> I am looking for a web-based email service that uses a challenge-response
> mechanism to fight spam,
Seriously, you do not want a to set up yet another backscatter
generator. Some gentle advice at
http://bsdly.blogspot.com/2008/05/i-challenge-your-response-backscatterer.html
HTH, HAND.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
W
Since no one seems to favor challenge-response systems, let me change the
question: What are the best web-based email systems (forget the
challenge-response requirement) that offer:
1) Extremely good anti-spam filtering
2) The ability to create aliases under my control that I can then hand out
to different services I subscribe to. I need to be able to specify the
alias, not just generate one automatically. I do not want to lock the
alias down to a single sender, but might use the alias for all Internet
email from any sender on the subscription web site.
--
W
Chris Davies
> I can also "at once" produce a way to make C/R no evil but it would kill
> main C/R "advantage" that it can work with "any challenged mail reader".
I'm sure there are other people out there who refuse, point blank, to
respond to an email based challenge-response mechanism. No amount of
technology will get around this. C-R is bad. Don't do it.
Chris
Andrzej Adam Filip
It is all about precision:
C/R is an interesting idea but idea without acceptable implementations.
All implementations I know act too much as "redirectors of too big part
of received spam/trash". I can see no way to create acceptable C/R
implementation but I am not a genius ;-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Rascal, am I? Take THAT!
-- Errol Flynn
David F. Skoll
> C/R is an interesting idea
No, it's not. It's a boring and terrible idea.
> but idea without acceptable implementations.
An "acceptable" implementation of C/R does not exist. You can do a
thought experiment: In the limit case in which everyone used C/R, no-one
would be able to communicate with anyone else unless they pre-arranged
it out-of-band.
C/R works because a small percentage of users don't mind harming a large
percentage of other users. It's like the advantage a few louts get from
littering in the park, knowing someone else will clean up after them.
If everyone became loutish, however, the park would be destroyed.
-- David.
Gary R. Schmidt
no spam in that account. Allows for creating aliases under your initial
id, at some level, it has changed since I became a customer.
Cheers,
Gary B-)
Thor Kottelin
news:ca8f3$4ac9d96a$d1d97a75$32...@PRIMUS.CA...
> An "acceptable" implementation of C/R does not exist. You can do a
> thought experiment: In the limit case in which everyone used C/R,
> no-one
> would be able to communicate with anyone else unless they pre-arranged
> it out-of-band.
Without intending to dwelve further into what has, over the years, almost
become a religious war, I would like to point out, as a technical
observation, that automatic whitelisting of email recipients would avert
the issue mentioned in the above thought experiment.
In other words, when Alice sends a message to Bob, Alice's
challenge-response software should whitelist Bob's email address. Thus,
Alice should receive Bob's challenge (which should be sent "from" the
address to which Alice had sent her message).
The same and more could also be accomplished cryptographically if
implementors were to agree on such a framework.
--
Thor Kottelin
http://www.anta.net/
Andrzej Adam Filip
> "David F. Skoll" <d...@roaringpenguin.com> wrote in message
> news:ca8f3$4ac9d96a$d1d97a75$32...@PRIMUS.CA...
>
>> An "acceptable" implementation of C/R does not exist. You can do a
>> thought experiment: In the limit case in which everyone used C/R,
>> no-one
>> would be able to communicate with anyone else unless they pre-arranged
>> it out-of-band.
>
> Without intending to dwelve further into what has, over the years,
> almost become a religious war, I would like to point out, as a
> technical observation, that automatic whitelisting of email recipients
> would avert the issue mentioned in the above thought experiment.
>
> In other words, when Alice sends a message to Bob, Alice's
> challenge-response software should whitelist Bob's email
> address. Thus, Alice should receive Bob's challenge (which should be
> sent "from" the address to which Alice had sent her message).
So you have shown David how to overcome one of his objections via
"careful implementation". I agree with David anyway that there is more
than enough "not solved yet killing deficiencies" left :-)
> The same and more could also be accomplished cryptographically if
> implementors were to agree on such a framework.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
The older I grow, the less important the comma becomes.
Let the reader catch his own breath.
-- Elizabeth Clarkson Zwart
Chris Davies
> Actually, the best way to kill C-R is to respond to every challenge [...]
Sadly, this would end up satisfying the "well it works for me" brigade. At
least in the short term. Personally, I don't actually I receive much
C-R email; if I got much I'd endeavour to reject it at SMTP time.
Chris
D. Stussy
news:dwkmgqt...@michael.brudna.chmurka.net...
> Chris Davies <chris-...@roaima.co.uk> wrote:
> D> Andrzej Adam Filip <Andrze...@gmail.com> wrote:
> >> I can also "at once" produce a way to make C/R no evil but it would
kill
> >> main C/R "advantage" that it can work with "any challenged mail
reader".
> >
> > I'm sure there are other people out there who refuse, point blank, to
> > respond to an email based challenge-response mechanism. No amount of
> > technology will get around this. C-R is bad. Don't do it.
> >
> > Chris
>
> It is all about precision:
> C/R is an interesting idea but idea without acceptable implementations.
> All implementations I know act too much as "redirectors of too big part
> of received spam/trash". I can see no way to create acceptable C/R
> implementation but I am not a genius ;-)
There are NO acceptable implementations, nor will there ever be.
In order for a challenge to be meaningful, it must quote part of the
original message under challenge. Spammers can design their payload such
that whatever part is quoted, it will include a spam message. Therefore,
C/R becomes spam in its own right.
A challenge that does not quote part of the original message is
meaningless. Furthermore, challenges are issued by the final delivery
mailbox which need not be the same mailbox that the original sender sent to
(cf. forwarding). Without quoting the original message, the sender will
have no idea what message or which recipient has challenged. The challenge
will go unanswered and the mail eventually deleted. (All of this was said
on this very newsgroup in 2003.)
The major problem with C/R is that it hampers the delivery of LEGITIMATE
mail, while not really doing anything to slow down the spewing of spam.
Proper systems should hamper spam while not [significantly] interfering
with legitimate mail delivery. C/R harasses the wrong party.
Andrzej Adam Filip
Let's do step by step analyze of C/R
Main C/R objectives:
a) it indents to validate validity of email sender
b) it intends to check if sender mentioned in email really send the message
c) it may intend to do some trivial checks if the sender is a human
Main C/R drawbacks:
x) it may send Challenges to spam with faked sender
y) some senders may do not bother to reply to challenges
It's is the original recipient problem - we may ignore it.
A few years ago I ignored a few challenges to my "usenet triggered
help emails".
DKIM and "strong SPF" may reduce drawback "x" but they achieve
most of objectives "a" and "b" without using C/R.
The problem you have mentioned is caused by fact that original sender is
unaware of C/R used by the recipient. So it may be fixed by expecting
that sender is "aware" about recipient "special procedure" and starts
"mailing list subscription like" procedure to be able to reach the
recipient.
Feel free to criticize mailing lists subscription procedure
(triple handshake) :-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
The autodecrement is not magical.
-- Larry Wall in the perl man page
Sam
Doing that is not helpful, it would actually only serve to enhance the value
of C-R systems. The challenge gets trashed, the original spam that trigger
the challenge never gets delivered to the luser's mailbox, this is exactly
what a C-R system intends to happen.
To diminish the value of C-R, it is necessary to make it ineffective;
namely, to respond to all challenges, so that the original spam still gets
delivered to the luser's mailbox, lessening the effectiveness of C-R based
systems.
In many cases it's quite easy to turn a given C-R system against itself.
Large C-R systems, under the guise of lessening the burden of their abusive
behavior, send you a challenge only once. After it's acknowledged, your
email address is considered valid, and no more challenges will be sent even
for messages to the C-R system's users other than the first one that
triggered that challenge. As such, any future spam forging your address will
get immediately delivered to all C-R system's recipients, with no further
challenges.
David F. Skoll
> In other words, when Alice sends a message to Bob, Alice's
> challenge-response software should whitelist Bob's email address. Thus,
> Alice should receive Bob's challenge (which should be sent "from" the
> address to which Alice had sent her message).
You're assuming that Bob's challenges always originate from the email
address to which he prefers to receive email. This is not necessarily
the case (I can make a good argument that challenges should originate
from "<>".)
How do C/R systems handle DSNs? (Answer: They don't.)
How do C/R systems handle mailing list subscriptions? (Badly, if at all.)
There are legitimate reasons for automated mailings (cron job output,
monitoring-software alerts, etc.) all of which are hampered terribly
by C/R. You'd have to whitelist a whole bunch of addresses, and a
smart spammer would pretty quickly figure out that faking mail from
"ro...@mail.example.org" is likely to work.
> The same and more could also be accomplished cryptographically if
> implementors were to agree on such a framework.
Unlikely. Lots of people have considered C/R for years, and no-one's
come up with a good implementation. I don't think it's possible.
-- David.
Andrzej Adam Filip
> [...] Lots of people have considered C/R for years, and no-one's
> come up with a good implementation. I don't think it's possible.
I do fully I agree with the above but it does not make me SURE it is
impossible for every genius worldwide :-)
P.S.
My statement that it is "an interesting idea" does NOT mean
"a few last glitches to remove before worldwide implementation",
it merely means that it is interesting to think about why it has looked
almost like FUSSP and maybe to "reuse" some ideas in it in another solution.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Some of us are becoming the men we wanted to marry.
-- Gloria Steinem
D. Stussy
> ...
> Main C/R drawbacks:
> x) it may send Challenges to spam with faked sender
> y) some senders may do not bother to reply to challenges
> It's is the original recipient problem - we may ignore it.
> A few years ago I ignored a few challenges to my "usenet triggered
> help emails".
You missed the most significant drawback: A C/R system can be tricked into
becomming the actual spam delivery system.
The spammer sends to a C/R system with the source address forged to be the
actual recipient of the spam. The spammer has already tested that C/R
system and knows in what part of his message he must place his spam payload
for it to be copied into the challenge message. When the C/R system sends
the challenge, it is sending the actual spam.
I said that on this group back in 2003 also. Look it up.
Andrzej Adam Filip
For me it is covered by my "x", you prefer to describe it in a more
detailed, sinister and correct way :-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Every man thinks God is on his side. The rich and powerful know that he is.
-- Jean Anouilh, "The Lark"
D. Stussy
> Thor Kottelin wrote:
> > In other words, when Alice sends a message to Bob, Alice's
> > challenge-response software should whitelist Bob's email address. Thus,
> > Alice should receive Bob's challenge (which should be sent "from" the
> > address to which Alice had sent her message).
>
> You're assuming that Bob's challenges always originate from the email
> address to which he prefers to receive email. This is not necessarily
> the case (I can make a good argument that challenges should originate
> from "<>".)
Challenges cannot originate from envelope sender <> because such cannot be
responded to, with the exception of challenges that use a "Reply-To" header
(of which no one has ever mentioned that any C/R implementation does this).
> How do C/R systems handle DSNs? (Answer: They don't.)
Of course not. There's no place to send the challenge, at least not with
using the envelope sender as the challenge destination.
> How do C/R systems handle mailing list subscriptions? (Badly, if at
all.)
Presumedly, just like any other message: If not whitelisted, the challenge
gets sent to the list administrator.
> There are legitimate reasons for automated mailings (cron job output,
> monitoring-software alerts, etc.) all of which are hampered terribly
> by C/R. You'd have to whitelist a whole bunch of addresses, and a
> smart spammer would pretty quickly figure out that faking mail from
> "ro...@mail.example.org" is likely to work.
>
> > The same and more could also be accomplished cryptographically if
> > implementors were to agree on such a framework.
>
> Unlikely. Lots of people have considered C/R for years, and no-one's
> come up with a good implementation. I don't think it's possible.
It has already been proven that it is impossible to have a "good"
implementation of C/R.
D. Stussy
> "D. Stussy" <spam+ne...@bde-arc.ampr.org> wrote:
> > "Andrzej Adam Filip" <Andrze...@gmail.com> wrote in message
> > news:ga0w11c...@michael.brudna.chmurka.net...
> >> ...
> >> Main C/R drawbacks:
> >> x) it may send Challenges to spam with faked sender
> >> y) some senders may do not bother to reply to challenges
> >> It's is the original recipient problem - we may ignore it.
> >> A few years ago I ignored a few challenges to my "usenet triggered
> >> help emails".
> >
> > You missed the most significant drawback: A C/R system can be tricked
> > into becomming the actual spam delivery system.
> >
> > The spammer sends to a C/R system with the source address forged to be
> > the actual recipient of the spam. The spammer has already tested that
> > C/R system and knows in what part of his message he must place his
> > spam payload for it to be copied into the challenge message. When the
> > C/R system sends the challenge, it is sending the actual spam.
> >
> > I said that on this group back in 2003 also. Look it up.
>
> For me it is covered by my "x", you prefer to describe it in a more
> detailed, sinister and correct way :-)
No, it's not. The original message itself isn't meant to be spam. It is
configured such that the challenge message becomes the spam. The
difference is that the original message isn't designed to necessarily be a
"human readable" spam message that can stand on its own as such. Its sole
purpose is to place the spam message into the challenge. Your case "x" is
when C/R responds to spam that is meant to be human readable.
David F. Skoll
> "David F. Skoll" <d...@roaringpenguin.com> wrote in message
>> You're assuming that Bob's challenges always originate from the email
>> address to which he prefers to receive email. This is not necessarily
>> the case (I can make a good argument that challenges should originate
>> from "<>".)
> Challenges cannot originate from envelope sender <> because such cannot be
> responded to, with the exception of challenges that use a "Reply-To"
> header (of which no one has ever mentioned that any C/R implementation
> does this).
Well, they can't be responded to using e-mail. But almost all C/R systems
require you to click on a link to respond. Using <> for those challenges
is fine (well, "fine" modulo the understanding that C/R is fundamentally wrong.)
-- David.
Thor Kottelin
> Thor Kottelin wrote:
>
>> In other words, when Alice sends a message to Bob, Alice's
>> challenge-response software should whitelist Bob's email address. Thus,
>> Alice should receive Bob's challenge (which should be sent "from" the
>> address to which Alice had sent her message).
>
> You're assuming that Bob's challenges always originate from the email
> address to which he prefers to receive email. This is not necessarily
> the case (I can make a good argument that challenges should originate
> from "<>".)
Yes, notification messages such as challenges should be sent using a null
reverse-path.
However, for the reason stated above, the "From:" address should be the
one to which the original message was sent. I do not assume that this
would be the case; rather, I note that it should be the case.
Chris Davies
> Challenges cannot originate from envelope sender <> because such cannot be
> responded to, with the exception of challenges that use a "Reply-To" header
> (of which no one has ever mentioned that any C/R implementation does this).
Seems to me you're mixing up envelope and header from? Surely the point
of a C/R is that it requires a person to respond, at which point the MUA
replies to the header from rather than the envelope from. Undeliverables
get sent to the envelope from (or in this case, discarded because
it's <>).
Chris
D. Stussy
Which breaks another tenant - NEVER click on a link in an e-mail unless the
sender is well known to the recipient. (If the original sender is getting
a challenge, it's obvious that the two parties don't really know each
other, else the mail would have bypassed C/R via a local whitelist.)
D. Stussy
news:6knsp6x...@news.roaima.co.uk...
I'm not mixing them up. "<>" is valid only as an envelope from.
D. Stussy
news:ZVNym.25314$La7....@uutiset.elisa.fi...
...And when the original recipient was (or included) a non-whitelisted
mailing list, but the challenge is from recipients on the list, not the
list gateway itself, one gets challenge responses to the entire list. If
more than one recipient had C/R, this could declare to some recipients an
invalid response that will throw out the original message.
Thor Kottelin
news:hag5s2$9pl$1...@snarked.org...
> Challenges cannot originate from envelope sender <> because such cannot
> be
> responded to, with the exception of challenges that use a "Reply-To"
> header
> (of which no one has ever mentioned that any C/R implementation does
> this).
The envelope sender is irrelevant in terms of replies from message
recipients. Challenges sent using a null reverse-path can indeed be
normally replied to. The default addresses to reply to are the ones on the
"Reply-To:" line, if such a line exists; if one does not exist, the
default addresses to reply to are the ones on the "From:" line.
'If the "Reply-To" field exists, then the reply should go to the
addresses indicated in that field and not to the address(es) indicated in
the "From" field. If there is a "From" field, but no "Reply-To" field,
the reply should be sent to the address(es) indicated in the "From"
field.' - RFC 822, section 4.4.4
'When the "Reply-To:" field is present, it indicates the address(es) to
which the author of the message suggests that replies be sent. In the
absence of the "Reply-To:" field, replies SHOULD by default be sent to the
mailbox(es) specified in the "From:" field unless otherwise specified by
the person composing the reply.' - RFC 5322, section 3.6.2
David F. Skoll
> The envelope sender is irrelevant in terms of replies from message
> recipients. Challenges sent using a null reverse-path can indeed be
> normally replied to. The default addresses to reply to are the ones on the
> "Reply-To:" line, if such a line exists; if one does not exist, the
> default addresses to reply to are the ones on the "From:" line.
Think for a minute about the effectiveness of a C/R system that
allows a simple "Reply" as a response. Such a system could be
trivially broken.
A C/R system, to be effective, must have the recipient of the challenge
do something more... um... "challenging" than just replying, such as
clicking a link to a web site (trivial to automate) or answering a
question or something.
Having quite a bit of experience with end-users of email, I can tell you
that probably 90% of people won't bother (or indeed know how) to respond
to a challenge that's not trivially automatable.
Whitelisting recipients of mail that *you* send solves part of the
problem, but by no means all. Maybe I receive mail at "dfs" and "dave",
but prefer to send from "dfs". Maybe I want to send email to
"in...@example.com" but don't particularly want to whitelist that address.
Maybe I'm on the road and need to send email from a system that lacks access
to my automatic-outgoing-mail-whitelister.
-- David.
Thor Kottelin
> Thor Kottelin wrote:
>
>> The envelope sender is irrelevant in terms of replies from message
>> recipients. Challenges sent using a null reverse-path can indeed be
>> normally replied to. The default addresses to reply to are the ones on
>> the
>> "Reply-To:" line, if such a line exists; if one does not exist, the
>> default addresses to reply to are the ones on the "From:" line.
>
> Think for a minute about the effectiveness of a C/R system that
> allows a simple "Reply" as a response. Such a system could be
> trivially broken.
Perhaps, but has anyone in this thread suggested that a reply would
qualify as a response in the challenge-response sense, i.e. one that would
release quarantined mail?
What I have seen discussed is whether Bob would be able to receive a
challenge that Alice's system would have sent as a reply to a challenge
sent by Bob's system.
> Whitelisting recipients of mail that *you* send solves part of the
> problem, but by no means all. Maybe I receive mail at "dfs" and "dave",
> but prefer to send from "dfs". Maybe I want to send email to
> "in...@example.com" but don't particularly want to whitelist that
> address.
> Maybe I'm on the road and need to send email from a system that lacks
> access
> to my automatic-outgoing-mail-whitelister.
I agree. These are rather universal issues with spam filters employing
whitelisting of mail recipients.
D. Stussy
> "David F. Skoll" <d...@roaringpenguin.com> wrote in message
> news:d9ffb$4acbf49e$d1d97a75$14...@PRIMUS.CA...
> > Thor Kottelin wrote:
> >
> >> The envelope sender is irrelevant in terms of replies from message
> >> recipients. Challenges sent using a null reverse-path can indeed be
> >> normally replied to. The default addresses to reply to are the ones on
> >> the
> >> "Reply-To:" line, if such a line exists; if one does not exist, the
> >> default addresses to reply to are the ones on the "From:" line.
> >
> > Think for a minute about the effectiveness of a C/R system that
> > allows a simple "Reply" as a response. Such a system could be
> > trivially broken.
>
> Perhaps, but has anyone in this thread suggested that a reply would
> qualify as a response in the challenge-response sense, i.e. one that
would
> release quarantined mail?
That's how the first C/R systems worked - by accepting an e-mail reply.
Out-of-band (not SMTP) response systems came later.
> What I have seen discussed is whether Bob would be able to receive a
> challenge that Alice's system would have sent as a reply to a challenge
> sent by Bob's system.
>
> > Whitelisting recipients of mail that *you* send solves part of the
> > problem, but by no means all. Maybe I receive mail at "dfs" and
"dave",
> > but prefer to send from "dfs". Maybe I want to send email to
> > "in...@example.com" but don't particularly want to whitelist that
> > address.
> > Maybe I'm on the road and need to send email from a system that lacks
> > access
> > to my automatic-outgoing-mail-whitelister.
>
> I agree. These are rather universal issues with spam filters employing
> whitelisting of mail recipients.
That problem (and that of forwarding, thus not whitelisting the final
address) is another problem of C/R.
D. Stussy
> "David F. Skoll" <d...@roaringpenguin.com> wrote in message
> news:ca8f3$4ac9d96a$d1d97a75$32...@PRIMUS.CA...
> > An "acceptable" implementation of C/R does not exist. You can do a
> > thought experiment: In the limit case in which everyone used C/R,
> > no-one
> > would be able to communicate with anyone else unless they pre-arranged
> > it out-of-band.
>
> Without intending to dwelve further into what has, over the years, almost
> become a religious war, I would like to point out, as a technical
> observation, that automatic whitelisting of email recipients would avert
> the issue mentioned in the above thought experiment.
>
> In other words, when Alice sends a message to Bob, Alice's
> challenge-response software should whitelist Bob's email address. Thus,
> Alice should receive Bob's challenge (which should be sent "from" the
> address to which Alice had sent her message).
Whitelisting challenge recipients opens up the mailbox protected by C/R to
spam from that recipient as it must accept mail from that source in order
to receive the response to the challenge.
That's why your logic above fails.
Thor Kottelin
>> when Alice sends a message to Bob, Alice's
>> challenge-response software should whitelist Bob's email address. Thus,
>> Alice should receive Bob's challenge (which should be sent "from" the
>> address to which Alice had sent her message).
>
> Whitelisting challenge recipients opens up the mailbox protected by C/R
> to
> spam from that recipient as it must accept mail from that source in
> order
> to receive the response to the challenge.
>
> That's why your logic above fails.
Do you mean the threat of a third party being able to determine the
addresses to which Alice recently would have sent mail (and that therefore
could be successfully used as falsified sender addresses)?
D. Stussy
No, although that would be included. I mean spam from the sender under
challenge, if the response is expected via SMTP.
Thor Kottelin
Bob's C/R software should expect a response in a specified format, e.g.
including a predetermined token. Such a response would be processed
automatically. Any other mail from Alice would be held pending a
successful response to Bob's initial challenge.
This means that Bob's mailbox would only see mail from Alice after she
would have responded to the challenge. Granted, Alice could respond and
still be a spammer, but this is not a threat C/R in itself professes to
protect against.
The biggest problem with C/R probably remains Alice receiving challenges
based on falsified sender information.
Bill Gunshannon
I have been reading the Challenge/Response Email discussion with
interest. Now, I have decided to ask a different but, I think,
related question.
We all know one of the biggest problems with the current eamil
system is the fact that, basicly, any machine on the INTERNET
can be an MTA and thus spew garbage into the system. Many moons
ago we had what must be seen as the ultimate "white list" system.
UUCP Mail. Mail was only exchanged between sites that agreed
ahead of time to do so. Why has a return to such a system not
been considered lately as a possible solution (or at least as
a way to greatly reduce not only the total quantity of spam
but also the cost involved in dealing with it). It seems that
the disadvantages of the UUCP Email system are no longer relevant
and it offers one major advantage. Spamming is not a technical
problem, it is a social problem and this system offers the ability
to use a social solution to solve it.
Anyone interested in discussing this?
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Mark Hobley
> Anyone interested in discussing this?
I am thinking that we need some type of postage stamp system, whereby a
recipient issues digital stamps to a trusted post office. A post office can
filter out any messages that do not have the stamps attached. A sender wishing
to obtain a stamp, must present an electronic identity card signed by an
authority trusted by the intended recipient. The recipient can issue stamps to
a "post office" of their choice, and the sender has to present their identity
to the recipients chosen "post office" in order to obtain the stamps.
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
D. Stussy
You assume that C/R has a proper design to prevent messages other than the
response from being delivered. There are many broken implementations out
there.
> The biggest problem with C/R probably remains Alice receiving challenges
> based on falsified sender information.
And as previously demonstrated in 2003, for the challenge to be meaningful,
it must quote some part of the original message, which means that any
spammer can craft his spew to be echoed by the challenge itself -- thus the
challenge itself delivers the spam and the C/R system is an open spammer
relay.
W
news:ci0647-...@neptune.markhobley.yi.org...
What Internet email badly needs is rational economics. Charge one penny
for every email sent. That one step alone would reduce the volume of spam
by 95%. Any time you make any resource FREE, it gets abused. Give that
resource's use any kind of rational economic cost, and the cost alone
regulates the use. Even hardcore email fanatics do not send more than 200
emails a day. That's $2, or $60/month. That's hardly going to spoil the
Internet for any legitimate user.
A spammer who sends 100 million spams per day in order to make $1K isn't
going to want to pay 1 million dollars to send those outgoing emails.
Economics alone will dictate that only higher quality advertising directed
to more targeted recipients would be able to afford the cost of the resource
at one penny per email.
--
W
Bill Gunshannon
"W" <persis...@spamarrest.com> writes:
> "Mark Hobley" <markh...@hotpop.donottypethisbit.com> wrote in message
> news:ci0647-...@neptune.markhobley.yi.org...
>> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
>> > Anyone interested in discussing this?
>>
>> I am thinking that we need some type of postage stamp system, whereby a
>> recipient issues digital stamps to a trusted post office. A post office
> can
>> filter out any messages that do not have the stamps attached. A sender
> wishing
>> to obtain a stamp, must present an electronic identity card signed by an
>> authority trusted by the intended recipient. The recipient can issue
> stamps to
>> a "post office" of their choice, and the sender has to present their
> identity
>> to the recipients chosen "post office" in order to obtain the stamps.
>
> What Internet email badly needs is rational economics. Charge one penny
> for every email sent. That one step alone would reduce the volume of spam
> by 95%.
Which, once again, punishes the legitimate users and not the spammers.
> Any time you make any resource FREE, it gets abused.
Care to provide more examples taht support this allegation? I can think
of a lot of things that are free but not abused.
> Give that
> resource's use any kind of rational economic cost, and the cost alone
> regulates the use.
Regulate? Yes, it would. First thing to go would be any legitimate
mailing lists. Of course, this has been discussed before and I can
even remember when the ISP's wanted to charge for traffic as well.
It didn't fly then and no one is going to buy into it now. Except
maybe for the people who would be collecting all those pennies.
> Even hardcore email fanatics do not send more than 200
> emails a day. That's $2, or $60/month. That's hardly going to spoil the
> Internet for any legitimate user.
I certainly wouldn't pay it. And, if the cost is so low that it would
not effect ordinary users then it certainly won't stop spammers who can
write it off their taxes as a business expense. And, you do realize
that this would legitimize spamming and still leave the burden on you to
sort thru all the junk trying to find that one legitimate email that
you actually want to see. Once again, punish the victim by putting
more work, expense and wasted time in their hands.
>
> A spammer who sends 100 million spams per day in order to make $1K isn't
> going to want to pay 1 million dollars to send those outgoing emails.
> Economics alone will dictate that only higher quality advertising directed
> to more targeted recipients would be able to afford the cost of the resource
> at one penny per email.
There is no "higher quality advertising", spam is spam. And none of it
is "directed to more targeted recipients" it is flooded to the world and
the only way to stop it is by not allowing it in the first place. My
proposal goes straight to that as the first ones affected are all the
personal machines being used by spammers for sending their junk. ISP's
could stop this in seconds but have chosen to not do anything about it.
The other advantage of my system is it doesn't necessarily eliminate the
existing system. People will be free to continue to receive all the junk
the flows across the INTERNET today but, the ability to segregate real
email from potential junk increases dramatically. And, the system can
phase in (actually, back in) with no disruption to to the exiasting
system. Not only does it not cost the end-user anything, it has the
potential to reduce the amount of time spent by email sysadmins trying
to fight spam resulting in real cost savings.
D. Stussy
news:7tfvo3...@mid.individual.net...
I agree. However, what if the first 100 distinct recipients (not messages)
in a 24 hour period were exempt? There is always a way to figure out a way
to accomodate low volume users. Even if one forwards "chain jokes" (i.e.
jokes that propagate like chain letters), the non-spammer could probably
avoid the limit easily. Precise values can always be adjusted. The issue
here is that spammers need to send to many more mailboxes than any
legitimate user ever would in a short time period.
> ...
> > Even hardcore email fanatics do not send more than
200
> > emails a day. That's $2, or $60/month. That's hardly going to spoil
the
> > Internet for any legitimate user.
>
> I certainly wouldn't pay it. And, if the cost is so low that it would
> not effect ordinary users then it certainly won't stop spammers who can
> write it off their taxes as a business expense. And, you do realize
> that this would legitimize spamming and still leave the burden on you to
> sort thru all the junk trying to find that one legitimate email that
> you actually want to see. Once again, punish the victim by putting
> more work, expense and wasted time in their hands.
"A tax write off?" Not in places where spamming is illegal. In the U.S.,
26 U.S.C 162(c)(2) [Internal Revenue Code] denies a deduction which
represents a payment for an illegal act. 162(f) denies a deduction for any
government-imposed fine or penalty. So what writeoff do you think they
get?
> > A spammer who sends 100 million spams per day in order to make $1K
isn't
> > going to want to pay 1 million dollars to send those outgoing emails.
> > Economics alone will dictate that only higher quality advertising
directed
> > to more targeted recipients would be able to afford the cost of the
resource
> > at one penny per email.
>
> There is no "higher quality advertising", spam is spam. And none of it
> is "directed to more targeted recipients" it is flooded to the world and
> the only way to stop it is by not allowing it in the first place. My
> proposal goes straight to that as the first ones affected are all the
> personal machines being used by spammers for sending their junk. ISP's
> could stop this in seconds but have chosen to not do anything about it.
> The other advantage of my system is it doesn't necessarily eliminate the
> existing system. People will be free to continue to receive all the junk
> the flows across the INTERNET today but, the ability to segregate real
> email from potential junk increases dramatically. And, the system can
> phase in (actually, back in) with no disruption to to the exiasting
> system. Not only does it not cost the end-user anything, it has the
> potential to reduce the amount of time spent by email sysadmins trying
> to fight spam resulting in real cost savings.
I think both of you have missed he mark. Correct that a spammer won't
necessarily have $1M on hand to pay for 100M emails at $0.01/each, but
that's why they have botnets and such. All they have to do is hack and
compromise more machines and mail accounts across which to spread the load,
or create a massive number of junk mailboxes to send with and stay under
the quota. If less than 100 messages/day are sent per account, do you
think it will be easy for any mailbox provider to detect all 1M accounts
controlled by a spammer, especially when connecting via multiple addresses
(botnets or dyanmic assignments)? How is that different from a travelling
person from the ISP's knowledge?
Bill Gunshannon
Who is going to implement it? Who is going to bear the cost of
administering it? What will stop the spammers from sending 100
messages from each of the 1 million zombied machines they run?
What about a mailing list with more than 100 subscribers (like
The Risks Digest)?
> There is always a way to figure out a way
> to accomodate low volume users. Even if one forwards "chain jokes" (i.e.
> jokes that propagate like chain letters), the non-spammer could probably
> avoid the limit easily. Precise values can always be adjusted. The issue
> here is that spammers need to send to many more mailboxes than any
> legitimate user ever would in a short time period.
And no currently existing email system is capable of implementing
this plan.
>
>> ...
>> > Even hardcore email fanatics do not send more than
> 200
>> > emails a day. That's $2, or $60/month. That's hardly going to spoil
> the
>> > Internet for any legitimate user.
>>
>> I certainly wouldn't pay it. And, if the cost is so low that it would
>> not effect ordinary users then it certainly won't stop spammers who can
>> write it off their taxes as a business expense. And, you do realize
>> that this would legitimize spamming and still leave the burden on you to
>> sort thru all the junk trying to find that one legitimate email that
>> you actually want to see. Once again, punish the victim by putting
>> more work, expense and wasted time in their hands.
>
> "A tax write off?" Not in places where spamming is illegal. In the U.S.,
> 26 U.S.C 162(c)(2) [Internal Revenue Code] denies a deduction which
> represents a payment for an illegal act. 162(f) denies a deduction for any
> government-imposed fine or penalty. So what writeoff do you think they
> get?
If you create the concept of sending email for a fee you will not be able
to deny use of it to spammers. You will, in effect, give them legality
as long as they pay for it. And they can then write it off as a legitimate
business expense. Or have you forgotten "junk mail"? I don't want it
and I certainly don't like the idea that I pay a higher price for postage
to subsidize it. And, I have to pay to dispose of all that junk paper.
But you can't stop it and the USPS has to deliver it.
>
>> > A spammer who sends 100 million spams per day in order to make $1K
> isn't
>> > going to want to pay 1 million dollars to send those outgoing emails.
>> > Economics alone will dictate that only higher quality advertising
> directed
>> > to more targeted recipients would be able to afford the cost of the
> resource
>> > at one penny per email.
>>
>> There is no "higher quality advertising", spam is spam. And none of it
>> is "directed to more targeted recipients" it is flooded to the world and
>> the only way to stop it is by not allowing it in the first place. My
>> proposal goes straight to that as the first ones affected are all the
>> personal machines being used by spammers for sending their junk. ISP's
>> could stop this in seconds but have chosen to not do anything about it.
>> The other advantage of my system is it doesn't necessarily eliminate the
>> existing system. People will be free to continue to receive all the junk
>> the flows across the INTERNET today but, the ability to segregate real
>> email from potential junk increases dramatically. And, the system can
>> phase in (actually, back in) with no disruption to to the exiasting
>> system. Not only does it not cost the end-user anything, it has the
>> potential to reduce the amount of time spent by email sysadmins trying
>> to fight spam resulting in real cost savings.
>
> I think both of you have missed he mark.
I haven't missed anything.
> Correct that a spammer won't
> necessarily have $1M on hand to pay for 100M emails at $0.01/each, but
> that's why they have botnets and such. All they have to do is hack and
> compromise more machines and mail accounts across which to spread the load,
> or create a massive number of junk mailboxes to send with and stay under
> the quota. If less than 100 messages/day are sent per account, do you
> think it will be easy for any mailbox provider to detect all 1M accounts
> controlled by a spammer, especially when connecting via multiple addresses
> (botnets or dyanmic assignments)? How is that different from a travelling
> person from the ISP's knowledge?
Don't know, but it also has nothing to do with my suggestion which is
to revive UUCP Mail. The one thing that UUCP Mail had that none of the
current systems have is the upfront agreement between MTA's to exchange
email with each other. Which also allows for the setting of legally
binding groundrules up front as well. And, probbably the biggest advantage
this berings to the whole email system is the total elimination of zombied
machines. It doesn't matter how many machines you can zombie if no one
accepts their email.
D. Stussy
I addressed much of this below in the post you quoted.
As for mailing lists, that counts as ONE recipient as the person sends to
the LIST address. Obviously, where the list is expanded, the ISP covering
the list would be aware of it, etc.... Since their recipient list remains
roughly constant and is generally by request (i.e. signups), they would be
afforded different treatment.
> > There is always a way to figure out a
way
> > to accomodate low volume users. Even if one forwards "chain jokes"
(i.e.
> > jokes that propagate like chain letters), the non-spammer could
probably
> > avoid the limit easily. Precise values can always be adjusted. The
issue
> > here is that spammers need to send to many more mailboxes than any
> > legitimate user ever would in a short time period.
>
> And no currently existing email system is capable of implementing
> this plan.
You asked for an idea. You got one. It IS possible. You just don't want
to do the work.
I ask again: Write-off how? Spamming is illegal in the U.S. Illegal
professions are denied business expenses. I cited the specific statutes in
the tax code which deny the expenses. Show me why you think I'm wrong?
> > I think both of you have missed the mark.
Your prior post had NO MENTION of UUCP.
As for zombied machines, that's why we have DNSBLs. Under current
circumstances, I don't accept their spew either.
Steve Baker
...
>I ask again: Write-off how? Spamming is illegal in the U.S.
...
>Your prior post had NO MENTION of UUCP.
Yes, it did.
--
Steve Baker
Steve Baker
wrote:
>We all know one of the biggest problems with the current eamil
>system is the fact that, basicly, any machine on the INTERNET
>can be an MTA and thus spew garbage into the system. Many moons
>ago we had what must be seen as the ultimate "white list" system.
>UUCP Mail. Mail was only exchanged between sites that agreed
>ahead of time to do so. Why has a return to such a system not
>been considered lately as a possible solution (or at least as
>a way to greatly reduce not only the total quantity of spam
>but also the cost involved in dealing with it).
You can do that now under the current setup by accepting email only
from senders you know you want email from, you don't need to "return"
to anything.
--
Steve Baker
W
> "W" <persis...@spamarrest.com> writes:
> > "Mark Hobley" <markh...@hotpop.donottypethisbit.com> wrote in message
> > news:ci0647-...@neptune.markhobley.yi.org...
> >> Bill Gunshannon <bill...@cs.uofs.edu> wrote:
> >> > Anyone interested in discussing this?
> >>
> >> I am thinking that we need some type of postage stamp system, whereby a
> >> recipient issues digital stamps to a trusted post office. A post office
> > can
> >> filter out any messages that do not have the stamps attached. A sender
> > wishing
> >> to obtain a stamp, must present an electronic identity card signed by
an
> >> authority trusted by the intended recipient. The recipient can issue
> > stamps to
> >> a "post office" of their choice, and the sender has to present their
> > identity
> >> to the recipients chosen "post office" in order to obtain the stamps.
> >
> > What Internet email badly needs is rational economics. Charge one
penny
> > for every email sent. That one step alone would reduce the volume of
spam
> > by 95%.
>
> Which, once again, punishes the legitimate users and not the spammers.
Which - as it should have been from day one - charges the end user some
rationally proportionate amount for what he uses. End users are not
"punished" by being charged the price of three big macs to send a month of
email. Spammers ARE punished by this system, because the imbecile who
sends out 100 million junk emails now pays $1 MILLION dollars instead of
getting a free ride.
Does the world owe you free meat? A free home? A free car? Free
vacations? Why does the world owe any end user free anything? Just
because this is the way the Internet evolved doesn't mean it is economically
rational, economically desirable, or even good social policy.
> > Any time you make any resource FREE, it gets abused.
>
> Care to provide more examples taht support this allegation? I can think
> of a lot of things that are free but not abused.
The classic example would be underpricing of resources like meat by central
planning authorities as in the old Soviet Union. Failure to let price
rise to regulate supply and demand meant that day-long lines would form any
time the "free" or "near-free" resource was made available.
Economics says that anything that has a cost to produce needs to use a
floating price to bring supply and demand into equilibrium. If you want to
use examples of resources that don't meet that model, it's better to just
present those.
> > Give
that
> > resource's use any kind of rational economic cost, and the cost alone
> > regulates the use.
>
> Regulate? Yes, it would. First thing to go would be any legitimate
> mailing lists.
So make the cost 1/10th of one cent per email. The guy who sends 200
emails per day now pays $6/month. That's going to kill commercial email
lists? Excuse me?
> Of course, this has been discussed before and I can
> even remember when the ISP's wanted to charge for traffic as well.
> It didn't fly then and no one is going to buy into it now. Except
> maybe for the people who would be collecting all those pennies.
Given the choice between free and not free, consumers wanted free. Wow,
thanks for sharing.
Given the choice between getting votes of consumers and doing something that
is politically unpopular, politicians chose to buy the cheap political vote.
So let's start a little communist state right in the middle of the US, where
all of the meat, milk, cheese, tires, and cars have their prices set by
politicians who either give these resources away for free or set the price
too low. Consumers in this twilight zone pay very little money for
anything they buy, but then again they have no free time since buying cheese
requires them to come in on the day it is delivered and wait in line for
nine hours. Any time someone like me points out that such supply and
demand discrepencies should be resolved by a floating price, guys like you
stand up and say they love everything being free please don't change.
What you have today on the Internet is a cess pool. Any arbitrary low-life
can send 1 BILLION pieces of email and pay nothing. That low-life might
make $2000 for the effort and given the cost is zero they consider the
effort profitable. Instead of using the simple capitalist economic pricing
model that solves supply and demand problems for every other kind of
commodity, what we have instead is a socialist nirvana free-for-all, and the
fallout from that is that abusive individuals and organizations overuse the
resource, to the detriment of all of us.
You do NOT need to make it expensive to send email or to use the Internet.
You simply need to assign it *any* kind of cost, and that one step alone
would wipe out 95% of the abuse we now see.
> > Even hardcore email fanatics do not send more than
200
> > emails a day. That's $2, or $60/month. That's hardly going to spoil
the
> > Internet for any legitimate user.
>
> I certainly wouldn't pay it.
Part of being a free person in a free society is you get to make choices.
You get to choose to not buy meat, because it costs more than you want to
pay. You get to choose to not buy a car, because you don't want to spend
the money. So if you cannot afford to spend $10/month to send Internet
email, you get to choose to go back to sending letters by US mail, or by
FAX, and more power to you. That looks like a very bad decision to me,
but part of freedom is that you get to make very bad decisions.
> And, if the cost is so low that it would
> not effect ordinary users then it certainly won't stop spammers who can
> write it off their taxes as a business expense.
Absolutely ridiculous remark. If a spammer sends one hundred million
emails to make $1000, and now (by hypothesis) has to spend one penny per
email, his cost to make $1000 is now $1 million dollars. No economically
rational person spends $1 million dollars to make $1000, and who care what
they can "write off"?
> And, you do realize that this would legitimize spamming and still leave
the burden on you to
> sort thru all the junk trying to find that one legitimate email that
> you actually want to see. Once again, punish the victim by putting
> more work, expense and wasted time in their hands.
You have software tools to control what is in your email inbox. You can
continue to use those. But given these two choices:
1) 10,000 pieces of junk mail that are irrelevant to your life
2) 100 pieces of junk mail that advertise products that are relevant to you
what person wouldn't prefer 2) to 1). Obviously we might prefer option 3)
0 pieces of junkmail. But at least 2) is much less destructive to my time,
and much more socially desirable because it uses less limited resources.
--
W
D. Stussy
news:p5i6n55llppm5ui6r...@4ax.com...
> On Wed, 10 Feb 2010 14:39:40 -0800, "D. Stussy"
> ...
> >I ask again: Write-off how? Spamming is illegal in the U.S.
>
> Where did you get that idea? Which laws make it illegal?
If you think it's legal, then why have people been prosecuted for it?
> ...
>
> >Your prior post had NO MENTION of UUCP.
>
> Yes, it did.
The post I replied to had no mention of it.
Andrzej Adam Filip
> "Steve Baker" <bak...@comcast.net> wrote in message
> news:p5i6n55llppm5ui6r...@4ax.com...
>> On Wed, 10 Feb 2010 14:39:40 -0800, "D. Stussy"
>> ...
>> >I ask again: Write-off how? Spamming is illegal in the U.S.
>>
>> Where did you get that idea? Which laws make it illegal?
>
> If you think it's legal, then why have people been prosecuted for it?
People have been prosecuted in USA for *some* things we call spam :-)
There are many kinds of what we call spam "hard to prosecute" *at least*.
> [...]
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
All life evolves by the differential survival of replicating entities.
-- Dawkins
Mark Hobley
> Which - as it should have been from day one - charges the end user some
> rationally proportionate amount for what he uses.
Actually, another idea based on what you have said is for the a nominal
payment of just once penny to go to the recipient of the mail. Any mail
without the electronic payment authorization attached is simply filtered.
This would hurt spammers the most.
Thor Kottelin
news:RqmdnVmdashQF-7W...@giganews.com...
>> Regulate? Yes, it would. First thing to go would be any legitimate
>> mailing lists.
>
> So make the cost 1/10th of one cent per email. The guy who sends 200
> emails per day now pays $6/month. That's going to kill commercial
> email
> lists? Excuse me?
Let's assume that an university hosts 20 mailing lists as a public service
for various groups. Each list has an average of 2,000 users and receives
200 messages per month. The choice between paying USD 8,000 (� EUR 5,800)
per month or shutting down the lists would probably be obvious.
Nevertheless, that might be acceptable collateral damage, assuming that
this final ultimate solution to the spam problem otherwise works.
Mike Scott
> "D. Stussy" <spam+ne...@bde-arc.ampr.org> wrote:
>> "Steve Baker" <bak...@comcast.net> wrote in message
>> news:p5i6n55llppm5ui6r...@4ax.com...
>>> On Wed, 10 Feb 2010 14:39:40 -0800, "D. Stussy"
>>> ...
>>>> I ask again: Write-off how? Spamming is illegal in the U.S.
>>> Where did you get that idea? Which laws make it illegal?
>> If you think it's legal, then why have people been prosecuted for it?
>
> People have been prosecuted in USA for *some* things we call spam :-)
> There are many kinds of what we call spam "hard to prosecute" *at least*.
>
>> [...]
>
the UK. The chances of a prosecution are.......??
Doesn't the real point need stating somewhere - SMTP is well past its
'best before' date. It's worked wonders in the past, but the whole
protocol needs replacing.
SMTP dates back to days when connectivity could be flaky - it still has
relics of explicit routing in allowed addresses. Then store-and-forward
was a necessity.
But connectivity is pretty good now, and store-and-forward isn't needed
generally. Suppose, rather than the current 'push' method, mails are
stored at the sender end, the recipient notified, and then the recipient
pulls the mail from the /sender's/ server (not his own) - if and when he
wants it. The onus of storage is then on the sender (so zombies will
quickly run out of space) and the recipient doesn't get to store
potentially viral spam. It would seem to move the cost burden where it
belongs. Thoughts???
--
Mike Scott (unet2 <at> [deletethis] scottsonline.org.uk)
Harlow Essex England
Steve Baker
<spam+ne...@bde-arc.ampr.org> wrote:
>"Steve Baker" <bak...@comcast.net> wrote in message
>news:p5i6n55llppm5ui6r...@4ax.com...
>> On Wed, 10 Feb 2010 14:39:40 -0800, "D. Stussy"
>> ...
>> >I ask again: Write-off how? Spamming is illegal in the U.S.
>>
>> Where did you get that idea? Which laws make it illegal?
>
>If you think it's legal, then why have people been prosecuted for it?
Some types of spam are illegal under CAN-SPAM, but spamming, per se,
isn't illegal under CAN-SPAM. Maybe that's what you're thinking of?
>
>> ...
>>
>> >Your prior post had NO MENTION of UUCP.
>>
>> Yes, it did.
>
>The post I replied to had no mention of it.
That wasn't his only prior post.
--
Steve Baker
Andrzej Adam Filip
Over complicated. Another (simpler) approach may be "sender trust escalation":
1) receiving server rejects sending host with "try higher reputation relay"
5?? code in SMTP greeting message.
2) sending host relays message via relay with higher reputation
(initially its ISP) mail server
Of course there may be more than one "trust escalation attempt" but
limiting it to 3-4 levels would be sensible IMHO.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
Yevtushenko has... an ego that can crack crystal at a distance of twenty feet.
-- John Cheever
Bill Gunshannon
One of the basic tenets of what I am syggesting is the creation of a
network of "trusted relay hosts" or "higher reputation relays" if you
will. I am just suggesting doing this with a system that already exists,
could be re-implemented immediately, could grow over time and have an
immediate result. I do not believe charging more money is the solution.
And, I would really like ot hear what people see as flaws in this plan
rahter than just trying to come up with other alternatives.
D. Stussy
The first flaw is that NO one can be truly trusted. No matter how "smart"
a spam & virus detector is, it's programmed based on what has been seen
before, so some new type of hostile content can initially slip by.
100% spam elimination requires 100% mail elimination: No mail => no spam.
Not very practical, but it works.
Andrzej Adam Filip
If you assume that level 2 of (fallback) "trust escalation" may be
<10_000 then establishing if given host deserves trust should be
*MUCH* easier.
> 100% spam elimination requires 100% mail elimination: No mail => no spam.
> Not very practical, but it works.
Achieving one spam in mailbox per 100 ham messages would mean spam
elimination by my standards.
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
"No, `Eureka' is Greek for `This bath is too hot.'"
-- Dr. Who
Loki Harfagr
I suppose you mean *when* there is *zero* false positive?
Andrzej Adam Filip
Zero? Wake up to reality with your expectations :-)
Very low "false positives" can be ignored *IF* sender or recipient are
notified about "delivery refusal". A few spams per day (<=3) in spambox
folder would make "inspection/final judgment" *by the recipient* something
better than a "blame the end users" joke (as with 50+ "spams" per day).
BTW "sender trust escalation" is not for sure the only "relatively
simple" possible improvement of "(E)SMTP based infrastructure".
P.S. I do believe in "deceptive simplicity" :-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
i dont even know if it makes sense at all :)
This is an experimental patch for an experimental kernel :))
-- Ingo Molnar on linux-kernel
Mark Hobley
> What Internet email badly needs is rational economics. Charge one penny
> for every email sent.
The recipient could levvy a toll against a sender wishing to add their address
to the recipients' accepted sender list. Once you are on the accepted sender
list, you can mail for free. If you are not on the recipients' accepted sender
list, you cannot send mail. If you send spam, the recipient can remove you
from the list. Falsifying the sender address will do no good, because the
falsified address will not be on the sender list, and you will have to pay the
toll for this to be added. If your machine is a zombie, you will have to pay
the toll against each machine that you spam.
Mike Scott
> W <persis...@spamarrest.com> wrote:
>> What Internet email badly needs is rational economics. Charge one penny
>> for every email sent.
>
> The recipient could levvy a toll against a sender wishing to add their address
> to the recipients' accepted sender list. Once you are on the accepted sender
> list, you can mail for free. If you are not on the recipients' accepted sender
> list, you cannot send mail. If you send spam, the recipient can remove you
> from the list. Falsifying the sender address will do no good, because the
> falsified address will not be on the sender list, and you will have to pay the
Who will pay? The true, but anonymous sender - or will the faked sender
be asked to pay (and, presumably, refuse)? In which case all you've done
is move the problem to someone else - just like challenge-response.
> toll for this to be added. If your machine is a zombie, you will have to pay
> the toll against each machine that you spam.
How might that be enforced? Suppose I, in the UK, receive spam from a
hacked Indian machine, part of a botnet controlled by someone in Korea.
How will I - the recipient - collect anything?
>
> Mark.
Thor Kottelin
news:hl998p$4hd$1...@speranza.aioe.org...
> Mark Hobley wrote:
>> W <persis...@spamarrest.com> wrote:
>>> What Internet email badly needs is rational economics. Charge one
>>> penny
>>> for every email sent.
>>
>> The recipient could levvy a toll against a sender wishing to add their
>> address
>> to the recipients' accepted sender list. Once you are on the accepted
>> sender
>> list, you can mail for free. If you are not on the recipients' accepted
>> sender
>> list, you cannot send mail. If you send spam, the recipient can remove
>> you
>> from the list. Falsifying the sender address will do no good, because
>> the
>> falsified address will not be on the sender list, and you will have to
>> pay the
> How might that be enforced? Suppose I, in the UK, receive spam from a
> hacked Indian machine, part of a botnet controlled by someone in Korea.
> How will I - the recipient - collect anything?
SMTP could be expanded by a command that would include a cryptographically
signed "money order" attribute. The server would verify the signature and
determine whether it is configured to trust the sender's willingness and
capability to pay. Based on this, the message would either be accepted or
rejected.
If the server would accept the message, it would also pass the "money
order" to an application compatible with the payment infrastructure, which
would also need to be devised. In its simplest form, the "money order"
could include credit card details encrypted to the server's public key;
the server would forward the information to an acquirer, much as if
someone had swiped the sender's card in a point of sale terminal.
Admittedly, fraudsters often have an unlimited supply of credit card
numbers, but credit cards nevertheless remain the payment method of choice
on the Internet. Of course, other methods could be implemented as well. As
an example, banks or telcos (think GSM roaming) might run clearinghouses.
There, I have done my share. Now please write the protocol in
Internet-Draft format and gather a critical mass of adopters. Shouldn't
take long. :)
Mark Hobley
> How might that be enforced? Suppose I, in the UK, receive spam from a
> hacked Indian machine, part of a botnet controlled by someone in Korea.
> How will I - the recipient - collect anything?
The assumption here is that you do not want to collect anything from the
hacked machine. Your mail service provider checks the electronic
identification stub against your chosen trusted authorization service.
If the authorization is not valid, then the mail is simply bounced. If the
sender wants to become authorized, then it is a simple case of attaching a
valid epayment stub, which will cause the recipient's authorization authority
to issue an appropriate identification marker in exchange for the epayment.
As a recipient, mail is collected normally using appropriate protocols.
Loki Harfagr
Well yes, but I was just puzzled by the somehow 'low' 1p100 achievement
so I was /indirectly/ asking about the other unspoken (yet) factors that
actually did /mitigate/ that rate.
> Very low "false positives" can be ignored *IF* sender or recipient are
> notified about "delivery refusal". A few spams per day (<=3) in spambox
> folder would make "inspection/final judgment" *by the recipient*
> something better than a "blame the end users" joke (as with 50+ "spams"
> per day).
That's right and that FP/SP is always a 'specific per customer' rate setting :-)
> BTW "sender trust escalation" is not for sure the only "relatively
> simple" possible improvement of "(E)SMTP based infrastructure".
could be, I still didn't really understand what and how about it,
just like I simply still don't understand how and what SPF [csw]hould do...
Now, that's right it's nowadays a simple trigger to add-up 2 or 3 points
as 'probable spam ;-)
>
> P.S. I do believe in "deceptive simplicity" :-)
I like that too, most probably the only way to deal with noise :-)
Andrzej Adam Filip
> Sun, 14 Feb 2010 11:55:36 +0100, Andrzej Adam Filip did cat :
>> BTW "sender trust escalation" is not for sure the only "relatively
>> simple" possible improvement of "(E)SMTP based infrastructure".
>
> could be, I still didn't really understand what and how about it,
> just like I simply still don't understand how and what SPF [csw]hould do...
> Now, that's right it's nowadays a simple trigger to add-up 2 or 3 points
> as 'probable spam ;-)
0) As of today there far too many IP addresses that *MAY* host hammy MTA.
1) I effectively suggest setting "reject" as default policy for "far away
countries" and "not too good ASN networks" with "relays trusted
by the recipient" as the exceptions.
To be very specific (may be beyond political correctness):
block CN except a few hundredth "more trusted relays"
and maybe a few dozens "receiving site specific exceptions"
to avoid being too helpful to The Great Firewall :-)
Keeping score of a few hundredth email relays should be *MUCH* simpler.
2) Another path is to make companies like Google, Yahoo, IBM, MSN *SELL*
"outgoing fallback relay" service to senders. If such service would
accept/relay too much spam then *recipients* worldwide (also beyond USA
jurisdiction) would stop accepting messages from it and its value to
*paying* customers would be lowered.
[ send directly to friendly servers, used "outgoing relay" as fallback
for "as for now strangers" ]
>> P.S. I do believe in "deceptive simplicity" :-)
>
> I like that too, most probably the only way to deal with noise :-)
--
[pl>en Andrew] Andrzej Adam Filip : an...@onet.eu : Andrze...@gmail.com
A man of genius makes no mistakes.
His errors are volitional and are the portals of discovery.
-- James Joyce, "Ulysses"
David F. Skoll
> [...] gather a critical mass of adopters.
Which is why all these discussions are a shameful waste of electrons.
Pay-per-email will never happen because it would kill email more
swiftly and surely than spam ever could.
Regards,
David.
Bill Gunshannon
And it is totally unnecessary but no one seems to want to really look
at alternatives.
Mike Scott
> In article <59ca2$4b794d91$d1d97a75$27...@primus.ca>,
> "David F. Skoll" <d...@roaringpenguin.com> writes:
>> Thor Kottelin wrote:
>>
>>> [...] gather a critical mass of adopters.
>> Which is why all these discussions are a shameful waste of electrons.
>>
>> Pay-per-email will never happen because it would kill email more
>> swiftly and surely than spam ever could.
>
> And it is totally unnecessary but no one seems to want to really look
> at alternatives.
See my post a little way up this thread. I reckon there's mileage in the
idea, but I don't have the resources (or ability these days) to make an
exemplar system. But I do know a smooth transition to that sort of idea
from smtp could be managed.
I think there's too much emotional and financial interest in keeping
smtp going. There's a lot of people who've put a lot of (often very
good) work and time into patching it up - again and again - and writing
assorted filters, work-arounds, etc, etc and perhaps are reluctant to
drop the whole lot as being well past its best-before date. Then there's
the companies making money out of selling anti-spam "solutions". They
won't want a fundamentally spam-proof system, will they? Politics, not
'technics' :-{
Just my 2p worth.
>
> bill
David F. Skoll
> I think there's too much emotional and financial interest in keeping
> smtp going. There's a lot of people who've put a lot of (often very
> good) work and time into patching it up - again and again - and writing
> assorted filters, work-arounds, etc, etc and perhaps are reluctant to
> drop the whole lot as being well past its best-before date.
No, that's not it at all.
The huge problem with SMTP is that it allows anyone to send lots of
mail, unauthenticated, and very cheaply.
But that's also the *beauty* of SMTP. That's why it's such a
raging success. I *like* being able to dash off emails to people I
don't know without being forced to jump through hoops or pay money. I
*like* being able to generate random sender addresses for recipients
I'm not sure I trust. [My server tracks such addresses and makes sure
only authorized recipients can use them.] And I *like* being able to
receive email from strangers: My company depends on random people
being able to email us for information.
Anything that distorts that economic reality will kill email for me and
for many other people.
Regards,
David.
Mike Scott
But smtp is not the only possible protocol that could provide the
freedom we are all used to. It has its roots in the 1970's 'point to
point' age of poor/expensive long-distance connectivity. It would be
perfectly possible to replace with something more robust, without all
this stuff about charging for emails (which I am totally against).
And your random address generation (I've wondered about something
similar) is only a palliative for a deeper problem that desperately
needs fixing.
>
> Anything that distorts that economic reality will kill email for me and
> for many other people.
Yes. It would be a very perverse move.
>
> Regards,
>
> David.
David F. Skoll
>> But that's also the *beauty* of SMTP. That's why it's such a
>> raging success. I *like* being able to dash off emails to people I
>> don't know without being forced to jump through hoops or pay money. I
>> *like* being able to generate random sender addresses for recipients
>> I'm not sure I trust. [My server tracks such addresses and makes sure
>> only authorized recipients can use them.] And I *like* being able to
>> receive email from strangers: My company depends on random people
>> being able to email us for information.
> But smtp is not the only possible protocol that could provide the
> freedom we are all used to.
Anything that provides that freedom can (and will) be abused by
spammers. Any protocol that can't be abused by spammers must, of
necessity, remove one of the freedoms I mentioned (cheapness,
anonymity and ability to send large amounts of mail.)
> And your random address generation (I've wondered about something
> similar) is only a palliative for a deeper problem that desperately
> needs fixing.
Not at all. I have different identities for different purposes. To
my coworkers, I'm the head of my company. To my kids, I'm "Dad". To
various branches of the government, I'm a tax-payer, a licensed
driver, or someone on the Ontario health plan. I have completely
different credentials (and personalities!) for each identity, and I
don't particularly care to have them amalgamated. Similarly, for
people I don't trust, I want to present different identities that
can't easily be correlated.
Regards,
David.
Mark Hobley
> Any protocol that can't be abused by spammers must, of
> necessity, remove one of the freedoms I mentioned (cheapness,
> anonymity and ability to send large amounts of mail.)
Anonymity was never a good idea when it comes to email. It would be better
to have a system that identifies the sender (or at least the option to drop
anonymized mail). Being able to filter by geographic origin would also be
a useful facility IMHO.
David F. Skoll
> Anonymity was never a good idea when it comes to email.
Why not? Do you have a practical proposal to make email non-anonymous?
Any identity system can (will!) be subverted by those with enough
resources to make it worthwhile. It's better to be aware that email
is completely unauthenticated than to have misplaced trust in
supposedly-authenticated email.
> It would be better to have a system that identifies the sender (or
> at least the option to drop anonymized mail).
We have such a system; it's called PGP. Simply insist that anyone who
communicates with you signs his/her email, and insist that he/she be in
your web of trust. Problem "solved".
> Being able to filter by geographic origin would also be a useful
> facility IMHO.
That's easy; our (commercial) anti-spam product can already do that.
(Well... except for mail originating from gmail.com, because Google
hides the IP address of the originating sender. This is an example of
Google Doing Evil.)
Regards,
David.
Bill Gunshannon
>
>>> But that's also the *beauty* of SMTP. That's why it's such a
>>> raging success. I *like* being able to dash off emails to people I
>>> don't know without being forced to jump through hoops or pay money. I
>>> *like* being able to generate random sender addresses for recipients
>>> I'm not sure I trust. [My server tracks such addresses and makes sure
>>> only authorized recipients can use them.] And I *like* being able to
>>> receive email from strangers: My company depends on random people
>>> being able to email us for information.
>
>> But smtp is not the only possible protocol that could provide the
>> freedom we are all used to.
>
> Anything that provides that freedom can (and will) be abused by
> spammers.
Technically, true. Which is why the only really workable solution
is going to need to be non-technical (ie. social).
> Any protocol that can't be abused by spammers must, of
> necessity, remove one of the freedoms I mentioned (cheapness,
> anonymity and ability to send large amounts of mail.)
Well, some may not agree with your 3 freedoms, but the system I
have proposed can do them as well as the current system while still
reducing 9andi n some cases, eliminating) spam.
>
>> And your random address generation (I've wondered about something
>> similar) is only a palliative for a deeper problem that desperately
>> needs fixing.
>
> Not at all. I have different identities for different purposes. To
> my coworkers, I'm the head of my company. To my kids, I'm "Dad". To
> various branches of the government, I'm a tax-payer, a licensed
> driver, or someone on the Ontario health plan. I have completely
> different credentials (and personalities!) for each identity, and I
> don't particularly care to have them amalgamated. Similarly, for
> people I don't trust, I want to present different identities that
> can't easily be correlated.
I too have numerous Email accounts that i use for different purposes.
Nothing in what I periodically propose changes that. As a matter of
fact, for the average email user no visible change will happen. All
of my changes occur at the MTA level and will likely reduce rather
than increase the administrative overhead for the sysadmin.
And, for those who think the INTERNET is here for entrepreneurs to
make money, it would open up, or rather re-open as none of what I
propose is new, some interesteing oppoertunities (for those who have
been around a long time, think UUNET).
Mark Hobley
> That's easy; our (commercial) anti-spam product can already do that.
> (Well... except for mail originating from gmail.com, because Google
> hides the IP address of the originating sender.
I read somewhere that some mail gateways allow falsification of the originating
IP address, so this in itself is insufficient. I don't know which providers
this applies to though.
Landmark
only one economy or one jurisdiction involved then I think your ideas
would be feasible. However, on a global scale I think it has flaws.
If you pay per mail, who does the money go to? Is it paid to the ISP
which sends the mail for you? If so, that means that ISPs can set
their own fees for mail and an ISP in, say, Latvia, can offer spamming
services at a fraction of the cost of the UK or US ISP. What about
zombied PCs which can send mail directly and which are the source of
much spam? Who is going to make them pay to send mail?
If it is the receiving ISP which charges for the mail then how does
that work? Does that mean I will need an account with the ISP of every
person I want to send mail to?
If people or mail servers are paid to receive mail then we'll get a
form of reverse spamming. I operate a public newsletter. If I had to
pay the recipient to receive it then I can guarantee that people would
sign up a million email addresses to that list so that every time I
hit send I was having to pay then a million times 0.1 cents.
Landmark
>Don't know, but it also has nothing to do with my suggestion which is
>to revive UUCP Mail. The one thing that UUCP Mail had that none of the
>current systems have is the upfront agreement between MTA's to exchange
>email with each other. Which also allows for the setting of legally
>binding groundrules up front as well. And, probbably the biggest advantage
>this berings to the whole email system is the total elimination of zombied
>machines. It doesn't matter how many machines you can zombie if no one
>accepts their email.
The problem I have with this idea is that I don't know in advance
everyone my mail server might want to talk to. For example, I sell
goods via a website. When I have received an order I send out a
confirmation email. The sendmail program run by my webserver cannot
know in advance whaich addresses it might need to send confirmations
to. It wouldn't be practical for me to organise an agreement with
every email server in the world, not even inthe UK.
Landmark
>Suppose, rather than the current 'push' method, mails are
>stored at the sender end, the recipient notified, and then the recipient
>pulls the mail from the /sender's/ server (not his own) - if and when he
>wants it. The onus of storage is then on the sender
This method fails because the spammers will quickly develop mail
storage servers which only need to store one copy of the advertising
spam, regardless of how many people they send notifications to.
Bill Gunshannon
Landmark <dontm...@no.junkmail.here> writes:
> bill...@cs.uofs.edu (Bill Gunshannon) wrote:
>
>>Don't know, but it also has nothing to do with my suggestion which is
>>to revive UUCP Mail. The one thing that UUCP Mail had that none of the
>>current systems have is the upfront agreement between MTA's to exchange
>>email with each other. Which also allows for the setting of legally
>>binding groundrules up front as well. And, probbably the biggest advantage
>>this berings to the whole email system is the total elimination of zombied
>>machines. It doesn't matter how many machines you can zombie if no one
>>accepts their email.
>
> The problem I have with this idea is that I don't know in advance
> everyone my mail server might want to talk to.
That is one of the beauties of this propoosal. It doesn't require
the immediate demise of the existing system. It can phase in over
a period of time. And during that period one can place a value
on email based on how it got to your mailbox. Makes autmoatic
filtering easier and more accurate because it will be pretty much
immpossible to forge emails as coming from the more secure system.
> For example, I sell
> goods via a website. When I have received an order I send out a
> confirmation email. The sendmail program run by my webserver cannot
> know in advance whaich addresses it might need to send confirmations
> to.
Which is fine. The system would determine which way to send the email,
either over the UUCPNET or with SMTP based on the path the email took
to get there.
> It wouldn't be practical for me to organise an agreement with
> every email server in the world, not even inthe UK.
I do not anticipate every MTA having agreements or direct connections
to every other MTA in the world. If my MTA has an agreement with your
MTA the understanding of that agreement would be that you would forward
to me from other MTA's who had signed equivialent agreements. The
agreements would constitute legally binding contracts which offers two
major possibilities that both reduce or eliminate SPAM. The ability to
legally assess financial damages on one who violates the agreement and
the ability to terminate the agreement thus effectively eliminating that
party from future participation (the Amish call this shunning and it works
very well.) I also anticipate that as this system grows there will
appear both free and for-a-fee hubs (for those who have been around long
enough to remember, think SEISMO and UUNET) to make the system even more
efficient and further reduce the number of individual agreements needed.
Landmark
>> The problem I have with this idea is that I don't know in advance
>> everyone my mail server might want to talk to.
>That is one of the beauties of this propoosal. It doesn't require
>the immediate demise of the existing system. It can phase in over
>a period of time.
No, you've missed the point. Its not a case of phasing it in while I
build up my lists of who I want to talk to. It will always be the case
that there are email addresses that I need to contact, but don't know
that in advance, and don't have any agreement with them.
>And during that period one can place a value
>on email based on how it got to your mailbox. Makes autmoatic
>filtering easier and more accurate because it will be pretty much
>immpossible to forge emails as coming from the more secure system.
But it doesn't stop spam as we have it now getting into my mailbox,
and I can't afford to reject mail which has come through the existing
route because it might contain mails important to my business. So
unless everyone in the world agrees to use verified/paid for mail, it
doesn't actually make the filtering of mail any easier at all and I
can't see many businesses being willing to tell customers, "If you
want to contact us, you have to use this new fangled mail system".
>>For example, I sell
>> goods via a website. When I have received an order I send out a
>> confirmation email. The sendmail program run by my webserver cannot
>> know in advance which addresses it might need to send confirmations
>> to.
>Which is fine. The system would determine which way to send the email,
>either over the UUCPNET or with SMTP based on the path the email took
>to get there.
That doesn't make sense. The system decides on whether to use uucpnet
or smtp based on something that will happen in the future?
If someone has given me an email address via a website transaction, I
can't know anything in advance about that email address.
>> It wouldn't be practical for me to organise an agreement with
>> every email server in the world, not even inthe UK.
>
>I do not anticipate every MTA having agreements or direct connections
>to every other MTA in the world. If my MTA has an agreement with your
>MTA the understanding of that agreement would be that you would forward
>to me from other MTA's who had signed equivialent agreements....
So how many legal agreements do you think it takes to build an
effective web of trust on today's internet? A thousand? A million? A
billion? How do you think you are going to get legally-binding
cross-border agreements? Will you have to have documents withnessed by
lawyers for each party? It could get pretty expensive drawing up all
these agreements even if you don't need them for all combinations of
MTA to MTA.
I can see that lawyers might love your solution but I can't see how it
solves any of the problems, how it would be enforceable, or how you
ever get it to sufficient critical mass to make it work. It just seems
like a huge layer of complexity and cost for no tangible benefit.
Greg Russell
Landmark <dontm...@no.junkmail.here> typed:
> I operate a public newsletter. ... every time I
> hit send I was having to pay then a million times 0.1 cents.
That would be a good thing. Put your "newsletter" on a web site so that
people can voluntarily view it instead of receiving your spam.
Bill Gunshannon
Landmark <dontm...@no.junkmail.here> writes:
> bill...@cs.uofs.edu (Bill Gunshannon) wrote:
>
>>> The problem I have with this idea is that I don't know in advance
>>> everyone my mail server might want to talk to.
>
>>That is one of the beauties of this propoosal. It doesn't require
>>the immediate demise of the existing system. It can phase in over
>>a period of time.
>
> No, you've missed the point. Its not a case of phasing it in while I
> build up my lists of who I want to talk to. It will always be the case
> that there are email addresses that I need to contact, but don't know
> that in advance, and don't have any agreement with them.
And you are free to continue to accept email from anyone you want.
But as more and more users move to email providers who use the more
secure system, the amount of SPAM they will receive will decrease.
You remain free to accept all the SPAM you wish until a better model
for your specific communications becomes available.
>
>>And during that period one can place a value
>>on email based on how it got to your mailbox. Makes autmoatic
>>filtering easier and more accurate because it will be pretty much
>>immpossible to forge emails as coming from the more secure system.
>
> But it doesn't stop spam as we have it now getting into my mailbox,
Depends on how you look at it. If I stop accepting all email from
systems outside the secure system my SPAM stops. Right now, probably
the largest percentages of SPAm come from zombied machines/botnets.
ISP's could stop that today. They choose not to. I can not say why
they refuse to fix a problem that is due primarily to bad network
engineering on their part, but that is reality. The system I a
proposing will make zombied machines/botnets sending email of any
kind impossible.
> and I can't afford to reject mail which has come through the existing
> route because it might contain mails important to my business.
Then accept it and all the SPAM as well. I am not proposing anything
that would limit who you were allowed to accept email from. I am
proposing a system that gives those who want it a choice and on of those
choices is a system where the amount of SPAM becomes negligible. And,
up to this point, I have not even begun to address the overall decrease
in useless network traffic that would result from this. People are
already trying to do this with "whitelists" and "tarpits" and whatnot.
These are all reactive solutions. I am merely suggesting it is time
to make the solution proactive. I am assuming, based on the problems
you percieve in this that you run a wide open email server and accept
everything from everyone. Based on the amount of SPAM I see and the
number of machines that I already refuse email from, I can't imagine
how you can possibly sort out the legitimate from the garbage.
> So
> unless everyone in the world agrees to use verified/paid for mail, it
> doesn't actually make the filtering of mail any easier at all
Of course it does. Many email/SPAM filtering systems today use
a weighting system. They assigne a value, usually based on some
Bayesian filters computation of the liklihood of an email being
SPAM. If one used UUCP and had agreements with UUCP peers forbidding
SPAM then these emails would always be rated as SPAM free.
> and I
> can't see many businesses being willing to tell customers, "If you
> want to contact us, you have to use this new fangled mail system".
Never said they have to. But I foresee mroe and more people moving
to the more reliable, more SPAM free system over time which would
make a marked improvement in these businesses abilty to devote less
resources to separating real customers from SPAM.
Oh, and it's not "new-fangled". i thas been around longer than SMPT
and is fully supported by systems like sendmail.
>
>>>For example, I sell
>>> goods via a website. When I have received an order I send out a
>>> confirmation email. The sendmail program run by my webserver cannot
>>> know in advance which addresses it might need to send confirmations
>>> to.
>
>>Which is fine. The system would determine which way to send the email,
>>either over the UUCPNET or with SMTP based on the path the email took
>>to get there.
>
> That doesn't make sense. The system decides on whether to use uucpnet
> or smtp based on something that will happen in the future?
No, based on what exists at that time. If a path exists over UUCPNET
that would be the prefered method, otherwise, use SMTP just like it
does today. In the future, more an more would move over UUCPNET as
more and more MTA's become connected that way.
>
> If someone has given me an email address via a website transaction, I
> can't know anything in advance about that email address.
How does your email MTA send a reply to them today? The MTA takes the
address and looks for an IP address. If one exists it connects and sneds
the email. If not, it drops it, maybe returning an error message to you.
Just add one more step in the whole process to look to see if the email
address is reachable over UUCPNET first and if so, send the reply that
way. The user never sees a difference. He reads eamil just as he always
has and he send email just as he always has. All changes are at the level
of the MTA.
>
>>> It wouldn't be practical for me to organise an agreement with
>>> every email server in the world, not even inthe UK.
>>
>>I do not anticipate every MTA having agreements or direct connections
>>to every other MTA in the world. If my MTA has an agreement with your
>>MTA the understanding of that agreement would be that you would forward
>>to me from other MTA's who had signed equivialent agreements....
>
> So how many legal agreements do you think it takes to build an
> effective web of trust on today's internet? A thousand? A million? A
> billion?
Do you seriously believe there are that many legitimate MTA's
on the INTERNET? I would bet the number is nowhere near a
million and is very likely much less than 100,000. for example,
how many users does verizon have? A million? 10 Million? How
many legitimate MTA's? Probably no more than a dozen and they
probably wouldn't need that many but that is their choice. And,
of course, because the agreement is between people and not machines,
a single agreement could cover all their MTA's.
One has to realize that more than 90% of the machiens sending emails
accross the INTERNET today should not be doing it. And all attempts
aty finding a solution (whitelists, tarpits, RBL's) to stop them have
proven fruitless because they try to stop them after the fact. They
need to be stopped before they send, not after.
> How do you think you are going to get legally-binding
> cross-border agreements?
How legally binding they need to be will depend on the individuals
making the agreements. Remember, one of the penalties for violating
the agreement is you get thrown back into the current morass and it
is unlikely anyone will trust you enough to let you back into the
clean system again.
> Will you have to have documents withnessed by
> lawyers for each party?
If you wish. Personally I hate lawyers and think they are more a part
of the problem than a solution to any problem.
> It could get pretty expensive drawing up all
> these agreements even if you don't need them for all combinations of
> MTA to MTA.
Believe it or not, there is a system of machines exchanging email
like information today that relies on very nearly the same model I
am proposing. And you are using it right now. How do you think
USENET News moves around the world? The sysadmins of News machines
have agreed to exchange news with each other. And it works. How
formal are the agreements between these systems? Probably depends
on the sysadmins.
>
> I can see that lawyers might love your solution
Why would lawyers need to be involved at all?
> but I can't see how it
> solves any of the problems,
There can be no zombied machines or botnets. How much SPAM woudl that
alone eliminate?
> how it would be enforceable,
You violate the agreement, I pull the plug on your connection to my
email MTA and you go back to being a part of the morass. If people
are actually using a weighted system based on which network email
comes from you immediately drop from 1% likely SPAM to 80%-90% likely
SPAM.
> or how you
> ever get it to sufficient critical mass to make it work.
Actually, there was a time when both were in use and more email was
moved by UUCP than by SMTP. Slowly, over time, SMTP use increased
and UUCP use decreased. Why? Because SMTP was percieved to have
advantages that outweighed any possible disadvantes. That ratio
has changed today. But most people only know SMTP and think there
are alternatives. Will it reach critical mass? We will never know
if we never try. One of the biggest selling points is the fact that
this involves no new protocols to be developed, no neew software to
be written and full compatability with the email systems we use today.
> It just seems
> like a huge layer of complexity and cost for no tangible benefit.
It is a trivial layer of complexity that has existed for decades and
has the potential to actually reduce the amount of work that most MTA
sysadmins have to do today to try to keep up with the SPAMMERS.
Landmark
>That would be a good thing. Put your "newsletter" on a web site so that
>people can voluntarily view it instead of receiving your spam.
It is not spam, and people ask for it by email.
Greg Russell
Landmark <dontm...@no.junkmail.here> typed:
>> That would be a good thing. Put your "newsletter" on a web site so
>> that people can voluntarily view it instead of receiving your spam.
>
> It is not spam, and people ask for it by email.
That's what *all* spammers say, every last one of them.
Landmark
>That's what *all* spammers say, every last one of them.
I suspect you are just a troll and not really interested in any sort
of sensible discussion. However, lets assume my suspicions are wrong.
Lets also assume for a moment that you are right and I am a lying
spammer. How does that invalidate my point in this discussion which
was about genuine newsletters?
Are you saying that there is no such thing as a genuine email
newsletter and that every person who operates an email-based
newsletter is really a spammer?
If you accept that there are some people who operate genuine email
newsletters which are available only to people who request it and
which uses confirmed opt-in to ensure the only people who receive it
are the ones who genuinely want to receive it, then do you also accept
that a system where senders pay the recipients to receive mail would
result in "reverse spamming" and explained in my original post?