ietf-asrg
[Top] [All Lists]

RE: [Asrg] whitelisting server and not users

2003-04-02 11:02:21
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

On Wednesday, April 02, 2003 10:35 AM, william(_at_)elan(_dot_)net 
[SMTP:william(_at_)elan(_dot_)net] 
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:maex-lists-spam-ietf-asrg(_at_)Space(_dot_)Net] 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) 323  
56-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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg