"Radu Hociung" opined:
I have a bone to pick with the %{l} macro.
A domain that is publishing such a macro allows in one way or another
that a user of the domain name mess with the domain's reputation.
In the near future, if all goes well, reputation databases will be
possible using the information derived from SPF authorization.
So a simple include:%{l}.whatever means that the domain's reputation
will be affected by the actions of any single user. The case is the same
for a:%{i}.dyndns.mydomain.com (in the SPF policy of mydomain.com)
In my view, publishing %{l} is too high of a risk that the reputation of
the entire domain be tarnished by one single user, during a single
incident. Single-user domains don't have much to lose, as
domain_reputation==user_reputation. But those domains also don't have a
use for %{l} :)
So, how likely is any domain to want a %{l} in their policies after
they've considered all the implications?
If it is dangerous for the large domains, is it less dangerous for the
smaller domains? I think of dangerous in terms of "dangerous for the
domain's reputation".
I regard the pobox.com and listbox.com's SPFs as poorly thought out
policies, and I do not believe that their use of %{l} can be defended
easily.
Chris Haynes wrote:
Maybe I'm still half asleep, but I don't understand your concern.
If a single user misbehaves in the sending of mail, that tarnishes the
reputation of her entire domain, regardless of whether or not a
person-specific policy is in use.
An individual cannot set the content of her own policy just because she
has one allocated to her; all the policies are under the control of the
DNS administrator for the domain as a whole. If a domain admin.
publishes something like +all at the request of a user, it's the
domain's fault for being stupid when bad things happen.
It would be possible for an individual in domain A to have a %{l} which
includes or redirects to some other domain's SPF record, and for that
other domain (perhaps later) to publish something stupid or dangerous
but, again, whether off-domain references are permitted in the first
place under the control of the DNS admin. of domain A.
My concern is not with theoretical use of %{l}, but with practical use.
I can't think of a practical scenario where using %{l} makes sense, such
that the benefits outweigh the negatives.
Let's look at a couple of examples:
A company with remote employees.
--------------------------------
I think most/all such companies are more likely to use VPNs and/or
encrypted SMTP AUTH. The alternative, allowing the employees to run
outgoing MTAs from potentially hostile networks, and allowing
potentially confidential information unencrypted on such hostile
networks is unwise.
The practice of employees running MTAs is also an unreliable one, as
when they travel, they are very likely to have their port 25 blocked. In
that case, the only use they have for %{l} is if the companyA employees
use their ISP or companyB mail servers (companyB could be the competition).
If employees do send through their ISP, the company IT infrastructure
could be faced with a lot of work including SPF policies of ISPs, because:
1. employees may switch ISPs
2. Not all ISPs publish SPF. Once you put a %{l} in a policy, any
includes that use it, must have an SPF policy, or mail flow breaks. In
this case, to be fully reliable, the company would have to publish an
SPF policy equivalent to the ISP's, but hosted on its own DNS. then it
could substitute +all policies for ISPs that do not publish SPF.
In my view, the issues outlined make %{l} impractical here.
Colleges
--------
Some of the issues with companies apply here also.
Additionally, the user base is guaranteed to be large, so the chore of
manual maintentance of per-user policies by IT is also impractical.
Travelling salesmen
-------------------
Blocked port 25. Their mail is forced through home base SMTP AUTH on 587
because of this, Thus no need for %{l}
Hobbyist networks
-----------------
A user of such a network may be allowed to do what they please.
The user base is likely to be proficient enough to make use of
task-specific email addreses. (For instance, for this mailing list, I
post using radu(_dot_)spf(_at_)ohmi(_dot_)org, such that any SPF related email
is
automatically sorted in the SPF-relateds folder, even if sent off-list).
This means that every time a new mail folder is created, I would have to
create also a DNS entry, and make it auto-compiling somehow, so I can
send email from anywhere I travel with my notebook.
Again, this work gains me nothing. Using SMTP AUTH solves several
problems, and makes %{l} unnecessary
An ISP or mail forwarder
------------------------
In order to even be profitable, such an outfit needs a lot of paying
customers, given the fierce competition in the market.
With a large userbase, it becomes impractical for the ISP to manually
check all per-user policies, in a timely manner, such that mail from the
customers flows reliably. If the ISP is selling SPF as one of the ways
that makes it's mail services reliable, %{i} would only undermine that
reliability (takes time and is error prone to maintain all per-user
policies).
Such an outfit would have no choice but to allow users to specify their
own policies, and have some automated way of inserting it into the ISP's
zone as it gets updated.
Unfortunately, as you have seen yourself, this would open the gates for
any one user to tarnish the reputation of the ISP. With a large user
base, this tarnishing is a guaranteed outcome of %{l}
Perhaps you can come up with a practical use of %{l} that makes sense in
the real world?
Theoretically I understand the benefits of %{l}, no need to rehash those :)
Thanks,
Radu.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
smime.p7s
Description: S/MIME Cryptographic Signature