Subject: [Asrg] A possible way to a solution?

From: Olger Diekstra <[email-masked]>
Date: Thu, 20 Mar 2003 10:06:42 +0100

Hi all,

I've been monitoring the list for the past few days now. Hearing (well, reading) everyone with all 
the different types of solutions and arguments brings me to the following concept. Although its far 
from covering everything, there are still some lose ends, I think its a good starting point. 

Although spam should be (and in most countries is) illegal, that's not going to stop it. As long as 
there are countries that are more flexible to spammers, it will be hard to get them before court. 
Which ultimately leads to conclude that the law is not going to be able to solve this. So any 
discussion whether it should be more illegal or not, heavier punishments or cheaper ways to bring a 
spammer to justice will not make spam go away. In other words, a futile discussion.
Since justice needs a person or organization to stand trial, what we need to do first is find out 
who is spamming in a legal way. Then Justice can take place much more easily.

Content filtering is (as has been pointed out before) ultimately an enduser solution. As email can 
be encrypted (although encrypted spam is hardly very likely) it becomes difficult for an automated 
process to be checked. Besides, the same content can sometimes be wanted and sometimes be spam (as 
has also been described in emails from others on the list). If I like to write dirty to my 
girlfriend, that is not spam. However, if it is to thousands of users around the world that I do 
not know, that would make it spam for most, although there might still be a few who would want that 
kind of mail...

Systems that rely on remote systems setting tags, or having certificates are also not very reliable 
in the end. They can be forged. If a spammer has its own mailserver, it can forge any tag that is 
invented to prevent spam.

Seperation of spam and legitimate mail must be close to 100%. Something like 99.99999%. If on a 
billion mails only one gets lost, that's acceptable to me. Furthermore, the traffic spam consumes 
must be reduced to its absoluut minimum. Determining if an email is spam can only be done at the 
receiving side on the server or on the client. A spammer can be a legitimate sender at one time, 
and a spammer at another.

Which ultimately leads me to the conclusion that the receiving mailserver should be the first place 
to start. This is the place where the spammer has no control over. If he knocks on my door and 
doesn't know the password, I can simply keep the door locked. Whatever authentication or 
certification my mailserver wants to receive an email, the spammer will have to comply to. (As long 
as my security on the server is sound of course...But even then, if security is low, the spammer 
will have to be a hacker as well, totally different skills, and much more timeconsuming).

So the question is probably, how do we do that?
Firstly, I want my mailserver to garantee the sender. That will give me much more control. 
The server could do this as follows: whenever a remote mailserver sends an email to a receiving 
mailserver, the receiving mailserver should lookup the domain of which the sender claims the email 
is from, contact the mailserver of that domain, and check it is actually trying to send the email.
This will garantee the source to my mailserver, giving me full control over the check. It will be 
very difficult for the spammer to forge this.
Now a problem rises for users that send from a mailserver that's is not part of the source domain. 
Like mobile users sending mail from their hotelroom, home users sending with an office 
emailaddress, etc. This can be solved by informing the mailserver of the domain in the FROM field 
that a message is being send. Basically, you could send the header of the email which will provide 
enough information. For this to happen reliably, the user would have to login to the mailserver. In 
the end, if the mailserver of the domain in the FROM field is not notified, the sender will not be 
able to get the email to me.

So now that I know the source,  I could setup a list of users on the mailserver that are save. 
Whenever the mailserver receives an email for me, it'll check against the list of known addresses. 
If the sending party is in my list, the email can go right to my mailbox. If not, additional action 
is needed (and has to be defined). Very safe, and without too much need for server resources.
I can still send email from anywhere in the world to anyone. Thus, I can create a whitelist of 
folks whom I trust. Of course, I would need to setup all my emailboxes with the necessary filters.

This mechanisme ensures that an email can be traced back to the sending domain, it has to have a 
valid sending emailaddress of which the domainname is registered in DNS and the authorized 
mailserver of that domain must have send the email.
If more mailservers exists within the sending domain, it is likely that the receiving mailserver 
connects to a different mailserver from the sending domain. So there also has to be a mechanisme 
for the sending mailservers to communicate amongst each other. Basically, it should do a sort of 
broadcast to is fellow mailservers of the domain, and ask if anyone is sending the email.

Since we now know who is sending the spam (forging emailaddresses just became much more difficult) 
we can put up a blacklist with known spammers. An email server should be able to either mirror it 
in case the blacklist goes down (due to a DoS attack of some sort) or use it realtime. Every user 
should have an option somewhere, in its client, thru a website of the ISP, whatever, to select a 
particular blacklist and tell the emailserver to use that list or lists for the users mailbox. The 
email server will first use the users whitelist, and then the blacklist.
If a user considers an email spam, it should be able to reply the email and sent it out again, 
using a special tag in the subject stating SPAM or something. The email server will pick this up 
and instead of sending the reply to the spammer (though he might get perhaps a copy?) it will sent 
it to the blacklist.
If the sending address gets, say, twenty emails from different persons stating the sender is a 
spammer, it could be added to the list.

