[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Asrg] whitelisting server and not users
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, william@elan.net [SMTP:william@elan.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@Space.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)
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
> > > Asrg@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/asrg
> > _______________________________________________
> > Asrg mailing list
> > Asrg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg