On Sun, 2005-01-30 at 09:33 +0100, Frank Ellermann wrote:
Douglas Otis wrote:
Those publishing SPF records risk causing their mail being
forwarded by various recipients to be blocked or lost,
They don't "risk" this, they _want_ it, it's the idea of RMX
or SPF -all that "mail from A" must come from an IP allowed
by the sender policy of A. If "mail from A" arrives at C
from another IP B, then C would reject it.
If B was a spammer or mail worm the spam or worm is in fact
"lost", again that's the very idea of RMX or SPF FAIL. If B
was a legit MTA it would create a bounce message to A, and
the mail is not lost.
Either A screwed up, maybe he forgot to include B in his
sender policy, or B screwed up, maybe a secondary MX forwarded
mail to a primary MX, and the latter tested SPF without
white-listing the secondary MX. SPF tests work as expected
at the border defined by A, but not later.
You can say that you don't like this one and only feature of
SPF, but you can't say that it's a bug, because it's the idea.
Those publishing SPF records want their mail to go missing? There is no
means to know which recipient may be using a forwarded account. There
is no means to prevent a "screw up" with SPF. Forwarding is a common
practice within colleges, societies, and many providers. Validating the
legitimacy of an MTA can take place within a single lookup of a small
CSV-CSA record. A single lookup does not increase the risk to DoS
attacks, and also does not create inadvertent loss of mail, as does
SPF.
SPF however can not indicate which identity checking is
desired by the sender. Is it the Sender-ID PRA, the SPF
MAILFROM, or now the SPF MAILFROM and HELO in combination?
Not only "now", HELO was "always" mandatory for MAIL FROM:<>
and otherwise optional. It's not a new idea. And it's not
necessarily a good idea, actually it was one of the things I
hoped to solve in the former MARID WG, but unfortunately it
wasn't allowed to discuss 2821 and CSV. [The SPF overhead
for simple HELO checks is IMHO too big]
The draft just submitted changes both when the HELO is checked and the
outcome of this checking. Previously, someone ignoring the use of SPF
for HELO would likely find their bounce messages treated as from an
"unknown" source. With the change being made, the HELO may now be
checked against a record found at the zone apex. This unexpected change
could cause their bounces to be rejected AND also their mail to be
rejected, as the HELO check is to be done in combination with the
MAILFROM rather than as an alternative for handling bounces. These are
changes publishers could not anticipate.
I agree, the overhead for HELO checking would be unacceptably high with
SPF, in addition to the other problems SPF records create.
Sender-ID PRA has nothing to do with classic SPF policies, it
only uses a somewhat similar syntax for Sender-ID policies.
Pobox still claims Sender Policy Framework is the essential part of
Sender-ID. It matters how the publishers are basing their decisions. I
have yet to hear any admonishment by proponents that when publishing
SPF, expect some of your mail to be lost or rejected due to problems
with either SPF et al or Sender-ID algorithms. This is shameful.
This gets even worse with use of this same TXT RR by more
than one faction.
If somebody abuses a protocol for a completely different
purpose, and it breaks, then he owns the pieces. As far as
SPF and I'm concerned the goal is a SPF RR replacing TXT in
the future. One of the reasons why I wanted an RfC.
The other reason was to get an "official" document which can't
be modified only because the authors have a new idea. That's
now solved by the formation of the SPF council.
A mechanism built upon a strategy that can not support revision does not
require a council. Nor would it likely find approval by a standards
organization that cares about compatibility and a need to support
orderly change.
The new SPF processing limits are stated differently
They are just clear and better. The handling of all errors is
now much more predictable. Minus DNS timeout errors the same
policy should now have the same effect with all conforming SPF
implementations.
This conclusion is guess work. You could be right, but those that have
published what is now considered too many records may find their mail
being rejected. The SPF timeout imposed still ignores UDP fallback.
Normal exponential fallback ensures congestion avoidance. This
oversight for such an intensive use of DNS is a serious concern.
This compares poorly to CSV which uses a single lookup to
obtain the CSV-CSA record.
Depends, many policies need only ip4 and all, and that causes
no additonal lookup. a, include, exists, and redirect need one
lookup. Ignoring the discouraged ptr only mx is "difficult",
but OTOH looking up MX is something any MTA knows. Yes, there
is a significant potential overhead, that's the price for its
great flexibility like per-user policies.
Will imposing the task of implementing the sender's per-user policies
upon the receiving SMTP server scale? Is it reasonable to expect the
receiving SMTP server to perform a hundred lookups per message? I see
this "great" flexibility stemming from an overly ambitious marketing
effort that continues to ignore serious problems. I agree with you,
there is a need to move toward a name basis to establish meaningful
feedback to administrators of MTA systems. A name basis would help
centralize the effort at getting rid of abuse. This can be safely
achieved via the efforts in MASS and CLEAR, but not with SPF.
-Doug