Re: A new SMTP "3821" [Re: FTC stuff...........]

"Chris Haynes" wrote to David WoodHouse:

> Please understand, I'm not inviting a reprise of arguments which have
taken
> place elsewhere, I'm trying to lift the level of debate to one of process
> related to the 'definition' of SMTP.
>
> ....

Good analyze and examples of the different viewpoints.  You emphasized on
the classical forwarding/routing problem currently experienced by the LMAP
solutions and summarized with a (rthoritical?) question:

> How, and from where, would one get an 'authoritative' ruling about the
> conformance or non-conformance of  forwarding (using the origin's MAIL
FROM with
> a new RCPT TO) to the extant SMTP architecture?

The more fundamental question as I see it is:

Does the process allow for "information" to be available so that a downlink
can understand what has occurred at a transition point?   If so, when and
where?   If no, when and/or where it is exposed?

On specifics,  The SUBMITTER proposal lends itself to this forwarding
problem.  But it only works in compliant downlinks.  The DMP (LMAP) also
lends itself using the secondary HELO/EHLO LMAP check when the 2821.MAILFROM
LMAP check fails.  But it presumes a working DNS secured/exposed HELO/EHLO
client domain name.

The question I ask (rhetorical) is what "common ground" SMTP level 'trace"
information can be done to better transition points.

I believe the Received: header lines are our "best"  hopes.  However, this
requires a PAYLOAD transaction.

In any case,  no matter how I look at the solutions, it always comes down
for a downlink to have more information at the transaction SMTP level.

A new ESMTP HEAD command keeps common to mind.  It solves many of the issues
we face, it will help the IIM/YDK and SENDER-ID proposals.  It will help
resolve the "transition points" forwarding problem.   It will help new ideas
such as TOPIC identification concepts.  I believe very strongly, this would
be a great enhancement to the protocol.

The expert debaters can argue the merits of how compatibility is address.
My simple input here is that ESMTP advertisement indicates a level of
scrutiny/security based on compliance.  For example, in response to EHLO, it
can have:

HEAD       - Optional
HEAD-R    - Required
HEAD-S    - Optional  for SPF systems
HEAD-A    - Required for ANONYMOUS senders

etc, don't know, this side of it needs a good analysis.  But it is on par
with the idea of new systems enforcing new requirements, and new systems
also offering some level of backward compatibility.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office