Subject: RE: [Asrg] whitelisting server and not users

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 12:09:21 -0500

The very first message to this list suggested such a scheme.

https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00001.html

I have heard it referred to in subsequent threads, and among other proposals 
and analysis I have read, it does seem to be a promising if it meets the 
ultimately developed requirements.  The proposal for an 'RMX' RR was presented 
as an interim or incremental solution to the issue you refer to.  I wonder if 
the author of the proposal is still participating, Hadmut you there?

-e

On Wednesday, April 02, 2003 11:27 AM, Markus Stumpf 
[SMTP:[email-masked]] wrote:
> I don't know if this has been discussed here before. All the whitelisting
> discussion I have seen so far was verifying the existance of users.
>
> From what I see from my logs by far the most percentage of spam is from
> hosts that are either on dynamic addresses or e.g. the unsecured
> workstation of someone in a company that all get abused, either by
> having a "not known about" mailserver or proxy server or ...
>
> IMHO a fast and easy to implement strategy would be not to accept
> SMTP connections from hosts that haven't clearly marked themselves
> "I am a outgoing MAIL Server".
> Such marking can be easily done in DNS in the in-addr.arpa zone either
> by e.g. setting a TXT record (preferable with a abuse contact) or a MX
> record (either a MX record at all or one with a special prio).
>
> This is better than any DNSBL list, because most reverse zones are
> maintained at the ISPs and they should probably know what they are
> doing.
>
> This setup is easy, cheap, easily deployable for the senders and the
> recipients (existing DNSBL modules need only minor tweaking). Transition
> is easy, also, one could use the information to add RFC 2822 Headers
> on the existance/absence of those records for use with e.g. spamassasin.
> Classification is easy, also: you want spam you don't look at these
> records, you don't want spam you do.
>
> I know this is not a solution to eliminate spam in total, but it might be
> one to eliminate large amounts of it.
> Also if an ISP adds one of those records one could set up legal mumbo
> jumbo and the customer can't say "it was a newly setup system and we
> didn't know it has a mailserver running".
>
> 	\Maex
>
> --
> SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
> Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
> "The security, stability and reliability of a computer system is reciprocally
>  proportional to the amount of vacuity between the ears of the admin"
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Wed, 2 Apr 2003 07:34:34 -0800 (PST)

It does not because of multiple problems like breaking mailing lists and 
forwarders and roaming users, only looking for enevelope from (while most 
users see header from and it can still be forged, etc). Here are
links about this (and similar) proposal that I gathered so far:

DNS Based source domain verifications 
Proposals:
 RMX proposal by Hadmut Danisch- 
  http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-00.txt 
 Designated Sender proposal by G. Fecyk - 
  http://www.pan-am.ca/draft-ietf-asrg-dsprotocol-00.txt
 Repudiating MAIL FROM by Paul Vixie
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00627.html 
 Domain Specific DNS blacklists:
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00686.html 
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00742.html 
Objections, Discussions: 
 DNS Security Problems: 
  http://www.securityfocus.com/guest/17905 
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00665.html 
 Incompatibilities with current mail system (maillist problems, etc):
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00025.html  
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00541.html
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00700.html 
  https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg00762.html

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 2 Apr 2003 21:05:35 +0200

> links about this (and similar) proposal that I gathered so far:

Maybe I didn't make it clear in my first post in this thread, but sorry,
I can't
a) see the problems described above
b) see how the proposals in the list you provided do relate to my proposal

What I am proposing is:
    mail.space.net	IN	A	195.30.0.8
we will like other mailservers to accept mail from mail.space.net and
indicate that by adding
    8.0.30.195.in-addr.arpa	IN	TXT	"[email-masked]"

