--Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
As on related note, I mentioned this to Meng as well.
This "testing" attributes has been exploited by SPF compliant spammers
and/or spammers knowing the existence of "relaxed" SPF/CEP records and use
these DOMAINS over others. All a spammer needs to do is "google"
Receive-SPF and they will find the "neutral" and "softfail" records,
pretty much in the same way a SPAMMER will collect the recent entries
into a RBL database and exploit the idea that it will take X days before
the open relay/proxies is closed by the system admin.
Lets [not] close current loopholes by introducing new ones.
One person's "loophole" is another person's "optional policy".
Here is MY opinion...
Some users may only elect to use LMAP to whitelist some MTAs and leave the
rest alone- neither authorized or denied. Similar to "+ip:x ?all". If
they want to do that, whatever floats their boats. We should not go around
second-guessing them or folding their record to -all after a certain time
or otherwise monkeying with their stated preference.
Here is why I believe this. If the "safest" thing to do, to not have any
mail dropped by the new LMAP scheme, is to do nothing and leave LMAP
undefined for our domain, people will opt for the safe method. The
"fallback to unknown" mechanism ensures the domain owner that their +
entries will get the "approved" treatment BUT the ? entries will suffer NO
ill effects compared to a non-LMAP domain. This is an important lever to
adoption, I think... at least it was important for SPF to state it as a
MUST.
IF we are talking about the same thing (i.e. a "fallback to unknown" type
of behavior) then I would not describe it as a loophole. Why would a
spammer try to game the system just to get a neutral result? That would
not get them approved or whitelisted anywhere... they would get better
results by registering their own domain and publishing +all. ?all does not
hurt the message when invoked but it also doesn't give them a boost either.
I (personally) would not refer to it as a "loophole" because that would
imply it's a "design defect" when in actuality it was done that way
deliberately. Disagreeing with the design doesn't automatically make it
defective.
(And yes I get defensive when SPF is described as "having loopholes" when
it was designed with that feature there on purpose, but Hector and I have
had discussions about that in other contexts too :)
I highly suggest that the documentation make it very clear "testing"
attributes are time limited options and designed for preferred short
migration periods. In addition, I suggest a statement be added eluding
to the probability a system implementation will catch on this exploit and
will add their own "time limited" caching. In other words, a system
might record the first usage of these 'testing" records and then put a
expiration and/or counter time on it repeated usage.
You, nor Meng can not stop us from implementing this sort of "derivative"
logic in our receiver system that compensates for the "holes" in the
current functional specification.
Hmm, you seem to have strong feelings on this one. I hope this is not the
majority opinion, because if we as a group state that "Unknown is OK but
many recipients will not respect that and will treat it as a fail after a
while" will send up red flags to managers who would like to implement as
safely as possible. I would much prefer to be able to tell them that
"unknown means fall back to the old behavior, as if no info was found."
Perhaps "unknown" will be deprecated by a future RFC but there are a lot of
events that have to happen first, many of which don't have schedules (yet).
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>