Spammers who use a temporary hotmail account might still form a problem, but they will not be able 
to send email using that account if they do not notify the hotmail emailserver. Webmail accounts 
usually can only be used from a webpage which sends the email using an unknown (to the sender) 
mailserver. I have a feeling spammers are not going to use a webpage to construct thousands of 
email spam....

Remember, this is just a thought (though a long one...) of how it could be done. The above 
described method can be slowly implemented in the existing systems. If users also authenticate to 
SMTP servers, the ISP or administrator can also make sure no unauthorised person gets to use the 
mailserver. In the end, it will make spamming a whole lot harder. 

Happy thinking! 

Olger Diekstra.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Wed, 19 Mar 2003 23:46:28 -0800 (PST)

Once again this is type of verification based on DNS, I described majority 
of this approaches in my presentation and in the beginning described what 
these approaches would need to deal with and the solution described here 
is pretty much what I called complex mail verficiation. Again ANYBODY who 
is considering doing any kind DNS based mail sender verification any kind 
of solution like has been discussed at "Domain Authorized SMTP Mail" 
thread and RMX and number of other threads (and there are many many people 
like this on the list), I strongly recommend to read my presentation at:

http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf

(Note that right now it looks like I will not be presenting this on actual 
meeting as chair has chosen different presentations for it)

I also do think that being able to track spammer to his real location will 
go 1/2 way in stopping them, the rest would fall into being able to 
contstruct good black/whitelists and doing legal and other actions to
close spammer business.

-- 
William Leibzon
Elan Communications Inc. 
Office & Support: 408-519-6243
Sales: 877-ELAN-NET or 650-333-7658

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 20 Mar 2003 13:38:23 -0500

[email-masked] wrote:
> I strongly recommend to read my presentation at:
> 

  I think the document is very helpful.  Simply having the picture of
a complex "real-word" e-mail deliver path means that any potential
solution can point to the picture, and say "we fit here."  That
capability was what was missing from many of the proposed solutions.

  Alan DeKok.

---

From: [email-masked] (Justin Mason)
Date: Thu, 20 Mar 2003 15:55:56 -0800

> capability was what was missing from many of the proposed solutions.

Yes, it's a good summary of some troublesome spots in modern SMTP use.

--j.

---

From: "Ye Olde Curmdudgeon" <[email-masked]>
Date: Thu, 20 Mar 2003 20:06:11 -0500

I don't have time to read all of the messages so it's likely that
someone pointed out some serious flaws in this approach. But first I
need to emphasize the difference between the envelope used to transport
the message and the header which is like the inner header in a business
letter and it is entirely optional. Sure, you're supposed to have from,
to and date but it works without it. There is an unfortunate design
error in that envelope is out of band and there is no standard way to
preserve it. This should be fixed but ...

Second, the word "forge", that's a moral term. One synthesize the
envelope for whatever purpose is appropriate and we shouldn't prejudge
this. In fact, I have to forge the from address for this letter in order
to keep the list manager happy since I use a different address for each
list. It isn't bogus, just informative. The Caller-ID for phone calls is
buggy since it doesn't tell me who is calling, just which phone they
happen to be using. I don't want to have be authorized to send mail.

How do you know I'm not a synthesized persona or that I don't present
different persona depending upon my role, job or mood. That's normal and
fundamental to living in an ambiguous universe.

You cannot get authentication from the DNS. It's just a repository of
lookup keys that get reused over time (unfortunately). Authentication is
a very deep and complex concept and there is no magic trust algebra. You
can buy services for vouching or other purposes from third parties and
require others who communicate you meet your own criteria such as having
VeriSign certs or having ones generated by Joe if you want "Joe sent me"
in your own private key community. Or you can simply have their bank say
"yeah, he has the money to cover the purchase".

Conclusion. This is not an Email issue -- it's a product that you might
want to offer but it cannot be mandated any more than you can have .XXX
and .KIDs.

Also, please define what it means for mail to be delivered?

PS: I am replying to the forwarded pointer because it also illustrate a
bigger problem -- the damn wrapping that occurs because of teletype
compatibility mode. I'm became quite proficient with the KSR and ASR
33,35,37 and 43 (well, not much with the 43 -- too new). But that
doesn't mean I'm glad to be living in the 1960's in terms of email. But
that's a separate grip -- I resisted using HTML though that's enough of
a reason to use it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan
DeKok
Sent: Thursday, March 20, 2003 13:38
To: [email-masked]
Subject: Re: [Asrg] A possible way to a solution? 

  Alan DeKok.

---

