At 16:17 -0400 on 05/25/2005, Hector Santos wrote about Re: SPF I-D
for review: draft-schlitt-spf-classic-01.txt:
Robert,
The whole purpose of the LMAP protocols is to help close the SMTP loophole -
AKA the massive exploitation of Anonymous Final Destination Transactions.
[snip]
----- 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.
Maybe I am being dense but I fail to see what relevance your comments
(which I snipped) had/have to do with my observation as quoted above.
To restate the observation logically:
1) Given an suggestion (via the publication of SPF Records) that SPF
be used to allow a receiving MTA to verify that a message being
relayed to it is being relayed by a MTA that is authorized by the
Owner of the Domain whose message it is to do such relaying, there
must be a way to supply the relaying MTA with the message.
2) Since the attempt to supply/submit such messages may be being
done via a connection from a ISP other than the one responsible for
the Relaying MTA, there must be a way to establish the connection to
a MSA at the Domain Owning ISP.
3) Since some Connectivity Provider ISPs prevent this connection
occurring via Port25, some other port must be used when getting
connectivity from such a provider.
Conclusion: To insure that the SPF Rules can be observed, the MSA
which is to be contacted so it can accept the message submission and
thus relay the message (either by the MSA SMTP Server acting as the
relaying MTA or by an MTA that the MSA has handed to message off to)
must be monitoring a Non-Port25 port. This is to handle connections
that occur from ISPs who refuse to allow the connection to occur over
Port25.
What disagreement (if any) do you have with this scenario? Note that
I am NOT addressing if SPF is a good idea (or will work). I am taking
its deployment and operation as a given and stating requirements that
should be in place for it to function as it is designed to operate.