spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: SPF adoption statistics

2005-11-22 15:07:14
----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>

Huh?  I am not talking about PTR records.  I don't want mail servers
to use PTR records.  PTR records are unreliable, and small domain
owners can't  fix it - no matter how competent they are.

Its not a matter of what you want. Its how the legacy market is.

The client should be a proper MTA, and should be configured with a
correct FQDN.

Should is one thing.  Legacy operations is another.

Manually, if automatic guesses fail.  If there is an
MX or A record for an MTA to receive mail, then that MTA certainly
has a correct HELO name to use.  If the shop has separate SMTP out
servers,
the *ability* to create MX records implies the ability to create
A records for their outgoing servers.

In the perfect world, yes.

On the other hand, a small domain (less than class C) does *not* have the
ability to create PTR records.  Only their ISP does!

I think you might have ignored the point about OS Socket Layer function vs
DNS query:

    - gethostbyaddr() vs direct DNS PTR query

This is extremely important in this discussion.  You can't ignore it because
it is a major reason why even the BEST of all good intentions sender may
have a configuration issue.

It really has nothing to do with the MUA vs ISP MTA. The MUA is just a term
that implies it has a built-in MTA with a mail reader/writer conponent. But
it to has the same issues.

Here is a perfect example of using Outlook from my home office machine a few
hours ago:

  SMTP log started at Tue, 22 Nov 2005  00:46:53
  Connection Time: 20051122 00:46:53  cid: 0000BE56
  Client IP: 72.144.150.205 (unknown)
  00:46:53 S: 220 winserver.com Wildcat! ESMTP Server v6.1.451.6 ready
  00:46:53 C: EHLO hdev1
  00:46:53 S: 250-winserver.com, Pleased to meet you.

Outlook used the socket call gethostbyaddr() which will return the netbios
computer name "hdev1" for my home office machine.

If Outlook and other MTA components was aware of the CURRENT NEEDS to be
correct, then it would of done a DNS PTR lookup and got:

    adsl-144-150-205.mia.bellsouth.net

which would of been proper and the SMTP Server would be then be able to do a
proper A record match.

Again, the SAME problem can exist with all MTA machines.  If it uses
gethostbyaddr(), it can run into this problem.  That's part of the legacy.
Understand?

I don't have any problems with my three strikes rule: "you must have
at least one (valid version) of the three 2821 IDs I check: PTR, HELO,
MFROM (SPF)".

Thats cool and I agree.

But again, this is based on a presumption of higher level of intelligence on
the part of the client.  You don't have a good fix on legacy operatons.
There are still millions of GOOD systems that still use legacy operations
and don't use SPF - thus the SPAM problem and the exploitaton of bad actors
on a legacy email framework.

Your rules are ok, but in my opinion, the HELO A/match requirement is still
too strong - TODAY - for me.  I think you know that I am a stickler for
strong SMTP compliance - but only where its practically possible.  I write
and market SMTP software and it has to work against all systems.

When to comes to anti-spam stuff, for me, the difference between:

   HELO
   MAIL FROM

is that MAIL FROM is a FUNDAMENTAL requirement for proper operations today.
It is needed for possible bounces.

HELO is not a fundamental requirement for proper SMTP operations today.

So to me, you can do strong testing on MAIL FROM, and for me, CBV is part of
that checking.  But for me, little can be done with HELO.  I think you get a
higher false positive with it without even testing if that is true.  Just
look at the Outlook example.

But as I said before, these days, there is a growing direct correlation of a
bad HELO vs. bad actor.

Anyway, good or bad, my only point is HOW it can come about with no
ill-intentions - just legacy setup and operations.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com