From: Olger Diekstra <[email-masked]>
Date: Fri, 21 Mar 2003 10:58:21 +0100

I didn't mean to use DNS for authentication.
I'll illustrate the method I had in mind for this. If my receiving mailserver gets a message from a 
remote mailserver, it'll use the emailheader which contains the FROM field (basically, I think the 
FROM field should contain the senders address, like there's ultimately one TO field that really 
matters, there should also be one FROM field that contains the actual senders address. That's the 
one I'm gonna check.). From that field I take the domainname, look it up in DNS, get the 
mailserver's IP address, and then contact that mailserver. Using a new protocol my mailserver 
communicates with the sending mailserver, to find out whether or not it is actually trying to send 
an email to my mailserver.
If the domain in the FROM emailaddress nonexistence, the email will get bounced. The sender will 
get notified by means of an email. The sender can then take appropriate action, and eventually 
resend his/her email. With a correct emailaddress.
DNS is used as it was intended, not for authentication, not with rDNS.

There's no point in trying to find a solution that will totally eliminate spam. It might work for a 
while, but anything is ultimately breakable. In my opinion, its better to make it very hard to 
spam, and/or give a spammer a lot of work to sending his/her email.
Just look at the all the copy protection schema's that are around. They make it harder to copy a CD 
or DVD for a while, not impossible. 

Olger.

>Once again this is type of verification based on DNS, I described
>majority of this approaches in my presentation and in the beginning
>described what these approaches would need to deal with and the
>solution described here is pretty much what I called complex mail
>verficiation. Again ANYBODY who is considering doing any kind DNS
>based mail sender verification any kind of solution like has been
>discussed at "Domain Authorized SMTP Mail" thread and RMX and number
>of other threads (and there are many many people like this on the
>list), I strongly recommend to read my presentation at:
>
>(Note that right now it looks like I will not be presenting this on
>actual meeting as chair has chosen different presentations for it)
>
>I also do think that being able to track spammer to his real
>location will go 1/2 way in stopping them, the rest would fall into
>being able to contstruct good black/whitelists and doing legal and
>other actions to close spammer business.
>
>>I've been monitoring the list for the past few days now. Hearing
>>(well, reading) everyone with all the different types of solutions
>>and arguments brings me to the following concept. Although its far
>>Although spam should be (and in most countries is) illegal, that's
>>not going to stop it. As long as there are countries that are more
>>flexible to spammers, it will be hard to get them before court.
>>Which ultimately leads to conclude that the law is not going to be
>>able to solve this. So any discussion whether it should be more
>>illegal or not, heavier punishments or cheaper ways to bring a
>>Since justice needs a person or organization to stand trial, what
>>we need to do first is find out who is spamming in a legal way.
>>Then Justice can take place much more easily.
>>
>>Content filtering is (as has been pointed out before) ultimately an
>>enduser solution. As email can be encrypted (although encrypted
>>spam is hardly very likely) it becomes difficult for an automated
>>process to be checked. Besides, the same content can sometimes be
>>wanted and sometimes be spam (as has also been described in emails
>>from others on the list). If I like to write dirty to my
>>girlfriend, that is not spam. However, if it is to thousands of
>>users around the world that I do not know, that would make it spam
>>for most, although there might still be a few who would want that
>>kind of mail...
>>
>>Systems that rely on remote systems setting tags, or having
>>certificates are also not very reliable in the end. They can be
>>forged. If a spammer has its own mailserver, it can forge any tag
>>that is invented to prevent spam.
>>
>>Seperation of spam and legitimate mail must be close to 100%.
>>Something like 99.99999%. If on a billion mails only one gets lost,
>>that's acceptable to me.
>>Furthermore, the traffic spam consumes must be reduced to its
>>absoluut minimum. Determining if an email is spam can only be done
>>at the receiving side on the server or on the client. A spammer can
>>be a legitimate sender at one time, and a spammer at another.
>>
>>Which ultimately leads me to the conclusion that the receiving
>>mailserver should be the first place to start. This is the place
>>where the spammer has no control over.
>>If he knocks on my door and doesn't know the password, I can simply
>>keep the door locked.
>>Whatever authentication or certification my mailserver wants to
>>receive an email, the spammer will have to comply to. (As long as
>>my security on the server is sound of course...But even then, if
>>security is low, the spammer will have to be a hacker as well,
>>totally different skills, and much more timeconsuming).
>>
>>Firstly, I want my mailserver to garantee the sender. That will
>>give me much more control. The server could do this as follows:
>>whenever a remote mailserver sends an email to a receiving
>>mailserver, the receiving mailserver should lookup the domain of
>>which the sender claims the email is from, contact the mailserver
>>of that domain, and check it is actually trying to send the email.
>>This will garantee the source to my mailserver, giving me full
>>control over the check. It will be very difficult for the spammer
>>to forge this.
>>Now a problem rises for users that send from a mailserver that's is
>>not part of the source domain. Like mobile users sending mail from
>>their hotelroom, home users sending with an office emailaddress,
>>etc. This can be solved by informing the mailserver of the domain
>>in the FROM field that a message is being send. Basically, you
>>could send the header of the email which will provide enough
>>information. For this to happen reliably, the user would have to
>>login to the mailserver. In the end, if the mailserver of the
>>domain in the FROM field is not notified, the sender will not be
>>So now that I know the source,  I could setup a list of users on
>>the mailserver that are save. Whenever the mailserver receives an
>>email for me, it'll check against the list of known addresses. If
>>the sending party is in my list, the email can go right to my
>>mailbox. If not, additional action is needed (and has to be
>>defined). Very safe, and without too much need for server
>>resources.
>>I can still send email from anywhere in the world to anyone. Thus,
>>I can create a whitelist of folks whom I trust. Of course, I would
>>need to setup all my emailboxes with the necessary filters.
>>
>>This mechanisme ensures that an email can be traced back to the
>>sending domain, it has to have a valid sending emailaddress of
>>which the domainname is registered in DNS and the authorized
>>If more mailservers exists within the sending domain, it is likely
>>that the receiving mailserver connects to a different mailserver
>>from the sending domain. So there also has to be a mechanisme for
>>the sending mailservers to communicate amongst each other.
>>Basically, it should do a sort of broadcast to is fellow
>>mailservers of the domain, and ask if anyone is sending the email.
>>
>>Since we now know who is sending the spam (forging emailaddresses
>>just became much more difficult) we can put up a blacklist with
>>known spammers. An email server should be able to either mirror it
>>in case the blacklist goes down (due to a DoS attack of some sort)
>>or use it realtime. Every user should have an option somewhere, in
>>its client, thru a website of the ISP, whatever, to select a
>>particular blacklist and tell the emailserver to use that list or
>>lists for the users mailbox. The email server will first use the
>>users whitelist, and then the blacklist.
>>If a user considers an email spam, it should be able to reply the
>>email and sent it out again, using a special tag in the subject
>>stating SPAM or something. The email server will pick this up and
>>instead of sending the reply to the spammer (though he might get
>>perhaps a copy?) it will sent it to the blacklist.
>>If the sending address gets, say, twenty emails from different
>>persons stating the sender is a spammer, it could be added to the
>>list.
>>
>>Spammers who use a temporary hotmail account might still form a
>>problem, but they will not be able to send email using that account
>>if they do not notify the hotmail emailserver. Webmail accounts
>>usually can only be used from a webpage which sends the email using
>>an unknown (to the sender) mailserver. I have a feeling spammers
>>are not going to use a webpage to construct thousands of email
>>spam....
>>
>>Remember, this is just a thought (though a long one...) of how it
>>could be done. The above described method can be slowly implemented
>>in the existing systems.
>>If users also authenticate to SMTP servers, the ISP or
>>administrator can also make sure no unauthorised person gets to use
>>the mailserver. In the end, it will make spamming a whole lot
>>harder.
>>
>>Happy thinking!
>>
>>Olger Diekstra.
>>
>>
>>_______________________________________________ Asrg mailing list
>>[email-masked] https://www1.ietf.org/mailman/listinfo/asrg
>>
>

