[Questioning One's Self] RE: The vulcan mind melt

Questioning one's self is the first step to knowledge.  - (I forgot who said
that, it was said in a Star Trek game called "A Final Unity.")

So let's see my assumptions that I need to question.

> - What exactly do we do with HELO host names, why do we do it,
>   and what do we gain by doing so in context of the subject of
>   Anti-Spam.

I originally wanted to ignore them completely.  Certain constraints in the
defined SMTP Protocol require, however, that another source be considered
for information besides the envelope domain and the source IP.  HELO is the
only other source of information we can use this early in a SMTP
conversation.

I wanted to deal with forgeries "early" to save on SMTP bandwidth.  I'm
discovering this is coming at the cost of DNS bandwidth.  I've never
actually measured the impact yet, so I'm acting on a feeling I've yet to
question and will do so in the coming days.

Assuming I want to deal with forgeries this early on, I need HELO as a check
for null reverse path messages (a constraint of RFC 2821) to make sure I
don't see a bunch of spam with null reverse paths as I've seen really early
in my sysadmin days (1997).

Also, to answer a very common criticism that MAIL FROM only checking kills
certain kinds of forwarding services, and also runs afoul of RFC 2821 7.1, I
want now to use HELO as a secondary check in case the MAIL FROM check is
rejected (not failed, rejected).  This may let more forgeries through.  But
I am content in that a site taking the trouble to identify their machine
through all this, is going to choose to act on any complaints.  And if not,
well, I could block based on host name.

I need to question these assumptions I've made: that a site setting up a
bunch of records is actually going to secure their machine so it isn't
easily abused, or that they're not a spammer trying to play by the new
rules.  And that looking for forgeries this early in the process is really
worth the DNS bandwidth I'm using up.  Or if not DNS, whatever protocol is
used.

> - Will we do the "simple method", where we just have a simple
>   IP-to-DNS mapping and hope that every company and every private
>   network fits into that scheme and every MTA is able to process
>   it with rule bases or
>
>   will we do the "meta-record" (as in RMX and SPF) containing a set
>   of authorization records of different types, which would require
>   to extend the capabilities of MTAs.

My assumptions here, are that MTA vendors and sites are lazy by defenition
and don't want to change things very much, that the "simple method" uses
less DNS bandwidth, supports TTL values set by the host so receivers could
cache it, supporting an assumption above and reducing the time it takes to
do a query.

Based on those assumptions I decided an IP query was best.  I need to test
those assumptions too.

> - If we do so, do we stick to DNS, or should we go the slow and
>   "expensive" in network traffic, but more modern way and fetch
>   an XML description from any URL?

My assumption here was that DNS was already being (ab)used for spam source
checking, and that switching one DNS lookup type for another would not incur
any additional DNS bandwidth cost.  I need to know just how many sites using
DNSBLs would actually turn off their DNSBLs in favour of this, or how many
*new* sites would use this which would increase the DNS overhead.

It has been assumed that DNS is in need of an overhaul, and cannot handle
the strain of yet another service heaped on to it.  Who can test this
assumption?

Any lookup over a different protocol may wind up using DNS anyway, to know
where to retrieve records.  I assumed that no one's going to want to look up
stuff on servers only by IP address, especially IPv6 addresses.  This might
be an assumption but I'm not sure I need to test this one.  Any URL based
lookup is guaranteed to use DNS.

> - Or should we go even further and download some program to be run
>   in a closed environment (like a java applet) which works as a
>   black box and decides whether to accept it or not?

Major assumption: open source folks don't like black boxes.  Does this even
need testing?

And how often do you download the black box, where you use bandwidth too?
How long before this becomes like modern anti-virus software, which could
only catch new forgeries after the fact?  Personal experience, not an
assumption, says catching stuff before the fact is more productive and saves
on bandwidth.  Why else would I recommend to a client that they don't run
conventional anti-virus software?

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email protected]>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>