Robert,
The whole purpose of the LMAP protocols is to help close the SMTP loophole -
AKA the massive exploitation of Anonymous Final Destination Transactions.
We don't need email auth proposals for routed transactions and/or
transactions which are authenticated/authorized or validated via traditional
means, namely, Allow IP Relay tables, ESMTP AUTH, POP B4 SMTP or SUBMIT
which is basically just an ESMTP AUTH enforcement protocol.
This is for one reason - maximizing backward compatibility.
In short, SPF or LMAP systems are not a "replacement" for BCP methods
traditionally in place for the past score of years.
With that said, I understand there is a "consideration" (opinions injected
into the discussion stream) to use the new proposals for MUA/MSA
authenticated sessions as well.
In my technical view, this goes against the backward compatibility aspect of
SMTP BCP and thus will have more problems being adopted if only from one
standpoint - the current SOFTWARE in place is designed around the black and
white SMTP BCP methods for authentication. It is not designed around "fuzzy
or grey" concepts. This is very important. You better have something
solid if we are going to be adding or replacing current MTA relay
authorization protocols.
PS: For over 1.5 years now, we have SPF implemented as part of a suite of
other anonymous sender verification methods lumped together as WCSAP
(Wildcat! Sender Authentication Protocols). WCSAP is only triggered for
anonymous transactions and only after the RCPT is determined per RFC 2821
recommendation:
RFC 2821 - 3.3 Mail Transactions
.....
............. Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In those
cases, the server MAY reasonably accept the reverse-path (with a 250
reply) and then report problems after the forward-paths are received
and examined. Normally, failures produce 550 or 553 replies.
This delay verification saves an average of 65% in WCSAP DNS-based
verification overhead.
----
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)
----- Original Message -----
From: "Robert A. Rosenberg" <hal9001(_at_)panix(_dot_)com>
To: <ietf-smtp(_at_)imc(_dot_)org>
Sent: Wednesday, May 25, 2005 3:13 PM
Subject: Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt
One other GOTCHA about deploying SPF - If you publish SPF records
authorizing ONLY SMTP Servers under your Control (ie: Email with a
From of *(_at_)ISP1 must come from an ISP1 SMTP Server), those SMTP
Servers MUST run their MSA (Mail Submission Agent) functions not only
on Port 25 but on at least one Non-Port25 Port (preferably the
OFFICIAL MSA Port587 [with SMTP AUTH] and hopefully also as an
SMTP-over-SSL Connection on Port465).
Failure to accept submitted email from Mail Clients on a port other
than Port25 raises a Catch-22 Situation when trying to connect
remotely from a Port25-Blocking (or Hijacking [ie: One who ignores
the Requested Server Address and forces the Port25 Session to a
dedicated SMTP Server]) Connectivity Provider. If you use the
Connectivity Provider's Server SPF breaks but the SPF Publishing ISP
provides no way to access their Server (and thus observe the SPF
Origin Restrictions) on a Non-Port25 Port.