Subject: Re: namedroppers, continued

From: "Doug" <[email-masked]>
Date: Mon, 6 Jan 2003 14:38:09 -0500

I believe the answer to your first question is you would send mail
using
your own mail server not someone else's. Although...I do see unique
issues
involved in people using mail servers that are not part of their
network
(hotmail, yahoo...) to send email if they try to authenticate you as
part of
their network before allowing you to send email. I believe the
solution to
that problem is that those commercial mail servers (free or premium)
would
not be able to authenticate you as part of their network before
allowing you
to send your email. They would then require clients logging into those
accounts (with valid user names and passwords) to send email from a
valid IP
address with no unsecured proxy services running on them (much like
many IRC
servers are doing) and transmit this IP information along with the
email
being sent. This would allow for pinpoint identification of the
sender's
using IP addresses MAC addresses and time stamped logs for the
specific
purposes of taking legal action against these network abuses.

Your second question is a bit harder for me to answer. I believe (I
may be
incorrect) that there is already a difference between a receiving mail
server's transaction with a sending or relaying mail server and a mail
client. I would never claim that it is impossible for a malicious user
to do
anything (I know better). On the other hand if we can achieve
authentication
before sending email and it becomes a requirement of the system then
it
should make the actions of a malicious user stand out in the logs of
the
server allowing for tracking, blocking, and prosecution of those users
for
the unauthorized access and (mis)use of private network resources. My
solution does NOT have a way of completely stopping spam from being
sent but
perhaps in conjunction with other actions it can stop a majority of
spam
from being sent. Additionally, my solution makes it easier for end
users and
administrators to track the actions of spammers and find their virtual
locations. I would further suggest that once this information is
gathered
and verified with the spammers ISP subpoenas, court orders, cease and
desist
orders, fines under existing laws, and criminal prosecution could do
the
rest.

I am not claiming that this will eliminate spam on it's own. I am
claiming
that it will make it harder for the offending parties to get away with
sending spam in a manner that is not compliant with TOS agreements and
the
law. This solution would require a concerted effort by the
administration
comunity as a whole and I think that is where the problem truely is.

----- Original Message -----
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "Doug" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 06, 2003 10:00 AM
Subject: Re: namedroppers, continued

>
>
> --On mandag, januar 06, 2003 02:01:27 -0500 Doug
<[email-masked]>
> wrote:
>
> >> Your proposal would fix the problem, but end up tossing a large
quantity
> >> of babies out with the bathwater.  The problem is that for the
case of
> >> a mailing list, you have *4* (at least) things to keep track of:
> >
> > There are many comercial email servers that require the people
sending
> > email with their server to log into the server using a valid
username
and
> > pass before
> > doing so. I doubt they are losing any valid emails. All it does is
to
keep
> > unauthorized users from using the server without a valid password.
The
> > reason
> > to require that the sender address in the outgoing email matches
the
email
> > address refrenced in the account is to keep people from sending
spam
from
> > these email servers and using fraudulant return and/or sender
address.
> > I fail to see how this throws out any babies. perhaps I am missing
> > something.
>
> well....think about how mail from someone who is not an user of that
system
> (like me) can send mail there....
>
> how does your system tell the difference between a remote mail
server and
a
> malicious user?
>                  Harald

---

From: [email-masked]
Date: Mon, 06 Jan 2003 15:36:54 -0500

On Mon, 06 Jan 2003 14:38:09 EST, Doug <[email-masked]>  said:
> their network before allowing you to send email.
You're still missing the point.

How do you tell the difference between:

1) The IETF mail server sending for the IETF list.
2) The large SUN box across the hall that's the main vt.edu mail server.
3) My laptop.

Currently, my laptop will send directly to the destination.  The problem is
that although it would be trivial to change it so that it uses the central
Virginia Tech mail hub, that doesn't fix your problem - there's still no
authenticator for the vt.edu mail server at your mail server either....

