[Top] [All Lists]

Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt

2005-05-25 21:18:58

At 16:17 -0400 on 05/25/2005, Hector Santos wrote about Re: SPF I-D for review: draft-schlitt-spf-classic-01.txt:


The whole purpose of the LMAP protocols is to help close the SMTP loophole -
AKA the massive exploitation of Anonymous Final Destination Transactions.


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

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