On Mon, 2004-09-20 at 06:51, Stephane Bortzmeyer wrote:
On Wed, Sep 15, 2004 at 08:39:30PM +0200,
Markus Stumpf <maex-lists-email-ietf-mxcomp(_at_)Space(_dot_)Net> wrote
a message of 27 lines which said:
Why all the hassle. Let the people/market decide.
- if someone publishes -all and gets important mail bounced s/he can
still decide to remove/change -all
I agree. This is a local policy issue. The second paragraph in the
section 2.2 of draft-ietf-marid-mailfrom-00.txt ("SHOULD publish SPF
records that end in "-all") should be deleted or moved to "Security
considerations" with a less demanding wording.
Publishing "open" records using "?all" or "+all" is not without risk and
is the reason for indicating a SHOULD USE "-all". Unless there is a
restructuring of the methods to authorize the MTA separately from the
association of the MTA to mailbox domains, an "open" list will invite
spoofing in a quest to falsely claim to be "authorized" by this mailbox
domain. While such an "open" list is vital to ensuring mail is not
lost, it also invites the problem SPF attempted to address in the first
place. It is not reasonable to expect a near-term solution for this
problem.
This creates a quandary. The list can not be closed without causing
mail to be lost, yet leaving the list open invites the problem that was
supposedly being solved. It is also hazardous to allow unknown entities
to dictate various DNS records of differing domains be looked up
sequentially within a process that grants authorization. The many
varied record types that SPF allows to be arbitrarily referenced
dramatically increases the risk. This also opens up other security
concerns as the message may reference a website using poisoned records.
The means of delegation to other domains could be done by name and not
by address to avoid this problem. By using a two step approach, the
mailbox domain and MTA relationships can be name based. A list of names
can be obtained in a single DNS query and does not require a script.
This allows dropping use of TXT records as no amount of script changes
or warnings offers a solution for the many fundamental design flaws:
a) Prone to DNS record poisoning
b) High overhead prone to DoS attack
c) UDP exponential back-off ignored
d) Allows phishing and spoofing
e) Invites spoofing MAIL FROM!
f) Identity easily spoofed to receive "Pass" or "Neutral"
g) Identity does not locate source of abuse
h) Identity does not accurately authorize the MTA
i) Weak identity unsuitable for reputation assessment
j) Script macros make SPF records unsuitable for white-listing
k) Script macros allows spammers to hide their full address list
l) Closed list will break mail
m) Closed list may force use of provider's mailbox domain
n) Process does not indicate records as "open" or "closed"
o) MTAs not indicated as "shared"
p) Can be used to falsely gain credibility by passing checks
If this was a medicine, it would only make the patient sicker. Clearly
the risks do not out weight the benefits. There is a viable solution
however.
-Doug