If we contact another mailserver this mailserver would
- test if there is a TXT record for 8.0.30.195.in-addr.arpa
   i)  if there is -> fine
   ii) if there isn't
       1) accept the email anyway but flag the email as "no RR TXT"
       2) wait for a SMTP AUTH
	  a) if there is, it's a valid (roaming) user, accept,
	     probably add some authorisation information. (We currently
	     add "SMTP AUTH verified <[email-masked]>" which allows us
	     to track abusers very easily.
	  b) if there isn't, reject the eMail with an appropriate error
	     to the RCPT TO command (either permanent or temporary in
	     case of experienced DNS problems (TIMEOUT, SERVFAIL)

Please note that this does in no way any verification of EMAIL ADDRESSES.
It just checks, if the maintainer of the in-addr.arpa zone acknowledges
that the IP address the connection comes from is supposed to be a mailserver.

Using TXT records (e.g. MX will do also) has the big advantage that one
doesn't need another RFC to define a new type of record type or other
implementation work (add the new record type to DNS servers, to zone
management tools, ...). Deployment could be *very* fast at minimal cost.

	\Maex

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 2 Apr 2003 21:17:56 +0200

> management tools, ...). Deployment could be *very* fast at minimal cost.

Forgot about that:
existing DNSBL modules can be used. The BASE of the DNSBL would be
in-addr.arpa and the meaning of the existance of a TXT record would have
to be inverted.

This approach would also fix a lot of other DNS problems :-)) because
everyone would start to take a lot of care about their RR zones (which
they currently do not, as Bill Mannings statistics show very clearly).

	\Maex

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 2 Apr 2003 14:24:18 -0500 (EST)

> the author of the proposal is still participating, Hadmut you there?

To be fair to Markus, while there is a hazy relationship between his 
scheme and Hadmut's, they are fundamentally different because Hadmut
want to authorize the envelope from address and Markus the connection
IP. I don't believe many of the objections to validating the envelope 
from address (mailing lists, forwarding, etc) apply to validating the
IP connection address. 

Markus's scheme gives to the DNS owner the authority to authorize or
disallow mail from a server whose pimary host name is in its delegated
space. This seems perfectly reasonable to me, especially since it is
optional for receipients to observe the authorization or not, and 
would require no new protocols or even much coordination. 

People who wanted to send mail, but whose machines were registered
in domains whose owners didn't want them to would complain. I 
wouldn't think that was decisive, though. They could forward 
through a valid machine, or take their chances with filters.

---

From: Steven F Siirila <[email-masked]>
Date: Wed, 2 Apr 2003 13:25:18 -0600

>     8.0.30.195.in-addr.arpa	IN	TXT	"[email-masked]"

Personally, I'd go a step further.  Associate an MTA connection with a
domain name.  In other words, require rDNS and use the host name returned
to look up a TXT record.  Using your above example, you'd have this:

mail.space.net.			IN	A	195.30.0.8
				IN	TXT	"[email-masked]"
8.0.30.195.in-addr.arpa.	IN	PTR	mail.space.net.

For an MTA to be considered "valid" it must have both valid rDNS and a TXT RR.

My only concern is how to get this in widespread use, which would be required
before any severe penalty could be imposed on those that don't employ it.
-- 

Steven F. Siirila			Office: Lind Hall, Room 130B
Internet Services			E-mail: [email-masked]
Office of Information Technology	Voice: (612) 626-0244
University of Minnesota
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 2 Apr 2003 21:54:56 +0200

> before any severe penalty could be imposed on those that don't employ it.

This could be creeping and it's up to the maintainer of the receiving
server. At the beginning it could make its way to filters that rate it
positive if the records exist.
As it gets deployed more it could be rated negative if the records don't
exist.
And it would be very easy to do deployment statistics and keep track
of the progress ...

	\Maex

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 2 Apr 2003 15:48:04 -0500

>to look up a TXT record.  Using your above example, you'd have this:

Yes.  But that particular step breaks 30% of the email out there (at 
least that's the number I've seen for email senders without proper 
reverse DNS).  It may be high--but certainly no major ISP that has 
attempted to block on rDNS has kept the block--and they weren't even 
authenticating--just seeing if it was there.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Steven F Siirila <[email-masked]>
Date: Wed, 2 Apr 2003 15:00:08 -0600

> authenticating--just seeing if it was there.

It "breaks" it no more than adding just the TXT record itself in that both must
be configured by the DNS administrator in order to pass the "good MTA" test.

