Subject: [Asrg] whitelisting server and not users

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

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

---

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

William,

Thanks.  I agree that the proposal presents a number of difficulties and 
technical challenges, specifically with breaking legacy systems (maillists) I 
am not so sure that these can not be overcome with some a additional analysis 
(e.g. additional research into how many vectors for verification are available 
to the receiving MTA: helo/ehlo, mail from, 822-header information, forward 
chaining) that may use a combination of approaches. Still, an interesting 
approach IMHO.  Thanks for the pointers.  BTW, was a consensus check done on 
that approach, just curious (since you seem to be the link master :-)

-e

On Wednesday, April 02, 2003 10:35 AM, [email-masked] [SMTP:[email-masked]] 
wrote:
> 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
>
> On Wed, 2 Apr 2003, Eric D. Williams wrote:
>
> > 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:

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 13:00:03 -0500

Concerning the discussion I am reading it appears to me the following issues 
were 'out of scope' for the solution:

+ DNS problems are not the object of resolution, albeit the system depends on 
DNS the affect of the DNS problems discussed are not specific to the proposal 
but are general.

I just wanted to add my $.02 to that discussion thread.  It also appears that 
the discussion did not seek a consensus deprecating a 'sender authorization' 
methodology, so that to me means a scheme using such a method that can correct 
these issues could still be considered viable.  I think that the legacy system 
(forwards, maillists, etc.) issues can be overcome, they are not trivial BUT 
neither are they insurmountable.

That's my $.02

-e

proposals

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 18:49:03 -0500

I here you there.  I noticed the difference, but wanted to be true to the 
analysis offered.  Indeed, I actually think the query on connection requests is 
a more viable method, but it does not preclude other types of 'checks'.

-e

proposals
> 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: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 18:53:36 -0500

As any such methodology would seem easy to implement (but remember there is a 
scoping paradox if other measures are not taken (e.g. SMTP AUTH), that would 
tend to serve to elicit deployment to derive its benefits.  Since such a 
proposed method would not break existing deployments it would not appear to 
deter experimentation either.

-e

On Wednesday, April 02, 2003 2:25 PM, Steven F Siirila [SMTP:[email-masked]] 
wrote:
> On Wed, Apr 02, 2003 at 09:05:35PM +0200, Markus Stumpf wrote:
> > On Wed, Apr 02, 2003 at 07:34:34AM -0800, [email-masked] wrote:
> > 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]"
>
> 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

---

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

I agree.

On Wednesday, April 02, 2003 4:22 PM, Daniel Feenberg [SMTP:[email-masked]] 
wrote:
8<...>8
>... Without that enforcement tool, there isn't any real
> incentive in the system.
>
>
>

---

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 19:10:30 -0500

On Wednesday, April 02, 2003 4:07 PM, Kee Hinckley [SMTP:[email-masked]] 
wrote:
> At 3:00 PM -0600 4/2/03, Steven F Siirila wrote:
> >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.
>
> 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.  :-)

I don't think it 'breaks' any systems, it just points to another consideration. 
 If when developing any of these very good ideas we keep getting caught on 'it 
breaks something' and not trying to come at the 'problem' from a different 
perspective, in this case how to get rDNS 'widely deployed and used'.  Then in 
a lot of cases (IMHO) we will not make much progress with out breakthroughs. 
 We should (for the time being I think) try to be a little more experimental 
with some of these approaches, this is a 'researchy' - I know I keep saying 
that - group.  We need to think deeply AND broadly, bringing all of the various 
disciplines and techniques we know to bear.

-e

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 3 Apr 2003 11:04:42 -0500

If the goal is to develop/discover/research methods to reduce spam then reverse 
mapping of domain name system RR's is a valid approach.  I don't think we need 
to specify anything per se to offer that as a valid methodology (whether it's 
adopted may well depend on our recommendation that it is a viable method).  One 
of the goals is "must not depend on universal deployment to be effective" from 
the list that Paul Judge forwarded (via a link):

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

I think the offered method fits that criteria, whether it provides an incentive 
may depend on whether we agree that it can be an effective enhancement to 
system operation within the context in which it is being proposed I don't think 
that any proposal HAS to offer an inherent incentive (based on RFC's or 
whatever) but, that is a sub-goal on the list.  I think a better goal would be 
'should provide an incentive for further deployment, for those doing the 
deployment' because experimentation is the first step towards acceptance, we 
can not skip that step if we are working towards an effectively deployed 
solution.

-e

On Thursday, April 03, 2003 7:49 AM, Markus Stumpf 
[SMTP:[email-masked]] wrote:
> On Wed, Apr 02, 2003 at 06:16:06PM -0700, Vernon Schryver wrote:
> > 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.
>
> 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".
>
> > > 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.
>
> 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.
>
> > > 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.
> >
> > That's a tad theoretical, since it depends not only on good reverse
> > DNS but your new TXT RR.
>
> 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".
>
> > Maybe so, but you missed the most memorable reason I've been given.
> > That was "not having good reverse DNS names reduces spam."
>
> No.
>
> 	\Maex
>
> --

---

From: "Eric D. Williams" <[email-masked]>
Date: Thu, 3 Apr 2003 18:29:52 -0500

On Thursday, April 03, 2003 5:05 PM, Kee Hinckley [SMTP:[email-masked]] 
wrote:
8<...>8
> 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.

Excellent point.  But, letting someone run an SMTP server that originates from 
the ISP's address space is the issue, so it could be worked with given proper 
accountability for delegation.  If one of the other checks is performed at the 
first reciever site (e.g. domain chk) in addition to IP address checks, that 
could also make it acceptable and could introduce a different type of provider 
of authorized relay services (unintended consequence?).

-e