[Top] [All Lists]

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

2005-05-26 07:13:20

On Thu May 26 2005 00:00, Robert A. Rosenberg wrote:

must be a way to supply the relaying MTA with the message.

should be obvious -- if a relay is used.  In general, there
has to be a reliable path to recipients' MX hosts, either directly
or via relays.

there must be a way to establish the connection to 
a MSA at the Domain Owning ISP.

that presumes that a particular MSA (or MTA) is always used,
which isn't a universal condition.

  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.

That's a direct consequence of port 25 blocking, largely independent
of other considerations.
No question that if SPF is used it presents obstacles that need to
be worked around.  Your conditions therefore are necessary, given
the stated auxiliary conditions, but are not always sufficient.  For
example, a few years ago I was managing a small (~15 recipients)
mailing list.  The typical case was to send one instance of each
distinct message to an ISP's MTA with the recipient list (primarily
because the connection was a dialup link).  However, at various times,
there were problems with a couple of recipients -- in one case the ISP
was getting (or asserting) bogus NXDOMAIN and was bouncing messages,
and to work around that, it was necessary to send a separate copy to
the designated MX host for the recipient domain, which worked fine.
In theory, that sort of problem shouldn't happen -- in practice it
does, and SPF and SPF-like schemes impose an additional necessary

the ISP's MTA must work 100.00000% of the time, even when there are
foul-ups in DNS records (I seem to recall a rather large domain name
which was "hijacked" about six months ago, Robert, you might recall
something about that).  Without SPF-like schemes, it's possible to
work around problems such as the case noted in the previous paragraph.
In the presence of schemes which thwart such work-arounds by forcing
traffic through a choke point, that choke point needs to work
perfectly, no matter what, with no more end-user effort or time than
work-arounds would take (~1 minute -- in particular it can't depend
on a several-hour wait to talk to an ISP "tech support" person who is
clueless about mail routing, and that's the unfortunate reality).
While we'd all like to "kill" spam, collateral damage to legitimate
mail traffic -- for mobile users, for working around problems, etc. --
is simply unacceptable.

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