Oh, and don't even suggest chasing MX records - the MX for vt.edu points
at one set of boxes, but you will almost certainly *NOT* get a connection
from them, as our outbound servers are at different addresses.  And no, we
won't change this unless you first manage to get hotmail.com and aol.com
to not use different inbound and outbound addresses first, as they do the
same thing for the same reasons.
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

---

From: "Doug" <[email-masked]>
Date: Mon, 6 Jan 2003 18:08:44 -0500

I am apparently missing something here but I am going to give it a
shot anyway.

You can tell the difference between 1, 2, and 3 because they all have
a different DNS/IP footprint.

You can send email directly to the IETF mail server? Do you have an
account on that server?

I myself use a SMTP server to send out my email. It goes from my email
client to the SMTP server I happen to be using and it then gets
relayed through the network until it reaches the destination email
server.

The validation I have been referring to would take place between the
mail client and the originating server. The entire point would be to
verify the identity of the person sending the email or at least the
account it is being sent from.

I am not suggesting that the destination email server should ask for
authentication for every email it receives before it relays it on to
another mail server or a client. I am saying that the originating
server should ask for it before accepting it and relaying it on to the
network.

The originating server would then be able to assure correct header
information by not allowing an email to be sent unless the outgoing
email was tagged with the proper DNS/IP footprint (not that of an
unsecured proxy server or a spoofed IP) and a return/reply address
that is associated with the account that the client used to
authenticate with the server. This in effect means that you cannot use
a different return/reply address (or a fake return/reply address) that
cannot be traced back to your account on the originating server by the
recipient or an IP/DNS footprint that cannot be traced back to your
machine or a point on your network by the recipient. This is to force
the person sending the email to be accountable for the email sent.

I am not suggesting that the recipient or even the relaying server
should be allowed to connect back to the originating mail server or
the client that sent the email. That would create security risks for
networks hosting mail servers and clients sending the email.

I am suggesting that before someone drops an email onto an originating
mail server that the server should take what I consider to be
reasonable steps to authenticate the user and confirm their identity
and account status on that server. The server would then tag
information onto the email that would identify the machine on which
the email client that sent the email resides (not the information of
an unsecured proxy). In addition, the originating server should tag
information that identifies the account (on the originating
server/network) that the client used to send the email and force the
originating client to provide a valid reply address that is associated
with the account to the recipient of the email.

I am not suggest that originating servers should be tagging the exact
virtual location of an inbound or outbound server to anything or
changing MX records to reflect the correct virtual location to the
outside world. In fact, if this is not done it helps keep those
outbound email servers hidden from the outside world and helps keep
malicious users from finding them and exploiting them in some way to
send their email without authorization. I do feel that I should be
able to identify the actual network on which that server resides so I
can contact someone there to help track down someone who is sending
spam.

Does the above clear up any confusion? Is there anything I am missing
here? If so please tell me what because I would welcome the
opportunity to learn something new. There may very well be big gaps in
this plan I am just unaware of what they are so I welcome the
opportunity to learn that you or anyone may pointing them out would
bring.

Doug
[email-masked]
704-721-0212

P.S. As a side note if anyone thinks this is not a proper forum for
exchanging ideas about this please do tell me. It is not my goal here
to disrupt anything. I am just trying to exchange some ideas with a
large body of professionals in the hopes of learning something and
hopefully contributing something helpful. I would also like to invite
the moderators of this forum to contribute what they think of this
line of discussion. If they think it is unproductive I would be more
than willing to drop it and never breath another word about anything
unless it falls into any guidelines they would like to set forth.
Please, anyone, do feel free to respond with anything you feel would
be helpful constructive or apropriate on this subject.

---

From: Melinda Shore <[email-masked]>
Date: Mon, 06 Jan 2003 22:26:31 -0500

In that environment, anybody can get around what you're
proposing by setting up their own first hop mail server.
Or <n> hop mail server, for that matter.

Melinda

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 7 Jan 2003 12:05:43 +0000 (GMT)

