A solution about email spam and email reliability

I have thought a solution both for email spam and email reliability problems, of Internet.



1. Assuming a (E-Mail Removed)ess and a (E-Mail Removed)ess, after the sender sends an email at the
receiver, the receiver.address server sends back a message with a random number to the sender.address server.


2. Then, the (E-Mail Removed)ess sends again the email with the exact received number to the
receiver.address server.

3. The receiver.address server makes the email available to the (E-Mail Removed)ess.

4. The receiver.address server sends a successful receipt email with the same random number.



Thus it is authenticated both that the original email address is valid, and that the email reaches its
destination.



What do you think?



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

Hi,

i doubt that this would work in real world scenarios. In fact many
spammers use real email addresses as sender address, so your solution
would not catch spam, as the the sender address will gladly confirm
that it exists. But you don't want to prove that the sender address
exists, but that the guy who owns the sender address was the guy who
sent the email - which is something that your scheme doesn't provide.
It would also allow the spammers to check if a mailbox really exists
(by simply faking a callback message) and therefore would even promote
more spam...

So, no I don't think that this solution will work.

Jan

On 2009-06-04 14:12:27 +0200, Ioannis Vranos <(E-Mail Removed)> said:

> I have thought a solution both for email spam and email reliability
> problems, of Internet.
>
>
>
> 1. Assuming a (E-Mail Removed)ess and a (E-Mail Removed)ess,
> after the sender sends an email at the receiver, the receiver.address
> server sends back a message with a random number to the sender.address
> server.
>
>
> 2. Then, the (E-Mail Removed)ess sends again the email with the exact
> received number to the receiver.address server.
>
> 3. The receiver.address server makes the email available to the
> (E-Mail Removed)ess.
>
> 4. The receiver.address server sends a successful receipt email with
> the same random number.
>
>
>
> Thus it is authenticated both that the original email address is valid,
> and that the email reaches its destination.
>
>
>
> What do you think?

On Jun 4, 5:12*am, Ioannis Vranos <ivra...@freemail.gr> wrote:
> I have thought a solution both for email spam and email reliability problems, of Internet.
>
> 1. Assuming a sen...@sender.address and a recei...@receiver.address, after the sender sends an email at the
> receiver, the receiver.address server sends back a message with a random number to the sender.address server.
>
> 2. Then, the sen...@sender.address sends again the email with the exact received number to the
> receiver.address server.
>
> 3. The receiver.address server makes the email available to the recei...@receiver.address.
>
> 4. The receiver.address server sends a successful receipt email with the same random number.
>
> Thus it is authenticated both that the original email address is valid, and that the email reaches its
> destination.
>
> What do you think?

This turns every single legitimate mail user into a spam relay. Read
carefully what your step 2 does, and note that the sender has no way
to authenticate that the real recipient *wants* the mail it's about to
send.

The problem is this: if I can't trust that you want to receive an
email, I can't send you an email. So the trust must be established
*before* anyone but the initial sender sends any emails. Your scheme
fails this requirement.

DS

David Schwartz wrote:
> On Jun 4, 5:12 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
>> I have thought a solution both for email spam and email reliability problems, of Internet.
>>
>> 1. Assuming a sen...@sender.address and a recei...@receiver.address, after the sender sends an email at the
>> receiver, the receiver.address server sends back a message with a random number to the sender.address server.
>>
>> 2. Then, the sen...@sender.address sends again the email with the exact received number to the
>> receiver.address server.
>>
>> 3. The receiver.address server makes the email available to the recei...@receiver.address.
>>
>> 4. The receiver.address server sends a successful receipt email with the same random number.
>>
>> Thus it is authenticated both that the original email address is valid, and that the email reaches its
>> destination.
>>
>> What do you think?
>
> This turns every single legitimate mail user into a spam relay. Read
> carefully what your step 2 does, and note that the sender has no way
> to authenticate that the real recipient *wants* the mail it's about to
> send.
>
> The problem is this: if I can't trust that you want to receive an
> email, I can't send you an email. So the trust must be established
> *before* anyone but the initial sender sends any emails. Your scheme
> fails this requirement.


The approach is aimed to be as simple as possible, that is, the current design of an email address is to
receive email from anyone. My approach keeps this design.


Also most of the spam emails are sent from botnets and *not* from real email accounts.



The free email provider I am using (www.freemail.gr), provides an antispam option named "greylisting" which
radically reduced the amount of spam I am receiving, from many in a day to very few a week.