--

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 2 Apr 2003 16:06:32 -0500

>be configured by the DNS administrator in order to pass the "good MTA" test.

Sorry, I misread the proposal.  I thought it was finding the 
authenticating domain by looking at envelope.  Not from reverse 
looking up the IP address.  In that case you're right--they both 
break too many systems.  :-)

Too many ISPs don't provide reverse DNS to their customers, but do 
allow mail servers.  And many of those that do provide reverse DNS, 
reverse it to their own domain, not the sender's domain.

envelope -> domain -> lookup ip at domain

I think can work.  Straight reverse IP lookups are harder.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Steven F Siirila <[email-masked]>
Date: Wed, 2 Apr 2003 15:10:58 -0600

> reverse it to their own domain, not the sender's domain.

Not a problem here since we also look up the EHLO name.  If that resolves
to the caller's IP address, it counts as good as a PTR record in our book.

--

---

From: Daniel Feenberg <[email-masked]>
Date: Wed, 2 Apr 2003 16:21:37 -0500 (EST)

> to the caller's IP address, it counts as good as a PTR record in our book.

But doesn't this open the door for the spammer to just get a throwaway
domain name and authorize his own spam? The advantage of using the RDNS
of the connecting host is that it is fixed by the ISP, who can
be held responsible by RBLs. Since there are a finite number of IP address
blocks, the ISP isn't going to want to repeatedly issue new IP addresses
to the spammer. Without that enforcement tool, there isn't any real
incentive in the system.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 2 Apr 2003 23:28:14 +0200

> reverse it to their own domain, not the sender's domain.

So what? What do you think is a minor problem:
  - adding a DNS record to the reverse zone
  - installing a new system for user administration and lookups

> envelope -> domain -> lookup ip at domain

No, no, no ;-)
In my proposal I want to get rid of all the "I don't want you to be a
mailserver" hosts, i.e.
- workstations that are worm/virus infected
- workstations that are misconfigured and run
  - proxies that nobody knows about
  - SMTP servers that nobody knows about
- hacked DSL users
- thousands of hosts in universities that are not blocked by campus firewalls
- ...

I don't want to look at domain names or email addresses, I just want to
look at IP addresses, like in DNSBLs, but it is a DNSWL and the people
that are in charge of maintaining the reverse zone can whitelist hosts.

I don't accept a "they don't maintain RR zones" as an argument.
Everybody maintains RR zones the one or the other way. Now we could
force them to do it the correct way.

	\Maex

---

From: Steven F Siirila <[email-masked]>
Date: Wed, 2 Apr 2003 15:26:15 -0600

> to the spammer. Without that enforcement tool, there isn't any real

You are quite correct.  I realized this after I sent the mail.
It works well for open relays since the spammer cannot control the EHLO name.
However, open proxies and such are another story.

--

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 2 Apr 2003 16:35:15 -0500

>to the caller's IP address, it counts as good as a PTR record in our book.

Careful there.  I used to do that, but it wasn't sufficient.  Some 
spammers create DNS records that map to the machine they are 
currently spamming through.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 2 Apr 2003 14:54:50 -0700 (MST)

> From: Markus Stumpf <[email-masked]>

> ...

Why whould they start to care about their RR zones?  There are already
far more SMTP servers that require various matching rules among the
HELO value, the reverse DNS name of the STMP client, and the Mail From
client than you could hope to have check for TXT RRs for a year or
two.  However, those many SMTP checking servers are a small minority
because so many outfits have no or ridiculous reverse reverse DNS,
that no one who cares about false positives can use it.

As far as I can see, the only way to get such a rule in place is to
convince a very large SMTP client to impose it.  For example, AOL's
sudden requirement that the envelope Mail_From domain name resolve
made it possible for that rule to be the default.

This sort of transition problem differs from the problem of convincing
80% of the Internet to do something new like use certs or switch to
something other than SMTP.  When AOL started requiring valid sender domain
names, more than 80% of legitimate mail already met the rule.  AOL just
pushed most (but not all) of the small minority to get their acts together.

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

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 3 Apr 2003 00:06:20 +0200

