Subject: Re: namedroppers, continued

From: "Doug" <[email-masked]>
Date: Sun, 5 Jan 2003 19:04:41 -0500

Hello everyone,

It seems to me if the mail server administrators would make the decision to
require people that send emails from their servers to log into a valid
account on that server and use the same valid account on the server as a
return address it would negate the ability of a large percentage of the
spamers to send the spam anon. This would allow easier filtering of many of
the offending messages by domain. Additionally, the sending account field
and the reply to field should be equal and clients should be required to use
an email address that is associated with the account used to log into the
server in the first place. This will need to be implemented in the beginning
by administrators who run software capable of it, and it would be
implemented later as part of the email client and/or server software using
new software releases, patches, and individual customizations of existing
software. I know that there are many people who will scream and gnash their
teeth at this suggestion as it will force them to identify themselves to
anon mailing lists but I think it would be an acceptable compromise if we
could eliminate a major portion of the spam clogging our inboxes. Clients
need to be identified by ISP based email servers using their DNS and IP
address footprints and clients attempting to send email with improper
footprints should be disregarded (making it very difficult to send email
from the server if you truly are not a valid subscriber to the service, much
like many of the current news servers do). Then to deal with the anonymous
email servers out there (hotmail, yahoo, etc...) the operators of those
services should require clients logging into those accounts 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 senders of spam using IP addresses MAC addresses and
time stamped logs for the specific purposes of taking legal action against
these network abuses. I know it will be argued that this will require
cooperation between ISPs and that some systems are already implementing
these measures but if all administrators as a single body insist that
everyone adhere to these rules or be excluded from sending email to clients
of their services and enforced this through IP block and domain blocking the
stragglers would be forced to adhere to these rules. Further, if a body such
as the IETF stood behind this and perhaps drafted specifications for
administrators, and software developers to follow when making new
clients/servers and updating existing clients/servers it would hold added
weight in the market place. The extra cost associated with such actions
could be offset by saved resources, and additional revenues made as a result
of higher subscription rates justified by superior spam filtering techniques
and a greater number of subscribers to the service due to better service
quality. I would also like to suggest that the California law that requires
all unsolicited emails be appended with adv: in the subject line be expanded
to a federal law and additionally require emails that are solicited by
signing up for a service include exact information about who the sender
bought your email address from in the email.

These are just some ideas I have had on eliminating spam and should in no
way be considered a flame against anyone. I know there is no way that this
will stop all unsolicited email from being sent or received. I just thought
they might help to get some people rolling on a solution and that it would
be better than complaining about it. After all doesn't a global solution
make more sense than venting about what should be done to keep it out of
this mailing list.

Thank you for your time and attention,

Douglas Huyler
[email-masked]
704-721-0212

P.S. I am sorry this email comes so long after the original post was made
but I don't read the list very often and after reading this thread from the
begining to December 6th I thought I would reply. If someone else has
brought these things up after this point I am sorry, but I haven't caught up
with the list yet.

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, December 06, 2002 4:41 PM
Subject: RE: namedroppers, continued

> At 08:28 AM 12/2/2002 -0800, Hallam-Baker, Phillip wrote:
> >The only way to resolve this issue properly would be to require every
> >submission to an IETF mailing list to be cryptographically signed (PGP
> >or S/MIME), to require the subscribers to register their signing key and
> >to then filter the mail sent out on the list so that only signed mail
> >gets through.
>
> I would be in favor of that, personally, as long as we can ensure that the
> appropriate signature facility (be it RSA, PGP, or whatever) is freely
> available to all who need to use it. The issue here is not us corporate
> types who have a business reason to buy the software, it is the students
> who often lack the funds. The big issue would be the procedures for
posting
> one's key to the appropriate place - what is to stop a spammer from
posting
> a key and sending the spam anyway? I'm not proposing a mechanism, but
> someone who is good at such things might well find it of value.
>
> It doesn't address the "off topic" issue. As you say, that could be left
to
> a working group chair equiped with formal procedures developed by
consensus
> within the work group or adopted by the working group from a more general
> place (ie, the IETF could suggest a procedure, and the WG could adopt it
if
> it didn't feel another procedure would be better).
>
> I have had a private exchange, over the past few days, with someone who
> wished that the IETF would please document some good spam-elimination
> procedure, so that it could be used world-wide to completely eliminate
> spam. I think that boils down to "provide a global PKI" in this solution,
> and presumes that spammers are incapable of using one. That might be a
> great research topic. Too bad nobody has ever thought of it before; we
> could really use the outcome of that research. (OK, so it's a lame attempt
> at humor...)
>
> I think it was Steve Bellovin that suggested a procedure for reducing the
> utility of spoofing source addresses in emails; if not, it was me and I
> happened to suggest something his favorite algorithm fit into, by having a
> host in each mail domain (mailid.example.com) be able to assert that its
> domain had or had not sent an email within a given recent  time period
> whose MD5 hash, when divided by <vector of prime numbers> resulted in
> <vector of remainders>. I could write that up in an internet draft if
folks
> think it makes sense. That would be a more global procedure that didn't
> require a PKI and only addressed spoofed addresses.
>

---

From: [email-masked]
Date: Mon, 06 Jan 2003 01:23:48 -0500

> require people that send emails from their servers to log into a valid

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:

1) The RFC821 recipient address.  For your copy of this posting, it's "your
email address".