Doug has rediscovered the idea of closing open mail relays to prevent
unauthorised use by outsiders sending to outsiders. This was a big
thing in the early 90s when email became popular.

Doug has also come up with the idea of adding the IP address of the
originating client machine (not necessarily using SMTP) in a header
so that an attempt can be made to identify it - e.g. Hotmail has done
that for years.

L.

missing mail admin experience, I think.

On Mon, 6 Jan 2003, Doug wrote:

> _______________________________________________
> This message was passed through [email-masked], which is a sublist of [email-masked]. Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
>

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: [email-masked]
Date: Mon, 06 Jan 2003 23:12:31 -0500

> a different DNS/IP footprint.

They do? Are you sure of this?  I'll give you a hint - if you're outside
the two /16's of our network, and you get an inbound SMTP connection from us,
looking up the PTR to get the hostname will almost certainly *NOT* have
the string 'mail' in it.

And the inbound and outbound mail servers at ietf.org are called 'odin' and
'ran', respectively..  Not much info there.

And last I heard, about 30% of the PTR space is broken beyond use due to
cluenessness on the ISP's part, so you can't get a DNS name you can trust.

So what DNS/IP footprint were you planning to use?

> You can send email directly to the IETF mail server?

Yes, sometimes multiple times an hour if I'm in a verbose mood...

>                                                       Do you have an

Nope, no account there. Don't need one, works fine..

> relayed through the network until it reaches the destination email

OK.. to be *very* pedantic, I use an SMTP server as well.  My MUA (Mail
User Agent) exmh hands the mail to the SMTP server I happen to be using,
and the SMTP server relays mail everyplace.  It just happens that my preferred
SMTP server happens to be already running on my laptop....

> server should ask for it before accepting it and relaying it on to the

Aha.  I see now.  What you *want* is what all properly run mail servers
*ALREADY* do.  It's amazingly useful for tracking down users that are being
silly and need a slap upside the head to clear the kloo blockage.  What
it's NOT useful for is stopping the determined spammer who doesn't use
your mail server to inject the mail into the net....

The reason it doesn't stop spam is because you're missing an important
point - you seem to think that "if the sending server validates the user,
we won't have spam.."

> a different return/reply address (or a fake return/reply address) that

Hmm.. so the mail I'm replying to wouldn't work, because I got it from the IETF server
but it has your From: address on it - therefore the IETF server must be
lying about who it is and who the sender is.

Actually, that's not quite true - there's usually 
> the person sending the email to be accountable for the email sent.

OK.. and this is *forcing* it *how*?

Think carefully here - the receiving end is trusting what the sender
sends.

> with the account to the recipient of the email.

And of *COURSE*, not even a SPAMMER would be so unrighteous as to forge
a "this mail was approved" header.

This mail has a 'X-Verified-Sender-Address:' header that identifies
the originating address.  Take a look at it, and tell me if you feel any
better about having verified the origin.  And remember that since I control
my machine, I can make a similar change to any *OTHER* header (From:, Sender:,
X-Authenticated:, or whatever).

And the spammer controls his server....

/Valdis

---

From: jfcm <[email-masked]>
Date: Tue, 07 Jan 2003 14:56:36 +0100

>missing mail admin experience, I think.

This remarks shows that the problem is around for more than ten years and 
that no one found a satisfactory solution in using the present system. 
Would this feed back from real world not be enough for us to understand its 
'cybernetic' (true meaning) lesson : the current mail system model is 
inadequate.

Question now is : do we have to investigate a new one? or can an 
architectural change/addition may elegantly address the case? probably a 
mix of both due to the existing e-mail system use. ie a new e-mail system 
with a retro-compatibility with the current one. Or would it also be a new 
TCP/IP design, compatible with the old one? Or/and a new IPv6 compatible 
with the old one?

May be Dick Clarke will tell us next week how much he wants to invest into 
such a Nextnet?
jfc

---

From: jfcm <[email-masked]>
Date: Tue, 07 Jan 2003 14:56:36 +0100