---

From: mathew <[email-masked]>
Date: Sun, 23 Mar 2003 09:24:20 -0500

On Thursday, Mar 20, 2003, at 20:06 US/Eastern, Ye Olde Curmdudgeon 
wrote:
> The Caller-ID for phone calls is buggy since it doesn't tell me who is 
> calling, just which phone they happen to be using.

Actually, caller ID as sold to residential customers is no better than 
a From: line. There are autodialer products on sale that will set the 
caller ID readout to be whatever the telemarketer wants; see RISKS 
digest recently.

Not many telemarketers bother to use them, presumably because not 
enough people screen on the basis of caller ID for it to be worth the 
outlay.

It'll be interesting to see if the "do not call" list signed into law 
results in telemarketers setting up fake caller ID info and calling 
anyway.

mathew

---

From: [email-masked]
Date: Sun, 23 Mar 2003 11:18:08 -0800 (PST)

</rant>
 
> caller ID readout to be whatever the telemarketer wants; see RISKS 
I can attest to that. When I was running dialup ISP with PRIs for incoming 
calls, I also tried outgoing and could set phone# to anything I wanted. I 
even setup system to deliver free pages but setting it to call with 
specific caller-id and then hang-up (so it would be incomplete call but 
I'd still see numeric page), of course its irrelevent as now numeric pages 
are free and text pages are fairly inexpensive.

> results in telemarketers setting up fake caller ID info and calling 
There are other ways to find who the caller is even if they do not want 
to. There are some who setup traps on it and telemarketers will be caught.

</rant>