spf-discuss
[Top] [All Lists]

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

2005-11-24 11:47:51

----- Original Message -----
From: "j o a r" <joar(_at_)joar(_dot_)com>


On 24 nov 2005, at 00.15, Hector Santos wrote:

   The HELO receiver MAY verify that the HELO parameter really
   corresponds to the IP address of the sender.  However, the
   receiver MUST NOT refuse to accept a message, even if the
   sender's HELO command fails verification.

How more explicit can it get?  it says "MUST NOT"  not "SHOULD NOT"

But this is for HELO, not EHLO - which was what you discussed
previously. I'm no expert, but are these two not possibly subject
to different rules?

Joar, you raised a good question.

I think that I would be correct in saying the general consensus with the
IETF community, which include SMTP vendors, that it doesn't matter if its
HELO or EHLO.

Technically, RFC 821 is the standard. HELO is a REQUIREMENT.  EHLO, govern
by RFC 2821, is optional.  RFC 1123 is pretty much the bible for all hosting
applications.

What that means is that a EHLO aware system MUST be able to support HELO as
well and that a non-EHLO aware client need only HELO.

Remember this:

    RFC 821 (STD 10) -  August 1982  - 23 years old
    RFC 1123         -  October 1989 - 16 years old
    RFC 2821         -  April 2001   -  4 years old

You got MILLIONS of systems still based on 20+ years of operations. 2821 is
only 4 years old.

That said, I am of the school of thought, that anything that raises the bar
may be held to a higher scrutiny.  So if someone uses EHLO, that's that mean
its a modern software and should be smarter?  Should know better?

In either case, the problem is not always the fault of the software itself
old or new.

The issue is how IP addresses are resolved in a network environment. It is
different for different OSs and flavor.  Is DNS used? HOSTS files? Some
other Directory service concept?

Much of it has to do with the Administrator setup.  Of source, its all about
software. The software can do a better job, of course, but there was no
incentive to do so.

Today it is.

So if you ask me, one of many SMTP vendors, is it possible to have different
rules for EHLO vs. HELO?

I will answer yes, but it will depend on some other "higher level of
intelligence" assertions.

SPF is a good assertion, some clue or anything else that feeds the RECEIVER
information that says:

    "hmmm, this guy is no old dummy I have to put up with"

Anything that helps the receiver with Inconsistency information, then you
have new powers.

Example:

    HELO hdev1
    MAIL FROM: <emailaddress.com> SUBMITTER=joar.com

SUBMITTER is an proposed MAIL FROM modifier protocol to help SPF and
SENDERID.

What is wrong here?

1) You have a MAIL FROM modifier SUBMITTER, which could only
   be used under an Extended SMTP session. It should of used
   EHLO instead of HELO.

   Instant reject consideration

2) Using SUBMITTER makes the client HIGHLY SMART, it is related
   to SPF operations.  This should give you power to assert
   the FQDN domain for HELO/EHLO.

Get the idea?

So anything that the receiver can see in the form of inconsistency with
other "higher intelligence" concept or parameters, in my opinion, gives SMTP
developers more power to program as OPTIONS for the administrator to use.

Of course, this can get complex, so the good software would make this
available as rules the administrator can prepare himself.  Each system has
its own ideas of doing this, MFILTERS, ACL, HOOKS, SHIMS and even mail
filtering components like Sieve and other similar agents, etc.

But as a bare bones pure SMTP client/server transaction?

Unfortunately, no, rejection on a HELO A mismatch would be considered a bad
practice in the general environment.

--
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