2) The RFC821 sender address.  It should be available in the Return-Path:
header in most well-behaved mail systems as you look at your mail.

3) The RFC822 From: address.

4) The RFC822 To: address.

Another problem is that I am (fortunately) still receiving more mail
each day that counts as "legitimate unsolicited" (problem reports about
our servers, people who have seen my name and are looking for technical
advice, etc) than I do actual spam.

It's not as easy as it looks... :)

/Valdis

---

From: "Doug" <[email-masked]>
Date: Mon, 6 Jan 2003 02:01:27 -0500

----- Original Message -----
From: <[email-masked]>
To: "Doug" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 06, 2003 1:23 AM
Subject: Re: namedroppers, continued

>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.

>4) The RFC822 To: address.

I know what the recipient address, sender address, from address, and to
address in headers look like. The problem is that many spammers use false
information here and change it on a regular basis. This makes it impossible
to block their email at the client end. My proposal is very basically to
make
it mandatory to put valid information in these fields in order to be able to
send the email.

>advice, etc) than I do actual spam.

I also never intended for servers to be using filters on unsolicited emails
just
because they are unsolicited. My intention was to suggest that people who
were sending unwanted and unsolicited "comercial" email should be blocked.
I suggested that servers that refused to cooperate with the rest of the spam
hating world could be blocked just in case but, this may be a bit harsh.
In addition the steps I mentioned would allow for the person receiving these
emails to gather information to allow them to easily take legal action
against the
spammers that still managed to get through. IE if everyone is forced to use
valid
information in the headers to be able to send the email without using some
exploit on the server then it should be easy to track them down. If of
course
they are forced to use exploits to send their anon spam then the admins of
the
system would eventually find this and take action to block them and/or
prosecute them. Perhaps you could be scanning header information as well on
the receiving server (not the client or the sending server) to allow you to
check
for nonsense return addresses like [email-masked] or fraudulant source DNS
and IP information. Another thing that could be checked for is wether the
sending account matches the reply to address.

>It's not as easy as it looks... :)

Oh no I never said it was easy and I also never said I knew it all. I am
just
making a suggestion as to a possible solution to the problem.

:)
Doug

>/Valdis

P.S. I do seriously want to know how this would stop valid email users from
getting/sending their email.

---

From: "Ramana Divvi" <[email-masked]>
Date: Mon, 6 Jan 2003 12:59:45 +0530

Hi
In RFC2507( page : 22 ), it is given that compressed non-TCP headers
contains one BYTE optional 'DATA' field.
If any one knows , please tell me what is the main purpose of this one Byte
DATA field.
Thanks in advance.
With Kind Regards,
Ramana.

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************

---

From: Stephen Casner <[email-masked]>
Date: Mon, 6 Jan 2003 00:52:58 -0800 (PST)

> If any one knows , please tell me what is the main purpose of this one Byte

See Section 3.3.1 of RFC 2508.

                                                        -- Steve

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 06 Jan 2003 16:00:49 +0100

--On mandag, januar 06, 2003 02:01:27 -0500 Doug <[email-masked]> 
wrote:

> 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

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 10:15:07 -0500

> I fail to see how this throws out any babies. perhaps I am missing

What you're missing is that I can configure *MY* server so it will only:

1) Accept mail *TO* a local recipient.
2) Allow relaying of mail to a *remote* recipient after doing some sort of
authentication that it's one of my users.

And in fact, the last I heard, open relays were only 1% or so of the total
mailservers out there - so the above is already the usual state of affairs.

Note there's no requirement that *inbound* mail be authenticated, which is
the basic source of the spam problem.  Your mail server will probably
accept mail for your userid from anyplace without authentication.

Now let's say you *do* start requiring authentication for inbound mail.
Let's consider this piece of mail, which is being sent to both you and
the IETF list...

1) What userid/password does the IETF mailserver use to authenticate
itself to your mail server?  Remember in your answer to note that forcing
users to manually update a whitelist of mailing lists they are on is
a helpdesk nightmare, and hard to scale - our main mailserver has some
80K mailboxes/aliases on it, and I'm on a lot of lists.  However, just
because *I* am on a list hosted at some site doesn't mean that any other
users on my mail server wants to accept mail from that site.  However,
even if you decide *that* cost is toleralble, there's still:

2) What userid/password does my laptop use to authenticate itself to your
mail server?  And note that you can't just say "my laptop has to send it to
my mail server" - because then you need to get the userid/password pair to
my mail server.  Remember that your answer has to scale to 40 million .coms,
and that it has to work on a sender/recipient pair basis (otherwise, it's
like inviting a vampyre in - if they can get one person at your server to
OK the mail, then they can commence spamming all your users).  Note that
answers like the "reply to this message to prove you're not a spammer"
schemes are *NOT* a long-term solution - if any of those packages becomes
widespread enough to actually impact the spam problem, the spammers will
have a little Perl program scanning the bounces and canning the "yes I'm
not a spammer" responses.

-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech