On Fri, 2004-09-10 at 08:25, Alan DeKok wrote:
Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
If the mailbox domain has been safely blacklisted, then no confirmation
with respect to the IP address from the SPF records is needed.
RFC 2821 header checking against authentication records in DNS
enables recipients to safely blacklist mailbox domains.
i.e. 100% of messages from a domain pass RFC 2821 DNS checks, and
are spam: the recipient may choose to blacklist the domain.
I would restrict this to the EHLO domain. Using the MAIL FROM is making
an assumption of the integrity of the mail channel providing the
message. There is nothing to substantiate such an assumption and
defending a blacklist is not a trivial matter. There is naturally a
reasonably strong authentication of the IP address through transport
protocol interaction. The use of names MUST be held to at least the
same level of authentication. A name, unlike an IP address, may disable
mail and, effectively, how a business is identified!
Those running blacklisting services MUST be prepared to defend negative
name based assertions, especially with a name's broader impact. A point
of view that the mail channel "should" be secure and publishing an SPF
record represents an implicit agreement the mail channel shall be
considered secure is not defensible. "Tough luck, find a better
provider!" does not address a possibility the provider may not be at
fault. There are at least two realms that must be secure.
In the absence of those checks, the recipient can still blacklist
the domain, but has no way of knowing for sure if the messages are
forged, and thus an attack by a malicious third party, who wishes to
disrupt communications between the alleged originator and the
recipient.
Those checks with respect to MAIL FROM and even the more extreme From
with Sender-ID, still assumes the mail channel is secure. In the case
of "open" records, it is assumed the outbound mail channel is not being
shared. Where the normal implementation may be to publish the "nominal"
sources of a mailbox domain and leave the record "open" as a solution
for the forwarding issues, allows messages to suffer "validation"
promotion moving through the mail channel.
Should abusive mail be discovered, it would be unsafe to conclude
the SPF mailbox-domain/IP address confirmation is tenable for
establishing a name blacklist.
Are there reasons why this is true?
In short, the mail channel can not be assumed to be secure and not
shared.
Only the IP address has received sufficient authentication for such
a listing, but then this has not improved upon current IP address
blacklisting.
You are stating that your position is that your position is correct.
I was responding to Damon's statement that he was not looking at the SPF
record for making a decision. If only the IP address is being used,
then this has not improved upon the current IP address blacklisting.
The address space is becoming more dynamic, but there are still
black-holes implemented in routers by some providers that tend to
permanently disable address space due to bad policies of companies now
long out of business. Reclaiming this space may take decades. Moving
to a name based reputation system allows a long history to exist without
the overhead needed to track this exchange of IP addresses.
Trojan proxies are largely an outcome of the need to commandeer an
address that a blacklist attempts to make scarce. While the number of
names of the good actors should reflect real uses, the number of bad
actors will explode should a name blacklist become effective. This will
require taking advantage of the history that a name naturally provides.
This may seem like a poor choice, as the IP address space is bounded and
the name space is not.
To deal with such a difficult problem may require:
a) Retain good actors long term
(proved worthy of the magnetic domains expended)
b) Establish policy based affiliations
(agrees to Opt-In only perhaps)
c) Limit exposure from new domains
(cap messages perhaps)
d) Improve vetting of domain name applications
(industry sponsored clearing house perhaps)
There are many cases where an MTA is shared.
...
A breach in the mail channel integrity can happen within either the
receiving or sending realm. An SPF blacklisting fails to locate the
accountable entity.
Shared services means shared accountability. If the recipient is
unable to distinguish between a "good" party on a shared MTA and a
"bad" party, then by definition, both parties fall into the same
classification.
Sharing an MTA is a highly effective method used by ISPs to abate abuse.
Reserve painting this technique with such a broad brush. This wide
brush never uncovers an MTA that may be compromised or poorly
administered. Holding those unable to take immediate corrective action
accountable will cause a most unwelcome backlash. The party that must
be held accountable is the entity administrating policies of the MTA.
That party is only identified by an authenticated EHLO domain or the IP
address.
Having the MAIL FROM or From reference a name list of EHLO domains
allows a simple and safe method of publishing either the typical,
compatible, "nominal" record, or the atypical, breaks-everything,
"restrictive" record for outbound MTA servers. Making the authenticated
EHLO domain visible and used as a basis for establishing reputations,
affords consumer protections superior to that of the PRA algorithm. This
approach allows a policy that always restricts the From, as example.
Establishing a name for the MTA allows a "single" DNS lookup to further
establish the Mailbox-domain to MTA relationship in a non-exploitable
manner, and not the few hundred lookups required by SPF. When SPF is
used to express the nominal outbound mail channel, this invites the very
exploitation SPF had promised to curtail!
SPF is good for white-listing. For white-listing, I like the binary RR
specified by RFC3123 by P. Koch, "A DNS RR Type for Lists of Address
Prefixes", June 2001. There is a bit of a mess with CIDR notation in
SPF. It would be better in the long run to keep this information
concise and as part of the standard DNS reference library.
-Doug