On Wed, Apr 02, 2003 at 02:54:50PM -0700, Vernon Schryver wrote:
> Why whould they start to care about their RR zones?

There are six reasons:
1) it helps them reduce spam
   a) it is one of the easiest systems they can get
   b) it is one of the cheapest systems they can get
2) there is a RFC that says they should
3) It will reduce the costs of the abuse department, as 5000 braindead
   admins with misconfigured workstations can't cause too much trouble
   anymore and the complaints will become reports.
4) there is now a reason to care

The arguments of the no RR fraction have always been "we don't do it
because it is of no use" and "besides that there is no RFC that says we
have to".
None of that will be true afterwards.

	\Maex

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 2 Apr 2003 18:16:06 -0700 (MST)

>    b) it is one of the cheapest systems they can get

Yes, but it only helps other people reduce spam.  Fixing your own
reverse zones does nothing for your own spam load, at least not
for the first few years.

> 2) there is a RFC that says they should

I doubt this is the right working group to produce an RFC that mandates
proper reverse zones.  This is the IRTF instead of the IETF.

Depending on how you read them, there are already RFCs that say
you should have good reverse zones, because they say how to do it.

>    anymore and the complaints will become reports.

That's a tad theoretical, since it depends not only on good reverse
DNS but your new TXT RR.

> 4) there is now a reason to care

As I said before, there have always been reasons to care.  In
ancient days, FTP and other servers required matching forward and
reverse names.  There are currently plenty of SMTP servers that
enforce reverse DNS matching.  Then there is simple good hygene.

> None of that will be true afterwards.

Maybe so, but you missed the most memorable reason I've been given.
That was "not having good reverse DNS names reduces spam."

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 3 Apr 2003 14:48:48 +0200

> reverse zones does nothing for your own spam load, at least not

Huh?
If there is a RFC that says "MUST" have and I don't accept emails from
servers that don't adopt I have a /lot/ less spam. And everyone
complaining I can send the URL of the RFC and say "adopt".

> proper reverse zones.  This is the IRTF instead of the IETF.

I'm starting to doubt that this is the right group to find a solution to
spam. Too many people have too many different (e.g. commercial) interests
to push "their" solution.

> Depending on how you read them, there are already RFCs that say

That's the problem. Exactly what I said: "it depends" and nobody every
said "MUST". This can be changed.

> That's a tad theoretical, since it depends not only on good reverse

No it isn't. If I have the TXT RR in DNS and I get a complaint I can
point to the URL of the RFC and say "adopt, but I will talk to our
customer about the problem".

> That was "not having good reverse DNS names reduces spam."

No.

	\Maex

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 3 Apr 2003 17:05:03 -0500

>1) it helps them reduce spam

No.  It helps *you* reduce spam.  It doesn't help them reduce spam at all.

But I agree, it might be worth it.

Of course there's a little dirty secret probably at work here.  A 
good number of those ISPs would probably love it that their users 
can't run mail servers.

But it's going to take a draconian decision from AOL or several other 
ISPs to make it happen.  So far the ISPs that have tried RR blocking 
have all backed off almost immediately.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 4 Apr 2003 00:37:09 +0200

> have all backed off almost immediately.

We have, also.
The problem is that there is no RFC which I can point at and say "we're
on the right side". We did/do some blocking based on HELO arguments
(blocking earthling.net is currently unbeatable) but RFC 2821 says
that the argument has to be either a valid host name or the ip address
but it also says one MUST NOT reject connections based on non-conformant
HELO arguments.
So if I reject they tell me that is it forbidden. If I tell them that
what they do is forbidden, also they say mine is worse.
And there is no lobby. If I could have presented a list of some 1000
SMTP servers with some known names that enforce proper RR DNS my
standing would have been much better and maybe it would be BCP now
(about three years later).

	\Maex

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 14 Apr 2003 20:55:54 +0200

On Wed, Apr 02, 2003 at 12:09:21PM -0500, Eric D. Williams wrote:

> I wonder if 

