Subject: Re: [Asrg] 'GIEIS' - The Fifth Response

From: "Mark McCarron" <[email-masked]>
Date: Thu, 03 Jul 2003 20:11:49 +0000

Thankyou for your comments.  My comments are in the body of the message 
below.  This post refers to the 'GIEIS' system cueently at version 0.002.  
An update to version 0.003 will be carried out in the next few days.  
'GIEIS' has an extensive list of systems to be added and they will appear as 
soon as the documentation can be written.

The 'GIEIS' system can be viewed here at:

http://homepage.ntlworld.com/giza.necropolis

Mark McCarron.

>From: Steven F Siirila <[email-masked]>
>To: Mark McCarron <[email-masked]>
>CC: Steve Siirila <[email-masked]>,    [email-masked]
>Subject: Re: [Asrg] 'GIEIS' - The Fifth Response
>Date: Thu, 3 Jul 2003 15:08:20 -0500
>
>On Thu, Jul 03, 2003 at 08:04:23PM +0000, Mark McCarron wrote:
> > >
> > >On Thu, Jul 03, 2003 at 07:05:56PM +0000, Mark McCarron wrote:
> > >>
> > >> >>    (1) In the short to medium term
> > >> >>
> > >> >>     Devise a method of reasonably reliably identifying bulk spam,
> > >> >>     UCE or UBE and levying a charge on the senders (via any of 
>their
> > >> >>     upstream carriers, financial pain having the properties that 
>it
> > >> >>     does) which approaches that of any other method of commercial
> > >> >>     or non-private bulk message delivery and most of the TECHNICAL
> > >> >>     NETWORKING problems associated with spam - which are almost
> > >> >>     entirely due intractable volumes of traffic - would rapidly
> > >> >>     disappear.
> > >> >>
> > >> >> Mark's Response:
> > >> >>
> > >> >> The problem with this suggestion is that spammers are difficult to
> > >> >> trace and even when traced there lacks the proper legal frameworks
> > >> >> to do much about it.
> > >> >
> > >> >
> > >> >Spammers are only difficult to trace because there has been, until
> > >> >recently, little incentive to trace them and no sanctions placed
> > >> >on any injection points (which certainly can do most of the
> > >> >necessary tracing if well configured) for failure to do so.
> > >>
> > >>
> > >> Mark's Response:
> > >>
> > >> No.  The Internet crosses many legal boundries across the planet.  
>With
> > >> anonymous connections such as those by proxy (SOCKS, HTTP, etc) and
> > >those
> > >> by extensive proxy chains, simply back-tracing a tranmission is a 
>legal
> > >> nightmare.  Imagine attempting to get server logs from 40 or 50
> > >different
> > >> countries and then not even being guarenteed that the culprit is 
>still
> > >> there at the end of it all.  'GIEIS' would eliminate the need for all 
>of
> > >> this.
> > >
> > >So would simply requiring reverse DNS as well as a record indicating
> > >whether
> > >or not an IP address has been designated as an MTA.  This would make 
>all of
> > >the open proxies, hacked desktops, and dynamic IP ranges unable to send
> > >mail
> > >directly to a site's MX server, forcing them to use an ISP's SMTP 
>gateway.
> > >What you would have left is legitimate MTAs (some of which may be open
> > >relays).
> > >This is essentially where we are headed at our site by putting these 
>sorts
> > >of
> > >things into place gradually.
> > >--
> >
> >
> > Marl's Response:
> >
> > I am afraid that would not work.  Spammers would just use lists of
> > resolvable domain names.  Also, some form of centralisation would be
> > required to maintain the list you describe.  Another problem would arise
> > from sending authorisation requests cleartext over the Internet, these
> > could be intercepted and responded to allowing spammers access.  This is
> > exactly what 'GIEIS' architecture eliminates completely.
>
>The centralization you refer to is easily accomplished via DNS records.
>"Authorization" is accomplished via simple DNS lookups much the same as
>we currently use DNSbl lists already today.
>--
>

Mark's Response:

I think you are missing the point that it can be very easily bypassed.  Its 
not secure like 'GIEIS'.

>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

_________________________________________________________________
Sign-up for a FREE BT Broadband connection today! 
http://www.msn.co.uk/specials/btbroadband

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

---

From: Steven F Siirila <[email-masked]>
Date: Thu, 3 Jul 2003 15:48:17 -0500

> I think you are missing the point that it can be very easily bypassed.  Its 

Bypassed?  Not unless you control the IP address in-addr.arpa delegation
records as well as the domain name delgation records which correspond to
the PTR records.  Like I said previously, it would eliminate the problem
we have today with open proxies, compromised workstations, and dialup
lines being used to spam since none of those would have the required DNS
records designating them as MTAs.  I realize, like a lot of proposals,
that there is an adoption period where such records which did not exist
would have to be treated as "don't know", but as more ISPs adopted this,
sites would eventually be able to block based on this record.  BTW, this
record could include a value containing the abuse email address to send
abuse reports to as well.  For example, a valid MTA on the internet would
have the following DNS RRs:

3.2.1.10.in-addr.arpa.		PTR	mail.mydomain.com.
mail.mydomain.com.		A	10.1.2.3
mail.mydomain.com.		TXT	"MTA:[email-masked]"

To indicate that all other IP addresses in this domain are NOT MTA's one
might have something like this:

*.mydomain.com.			TXT	"NOMTA"

I would love nothing more than to shut down all of the open proxies and
virus-compromised workstations out there...

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 03 Jul 2003 22:42:36 -0400

At 03:48 PM 7/3/2003 -0500, Steven F Siirila wrote:
>....
>...
>the PTR records.
>.....

Keep in mind the DNS-Sec standards exist and ICANN is even implementing 
some of them. Security of the Domain Name System is being addressed.

Yakov