ietf-mxcomp
[Top] [All Lists]

Re: Semantics and Syntax

2004-05-03 10:03:08

On Mon, 2004-05-03 at 08:06, wayne wrote:
From the MARID charter:

In <938B9C24-858D-11D8-A7E0-000A95B3BA44(_at_)hxr(_dot_)us> Andrew Newton 
<andy(_at_)hxr(_dot_)us> writes:

                                       [....] the first task of the
      working group will be to establish which of these identities
      should be associated with MTA authorization. Once this
      decision has been reached, it will limit the scope of further
      activity in this working group,

It is my understanding that this first task has been finished.  The
co-chairs feel that there is a rough consensus that we should work on
the RFC2821 data first, then the RFC2822 data.


      May 04 Interim Meeting. Focus on required semantics for
      MTA authorization; syntax discussions


Ok, so now we are supposed to be discussing semantics and syntax.


The semantics and syntax range from the very minimalist approaches of
FSV and DMP, to the most complex of the lot: SPF.

While SPF isn't an exact superset of the LMAP and C-ID proposals, it
is pretty close.

Having been involved with the SPF project for a long time, I doubt
that it comes as any surprise that I think the SPF proposal is a
reasonable choice for both the semantics and the syntax.
<snip>

There are a few items missing from the SPF proposal that should be
included such as statements regarding use of third-party relay or
forwarding from the domain to enable rejections prior to envelope
rewriting practices.  The use of redirection and inclusion could lead to
a problem.  Expect domains that will not resolve within a reasonable
time frame.  There are no limits on this however.  For use where only
2821 validation is expected, there should be a requirement only a single
query is required.

Any new standard proposed will not conflict with records already in
place, but it seems likely, as the details are reviewed, the SPF
proposal will undergo signification change to accommodate a safer
progressive approach.  As details are resolved, features needed to
support 2822 validation may be added.  I would not want a standard that
obscures the domain with administrative control over the SMTP server
making the connection.  If there is a problem determined with the type
of messages being transported such as messages with header forgeries,
the chain of responsibility must be clear.

The momentum started by the SPF is important, but it would be beneficial
not to impose constraints that will impair proposals that wish to have a
simpler minimum set before their use becomes effective.

-Doug


<Prev in Thread] Current Thread [Next in Thread>