Here is info about "greylisting" (translated from Greek):

"Greylisting is a ==>transparent checking method of new/unknown senders. When it is active, and a sender sends
an email for the first time to a particular user, Freemail denies to receive it and requests from the server
of the sender to resend it. This usually happens within a few minutes, so the sender address is confirmed
without any bother to the sender or the receiver".


However if an email server is misconfigured, a legit email may not be received. However I haven't come across
any situation that I haven't received any email from someone who is not a spammer, since my alternate email
address with no antispam protection exists at my site shown in my signature in all emails I am sending, and
all messages I am posting to Usenet, so one could notify me of this.


So in summary, my approach is based on the concept of greylisting, and is based on the following facts:

1. 99% of spam emails are sent from botnets with fake or invalid sender email addresses.

2. Misconfigured legit servers may not work with greylisting (I haven't encountered such a problem so far),
and the suggested approach *ensures* that the email ==> of only a legit email account is received and not
rejected by the recipient server.


I haven't understood the following of Jan Thomä:

From Jan Thomä <(E-Mail Removed)>:

"It would also allow the spammers to check if a mailbox really exists (by simply faking a callback message)
and therefore would even promote more spam...".


So, what do you think?



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

Ioannis Vranos wrote:
> I have thought a solution both for email spam and email reliability
> problems, of Internet.
>
> 1. Assuming a (E-Mail Removed)ess and a (E-Mail Removed)ess,
> after the sender sends an email at the receiver, the receiver.address
> server sends back a message with a random number to the sender.address
> server.
>
> 2. Then, the (E-Mail Removed)ess sends again the email with the exact
> received number to the receiver.address server.
>
> 3. The receiver.address server makes the email available to the
> (E-Mail Removed)ess.
>
> 4. The receiver.address server sends a successful receipt email with the
> same random number.
>
> Thus it is authenticated both that the original email address is valid,
> and that the email reaches its destination.
>
> What do you think?

I think someone's thought of it already more thoroughly.
I think the idea has not gained traction.
I think it's not likely to do so.

See:
http://lipas.uwasa.fi/~ts/info/spamfoil.html

Ioannis Vranos wrote:
> David Schwartz wrote:
>> On Jun 4, 5:12 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
>>> I have thought a solution both for email spam and email reliability
>>> problems, of Internet.
>>>
>>> 1. Assuming a sen...@sender.address and a recei...@receiver.address,
>>> after the sender sends an email at the
>>> receiver, the receiver.address server sends back a message with a
>>> random number to the sender.address server.
>>>
>>> 2. Then, the sen...@sender.address sends again the email with the
>>> exact received number to the
>>> receiver.address server.
>>>
>>> 3. The receiver.address server makes the email available to the
>>> recei...@receiver.address.
>>>
>>> 4. The receiver.address server sends a successful receipt email with
>>> the same random number.
>>>
>>> Thus it is authenticated both that the original email address is
>>> valid, and that the email reaches its
>>> destination.
>>>
>>> What do you think?
>>
>> This turns every single legitimate mail user into a spam relay. Read
>> carefully what your step 2 does, and note that the sender has no way
>> to authenticate that the real recipient *wants* the mail it's about to
>> send.
>>
>> The problem is this: if I can't trust that you want to receive an
>> email, I can't send you an email. So the trust must be established
>> *before* anyone but the initial sender sends any emails. Your scheme
>> fails this requirement.
>
>
> The approach is aimed to be as simple as possible, that is, the current
> design of an email address is to receive email from anyone. My approach
> keeps this design.
>
>
> Also most of the spam emails are sent from botnets and *not* from real
> email accounts.

Doesn't matter who sends it. The bots use "from" lines stolen from people's
address books etc. Most spam that gets past my filter right now says it's
"from" me. So your method would be sending lots of confirm requests to
innocent bystanders who's names were forged.

> The free email provider I am using (www.freemail.gr), provides an
> antispam option named "greylisting" which radically reduced the amount
> of spam I am receiving, from many in a day to very few a week.

Very effective. I use it. Totally different than your suggestion.

>
>
> Here is info about "greylisting" (translated from Greek):
>
> "Greylisting is a ==>transparent checking method of new/unknown senders.
> When it is active, and a sender sends an email for the first time to a
> particular user, Freemail denies to receive it and requests from the
> server of the sender to resend it. This usually happens within a few
> minutes, so the sender address is confirmed without any bother to the
> sender or the receiver".
>
>
> However if an email server is misconfigured, a legit email may not be
> received. However I haven't come across any situation that I haven't
> received any email from someone who is not a spammer, since my alternate
> email address with no antispam protection exists at my site shown in my
> signature in all emails I am sending, and all messages I am posting to
> Usenet, so one could notify me of this.

It happens occasionally. The sender gets a "failed" back from their
server. Also some dumb servers wait hours or days before retrying.
You end up having to whitelist those people if you really want to
talk to them.

> So in summary, my approach is based on the concept of greylisting, and
> is based on the following facts:
>
> 1. 99% of spam emails are sent from botnets with fake or invalid sender
> email addresses.

Not really. A large percentage are forged real addresses these days.

>
> 2. Misconfigured legit servers may not work with greylisting (I haven't
> encountered such a problem so far), and the suggested approach *ensures*
> that the email ==> of only a legit email account is received and not
> rejected by the recipient server.
>
>
> I haven't understood the following of Jan Thomä:
>
> From Jan Thomä <(E-Mail Removed)>:
>
> "It would also allow the spammers to check if a mailbox really exists
> (by simply faking a callback message) and therefore would even promote
> more spam...".

Spam bot sends mail "from" (E-Mail Removed) "to" "(E-Mail Removed)".
"user" auto-responds to "spam" so now spam knows for sure that
"(E-Mail Removed)" is a working email address and should flood it with
ads for viagra.

Joe Beanfish wrote:
> Ioannis Vranos wrote:
>> David Schwartz wrote:
>>> On Jun 4, 5:12 am, Ioannis Vranos <ivra...@freemail.gr> wrote:
>>>> I have thought a solution both for email spam and email reliability
>>>> problems, of Internet.
>>>>
>>>> 1. Assuming a sen...@sender.address and a recei...@receiver.address,
>>>> after the sender sends an email at the
>>>> receiver, the receiver.address server sends back a message with a
>>>> random number to the sender.address server.
>>>>
>>>> 2. Then, the sen...@sender.address sends again the email with the
>>>> exact received number to the
>>>> receiver.address server.
>>>>
>>>> 3. The receiver.address server makes the email available to the
>>>> recei...@receiver.address.
>>>>
>>>> 4. The receiver.address server sends a successful receipt email with
>>>> the same random number.
>>>>
>>>> Thus it is authenticated both that the original email address is
>>>> valid, and that the email reaches its
>>>> destination.
>>>>
>>>> What do you think?
>>>
>>> This turns every single legitimate mail user into a spam relay. Read
>>> carefully what your step 2 does, and note that the sender has no way
>>> to authenticate that the real recipient *wants* the mail it's about to
>>> send.
>>>
>>> The problem is this: if I can't trust that you want to receive an
>>> email, I can't send you an email. So the trust must be established
>>> *before* anyone but the initial sender sends any emails. Your scheme
>>> fails this requirement.
>>
>>
>> The approach is aimed to be as simple as possible, that is, the
>> current design of an email address is to receive email from anyone. My
>> approach keeps this design.
>>
>>
>> Also most of the spam emails are sent from botnets and *not* from real
>> email accounts.
>
> Doesn't matter who sends it. The bots use "from" lines stolen from people's
> address books etc. Most spam that gets past my filter right now says it's
> "from" me. So your method would be sending lots of confirm requests to
> innocent bystanders who's names were forged.
>
>> The free email provider I am using (www.freemail.gr), provides an
>> antispam option named "greylisting" which radically reduced the amount
>> of spam I am receiving, from many in a day to very few a week.
>
> Very effective. I use it. Totally different than your suggestion.
>
>>
>>
>> Here is info about "greylisting" (translated from Greek):
>>
>> "Greylisting is a ==>transparent checking method of new/unknown
>> senders. When it is active, and a sender sends an email for the first
>> time to a particular user, Freemail denies to receive it and requests
>> from the server of the sender to resend it. This usually happens
>> within a few minutes, so the sender address is confirmed without any
>> bother to the sender or the receiver".
>>
>>
>> However if an email server is misconfigured, a legit email may not be
>> received. However I haven't come across any situation that I haven't
>> received any email from someone who is not a spammer, since my
>> alternate email address with no antispam protection exists at my site
>> shown in my signature in all emails I am sending, and all messages I
>> am posting to Usenet, so one could notify me of this.
>
> It happens occasionally. The sender gets a "failed" back from their
> server. Also some dumb servers wait hours or days before retrying.
> You end up having to whitelist those people if you really want to
> talk to them.
>
>> So in summary, my approach is based on the concept of greylisting, and
>> is based on the following facts:
>>
>> 1. 99% of spam emails are sent from botnets with fake or invalid
>> sender email addresses.
>
> Not really. A large percentage are forged real addresses these days.


What you call "forged" I called fake. Where I said fake addresses I meant forged.


If someone uses a forged email address, the real server corresponding to the forged address, will not resend
the email (also it doesn't know the email), so the recipient will never receive the spam.



>> I haven't understood the following of Jan Thomä:
>>
>> From Jan Thomä <(E-Mail Removed)>:
>>
>> "It would also allow the spammers to check if a mailbox really exists
>> (by simply faking a callback message) and therefore would even promote
>> more spam...".
>
> Spam bot sends mail "from" (E-Mail Removed) "to" "(E-Mail Removed)".
> "user" auto-responds to "spam" so now spam knows for sure that
> "(E-Mail Removed)" is a working email address and should flood it with
> ads for viagra.


Well this happens today in the opposite form. If the user doesn't exist, the sender is notified for that.

The difference with the proposal, is that the sender will be notified for both.


If an email address does not exist, the sender will be notified as today.

If an email address exists, the sender will receive an email message with a random number, which can be
interpreted that the email address exists. Today he received no reply for this, which usually means that the
email address is valid.



As you said, you are receiving mostly emails from forged email addresses, for example your email address. With
the validation scheme I am proposing, you wouldn't receive them, as it would be filtered out by your email
server, with 100% certainty that it was spam.



--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

Allen Kistler wrote:
> Ioannis Vranos wrote:
>
>> What do you think?
>
> I think someone's thought of it already more thoroughly.
> I think the idea has not gained traction.
> I think it's not likely to do so.
>
> See:
> http://lipas.uwasa.fi/~ts/info/spamfoil.html


I do not think this has anything to do, with what I said to be used as a feature of the next generation email
service.




--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

Moe Trin wrote:
>
>
> Why should I (or any receiver) accept the mail in the first place?
> Most mail from unexpected senders today is unwanted - usually spam - so
> why should the receiver's mail server waste time and bandwidth on it?


Well, occasionally I receive emails from people I don't know for things regarding programming and programs
(check my site if you want), and I have sent emails to people related to programming and programs, who didn't
know me, with whom I started email discussions.


>
>>>> 3. The receiver.address server makes the email available to the
>>>> recei...@receiver.address.
>
> That is called Back-scatter - look that up in your favorite search
> engine and understand why that will get the senders mail server on
> a black list, or merely blocked at the receiving site.


I am talking about a future new email standard that will have this proposed solution as a feature, which
feature will be transparent to the regular email users, senders and receivers, because it is about email
server "discussions" for the receiver email address authenticity (that the specific email address exists and
it did send the specific email, and was not forged).



>> Also most of the spam emails are sent from botnets and *not* from
>> real email accounts.
>
> Then why does my mail server see thousands of ``returned'' spam that
> is addressed to non-existent users at my domain - spam that was never
> sent from any domain that exists within a thousand kilometers of my
> mail server.


Under this proposal you would not receive those returned spam-related email messages, that you have supposedly
sent, because they would have been determined from your server that they are 100% spam related.


Also messages forged that were sent from your email address, would not reach their destination, because they
would have been determined from the recipient server that they are spam with 100% certainty.


All these would happen, transparently from the users (including you).


>
> news.admin.net-abuse.blocklisting Discussion of ip-based blocklisting.
> news.admin.net-abuse.email Discussion of abuse of email systems.
> news.admin.net-abuse.misc Network facility abuse, including spamming.
> news.admin.net-abuse.policy Discussion of net abuse policy.
> news.admin.net-abuse.sightings Sightings of net abuse.
>
> and see what others think. 'n.a.n-a.blocklisting' is an interesting
> group (moderated, like n.a.n-a.policy and n.a.n-a.sightings - so you
> can't just post anything), and see the whining from mail admins whose
> domains/IP-ranges are listed for abuse such as back-scatter. Read the
> FAQs for the groups. 'n.a.n-a.blocklisting' has existed about six
> years, and there have been some 25000 articles posted to it. You ought
> to read some of those before you try re-inventing the square wheel.


My proposal does not include any block-listing. These are half measures because we are lacking any email
address authentication, that is that a specific email address sent a specific email.



> Yes - you don't understand how spammers work - so you don't understand
> why your plan isn't foolproof. E-mail originated back in the late
> 1960s, before there was an Internet. Computer accounts were rare and
> not to be trifled with. As the Internet became more universal, a
> few idiots realized they could make money by sending out a million
> emails in the hope of finding one or two potential customers. That's
> when the war against spammers began.
>
> Old guy


My plan isn't 100% effective against spam, that is, it is not effective against spam emails that were sent
from a real email address only.


However spams sent from a real email address (and not a forged one) can easily be blocked, by an extension of
the proposal, that a recipient can block a specific address from sending him more emails in the future, by
clicking a "this is a scam" button at his email client, which client would then transparently notify his email
server to filter out future emails from this specific email address for a specific period, 365 days for example.

If many users block this email address this way, then the server can automatically block all emails from the
specific email address to all its users for this specific time period (e.g. 365 days).


All these transparently to the users.





--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net

Corrected:


Moe Trin wrote:
>
>
> Why should I (or any receiver) accept the mail in the first place?
> Most mail from unexpected senders today is unwanted - usually spam - so
> why should the receiver's mail server waste time and bandwidth on it?


Well, occasionally I receive valid emails from people I don't know for things regarding programming and
programs (check my site if you want), and I have sent valid emails to people related to programming and
programs, who didn't know me, with whom I started email discussions.


>
>>>> 3. The receiver.address server makes the email available to the
>>>> recei...@receiver.address.
>
> That is called Back-scatter - look that up in your favorite search
> engine and understand why that will get the senders mail server on
> a black list, or merely blocked at the receiving site.


I am talking about a future new email standard that will have this proposed solution as a feature, which
feature will be transparent to the regular email users, senders and receivers, because it is about email
server "discussions" for the sender email address authenticity (that the specific email address exists and it
did send the specific email, and was not forged).



>> Also most of the spam emails are sent from botnets and *not* from
>> real email accounts.
>
> Then why does my mail server see thousands of ``returned'' spam that
> is addressed to non-existent users at my domain - spam that was never
> sent from any domain that exists within a thousand kilometers of my
> mail server.


Under this proposal you would not receive those returned spam-related email messages, that you supposedly
sent, because they would have been determined from your server that they are 100% spam related.


Also messages forged that were sent from your email address, would not reach their destination, because they
would have been determined from the recipient server that they are spam with 100% certainty.


All these would happen, transparently from the users (including you).


>
> news.admin.net-abuse.blocklisting Discussion of ip-based blocklisting.
> news.admin.net-abuse.email Discussion of abuse of email systems.
> news.admin.net-abuse.misc Network facility abuse, including spamming.
> news.admin.net-abuse.policy Discussion of net abuse policy.
> news.admin.net-abuse.sightings Sightings of net abuse.
>
> and see what others think. 'n.a.n-a.blocklisting' is an interesting
> group (moderated, like n.a.n-a.policy and n.a.n-a.sightings - so you
> can't just post anything), and see the whining from mail admins whose
> domains/IP-ranges are listed for abuse such as back-scatter. Read the
> FAQs for the groups. 'n.a.n-a.blocklisting' has existed about six
> years, and there have been some 25000 articles posted to it. You ought
> to read some of those before you try re-inventing the square wheel.


My proposal does not include any block-listing. These are half measures because we are lacking any email
address authentication, that is that a specific email address sent a specific email.



> Yes - you don't understand how spammers work - so you don't understand
> why your plan isn't foolproof. E-mail originated back in the late
> 1960s, before there was an Internet. Computer accounts were rare and
> not to be trifled with. As the Internet became more universal, a
> few idiots realized they could make money by sending out a million
> emails in the hope of finding one or two potential customers. That's
> when the war against spammers began.
>
> Old guy


My plan isn't 100% effective against spam, that is, it is not effective against spam emails that were sent
from a real email address only.


However spams sent from a real email address (and not a forged one) can easily be blocked, by an extension of
the proposal, that a recipient can block a specific address from sending him more emails in the future, by
clicking a "this is a spam" button at his email client, which client would then transparently notify his email
server to filter out future emails from this specific email address for a specific period, 365 days for example.

If many users block this email address this way, then the server can automatically block all emails from the
specific email address to all its users for this specific time period (e.g. 365 days).


All these transparently to the users, except the original "this is a spam" email blocking.


However I repeat that most spam emails (>90%) are sent by no-existing or forged email addresses, which will be
automatically filtered out by the use of this proposal.





--
Ioannis A. Vranos

C95 / C++03 Developer

http://www.cpp-software.net