At 00:38 -0500 on 05/25/2005, wayne wrote about Re: SPF I-D for
In <200505241504(_dot_)42014(_dot_)blilly(_at_)erols(_dot_)com> Bruce Lilly
On Tue May 24 2005 13:05, Frank Ellermann wrote:
> That's at the heart of the problem -- it attempts to define
> a set which makes no sense; worse than that, it is harmful.
It does not _attempt_ to define this set, it only _allows_
to define this set.
But as the sender of mail, and the person affected, it doesn't
allow *ME* to do so. If -- in a fit of stupidity -- somebody at
the ISP where I *receive* mail were to do so, I would either be
forced to use a null return path (breaking the intended function
of delivery notifications, as noted by Markus), or I would drop
that ISP like a hot potato and find one with more sense.
I'm a strong believer in "their server, their rules", and also "the
domain owner's domain, their rules". If your ISP does anything you
really don't like, I complete agree that you should switch. For only
a few bucks a year, you can also buy your own domain name and then you
can set the rules for the domain you use.
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.