Yeah, I'm still alive on subscribed to the list, but was not
actually reading the list.

Sorry for beeing absent. After coming back from San Francisco
I was extremely busy with looking for a new job and a lawsuit
against the University of Karlsruhe. Since the ASRG mailing list
was producing high amounts of traffic, I was not able to follow
since coming back from SF. Since I was extremely disappointed about
the ASRG meeting, and somehow upset, I'd given the search for a 
job and the lawsuit a higher priority. 

I'm currently writing the second version of the RMX draft which will 
be submitted soon.

regards
Hadmut

---

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 14 Apr 2003 23:57:27 +0200

>   - installing a new system for user administration and lookups

I think the major problem in your proposal is to actually get people to
use it. 

On the receiver's side, I don't want to reject any legitimate mail. So I
cannot use it to reject mail until a very large percentage (say > 99%)
of all sites sending mail to my users are using your scheme to whitelist
their outbound MTAs. Because until then I cannot reliably distinguish
between "this is not a valid relay" and "the postmaster of this machine
has not yet heard about RFC xxxx". Therefore, nobody will use it to
block mail.

On the sender side, it is easy enough to implement, but until people
actually start blocking mail, there is no incentive to do it. 

So there is a vicious circle: Servers cannot implement it until the
clients do and the clients won't until the servers do.

But I think I have an idea how that can be broken. See below.

> - thousands of hosts in universities that are not blocked by campus firewalls

I think we can get rid of most of these with the RMX-like schemes, too:
Neither infected nor misconfigured workstations nor random hosts at
universities will have an RMX record pointing to them, so they cannot
send mail (except via their designated smarthost). That leaves proxies
and open relays. For these a spammer has to use his own domain and
operate a DNS server, which makes him traceable, easier to block, and
may also limit the number of proxies he can use (although the latter is
probably only short term until spammers learn to use specialized DNS
servers).

Unlike your WL scheme, the RMX schemes can be implemented gradually and
both senders and receivers have an advantage of doing it:

As a receiver, I won't get false positives, so there is no danger of my
own users lynching be because they didn't get an important mail. In the
beginning, it won't reject much spam, but as it doesn't cost much, even
the little it does is good.

As a sender, I helps me to repudiate spam with forged sender adresses.
"My official servers are listed in DNS, and that isn't one of them. I am
not responsible for that mail". If one of big mail providers starts
using that they can seriously cut into the spam with their addresses,
which is good for them (less mail to abuse, less bounces, better image)
- again, at first only a little, but as more receivers implement it, it
helps them more.

> that are in charge of maintaining the reverse zone can whitelist hosts.

What your scheme needs to be deployable is a way to mark an address
range as using whitelists. Lets say I control IP ranges 10.130.16/24
and 10.130.48/20, but not 10.130.32/20. There are three hosts which
can send outbound mail, 10.130.16.2, 10.130.50.18 and 10.130.50.112.

Then I can add 

*.16            IN  TXT   "no smtp"
2.16            IN  TXT   "smtp out"

*.48            IN  TXT   "no smtp"
*.49            IN  TXT   "no smtp"
[...]
*.63            IN  TXT   "no smtp"
18.50   	IN  TXT   "smtp out"
112.50          IN  TXT   "smtp out"

to the zone file of 130.10.in-addr.arpa, and an SMTP server trying to
validate a connection from a host would just do a lookup in
<rev.ip>.in-addr.arpa. TXT (as in your scheme). However, because of the
wildcard records he can have four different results:

TXT "no smtp" 	- this is definitely not an outbound SMTP relay
		  (reject the connection)
TXT "smtp out"	- this is an outbound SMTP relay
		  (accept the connection)
NXDOMAIN	- we don't know about whitelists.
		  (accept the connection)
SRVFAIL		- dns problem
		  (drop connection with a temporary failure)

Does that sound feasible?

	hp

-- 
   _  | Peter J. Holzer    | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR       | zu Fortran.
| |   | [email-masked]         |
__/   | http://www.hjp.at/ |    -- Alexander Bartolich in at.linux