There are a few areas in this review that differs, if considering the
channel versus the message. As this is a general overview for MARID, it
should be more comprehensive. The intent is to focus upon claims made
for Sender-ID.
Page 4:
In a designated sender scheme, the question becomes: "is the SMTP
client of an incoming message authorized by the purported sender of
that message to send the message?" The primary identity is the sender
of the message --- the (administratively independent) entity
responsible for the most recent injection of the message into the
mailstream.
Sender-ID assessment is weak and dependent upon checks made at undefined
administrative boundaries. Even with full compliance, there are many
areas where identification of the sender remains suspect. In addition,
the ability of an administrative domain to "usurp" permissions as with
list servers, or messages that originate from an "open" domain still
places the burden upon the recipient to sort through these
representations. Nor does Sender-ID curtail the volume of this sorting
task. Should a domain offer other domains permission to originate their
mail due to their use as an access provider or other related services,
then this public announcement offers a means to spoof, especially when
70% of these providers do not authenticate users on their networks.
Note that designated sender schemes are generally better suited to
identifying senders and cryptographic schemes are better suited to
identifying authorship.
The "sender domain" is not always identified by the designated sender
scheme. The sender domain may enable indirect authentication of other
domains or leave their accountability "open" as a means to allow remote
users continued use of their return address. Identification of the
domain of the senders may remain indeterminate and yet be compliant with
the designated sender scheme. This greatly erodes accountability,
closing avenues of curtailing rogue abuse. In the case of the "open"
list, this identification includes the entire Internet. This statement
also leaves out the non-cryptographic method of identifying the sender
(where the sender is the sending SMTP client).
Page 5:
Zombies versus hobbyists:
A - A majority of spam today originates from end-user machines
infected by viruses that send spam directly to receivers' MX
servers. Such zombies should no longer be able to send
direct-to-mx spam.
B - Linux hobbyists should still be able to send mail from their
consumer-grade broadband connections. They may have no control
over the PTR records of their assigned IP addresses, but the
concept of first-class and second-class citizenship rankles many
idealists who believe in an unfettered end-to-end model of pure
IP connectivity.
Any user would be able to employ a simple mechanism that relies upon
forward DNS queries. There are many offering name servers that handle
dynamic IP addresses, where support for this type of name service
is often included in low cost network address translators common for
home use. B, in this case, is in error. In addition, many providers
are offering this dynamic address name service free of charge as a means
to promote other services. This would work equally well for users on
static addresses. A simple forward reference allows a change from the
paradigm of rejecting senders from dynamic IP addresses as a means to
curtail infected systems. Stopping a virus is not a property of
Sender-ID however.
Page 7:
Nipping the innocent in the bud:
A - Spam should be stopped before it starts; to limit the cost of a
spam attack, receivers should by default adopt a skeptical stance
to any unknown input. In big cities, people don't talk to
strangers.
B - In small towns, people smile at strangers. Senders should be
assumed innocent until proven guilty. Any person should be able
to get onto the Internet, register a domain, and immediately
email a hundred of his closest friends.
This misses the possibility of allowing all sending domains (not
messages) to identify themselves and thus prevent abuse before even a
message is started. With a simple forward query, every sender dons a
name tag. Unlike the current system of just depending upon IP addresses
for vetting a connection, an authorized and authenticated name means the
receiving server will know the name of the stranger allowing a
determination as to whether they are new to the system. Sender-ID
will always leave the door open and allow strangers to assume the
identity of any domain enabling remote access.
DNS: Caching versus parsing.
A - To reduce the burden on clients, records should be easily cached.
Records that describe the full set of designated senders up front
are easily cached and require no subsequent lookups. However,
such records require parsing.
B - To reduce the burden on clients, records should require minimal
parsing. Records that answer "yes/no" for a given query aganst a
domain/IP tuple can be easily parsed using existing DNSBL logic.
However, such records are not easily cached, particularly when a
wide range of IP addresses produce multiple negative results.
This overlooks optimizations offered by standard DNS records. These
records are understood by libraries in hundreds of programming languages
and do not require a special parser to run concurrent with the reception
of mail. These records would be acquired once per connection rather than
many per message and offer the same protections as obtained from any
administrative domain that "usurps" permissions.
Once implemented widely in receiving SMTP servers, Sender-ID may damage
services of those domains publishing their lists as “open” as a means to
allow their users an ability to employ other points of access with their
return address. Abusers will take advantage of published partial lists,
especially those constructed with wildcards, and may inadvertently
create the effect of a distributed denial of services attack by
dispersing destinations from tens of thousands of machines using random
sub-domains as a standard obfuscation ploy against filtering techniques.
The option to partially publish should be removed due to this hazard.
Once discovered as a general problem, the removal of a partial Sender-ID
record would need to be done on a proactive basis, as those that abuse
often do not honor DNS TTL time limits. Removal of the Sender-ID record
in response to DDoS event will not provide relief, but may increase the
severity of this event, as a negative response is not cached remotely
for a long period of time. Should the record be changed to "closed" in
response to the DDoS, then their user's mail may become silently lost.
Those that operate with a large "closed" list may also become targets
for an intended DDoS attack. Messages spoofed will force the entire
matrix of records to be explored. The attacker's goal could be two
fold. One would be to convince receiving SMTP servers to disable the
Sender-ID check within the channel, and the other would be to convince
those with the attacked name server to remove the Sender-ID record. No
record linking or chaining could be made a requirement due to this
hazard. Those unable to comply with these limits should be advised not
to publish any Sender-ID records.
The motivation to attack would be to instill trust by artificially
obtaining a positive Sender-ID result by causing checks removed from the
channel. To be abusive, spoofing a return address is not required, but
Sender-ID does not remove all means for continuing this practice
either. By allowing this practice to continue through exceptions made
in the check, a great risk is placed upon the DNS and SMTP servers.
Page 8:
DNS: use of XML vs development of a little language
A - The syntax should be easy for receivers to implement. The
adoption of existing data formats such as XML means that existing
libraries can be used to parse the data. XML is popular among
the Microsoft community.
B - The syntax should be easy for receivers to implement. The use of
a custom-made little language means that heavyweight XML
libraries are not required. XML is generally unpopular among the
open community.
Using standard (non-text) DNS records, no syntax needs to be
developed. It also seems there should be a mention with regard to
leaving these text record definitions open-ended or subject to standards
review.
Page 10:
4.1.2 Minimizing friction.
Even the least amount of friction will impede adoption. The Design
should take advantage of existing capabilities wherever possible. The
design should optimize for the path of least resistance. The less
overhead needed to publish a record, the better.
The less overhead needed the better. Why emphasize publishing?
Sender-ID changes the way mail is used. Sender-ID will cause users to
change their use of mail and require updated servers and clients which
will impose a slew of problems. Users may discover their SMTP
transactions are transparently intercepted by their ISP thus
invalidating their mail. Repair of this problem means other clients of
this ISP will be able to forge mail as if from this user, but now with
an indication the message has been checked. Sender-ID trades an
effective means of abuse control for a mechanism that offers no control.
4.2 Design Guidelines
The design guidelines that result from the above goals are:
4.2.1: optimize for ease of publishing over ease of implementation.
4.2.2: follow the path of least resistance.
4.2.3: Find a middle way by setting mechanism, not policy.
Where design alternatives appear to conflict, find a
technical compromise that lets each school operate; do
not mandate or prohibit any of the choices.
Lists published in an attempt to correlate users to domains fails to
follow the path of least resistance. Ease of publishing complex
relationships invites attack and will thwart deployment. Publishing the
outbound SMTP servers for a single domain irrespective of return paths
indicated within the mail messages is far simpler and much more
effective at establishing accountability.
Page 12:
In accordance with its "mechanism, not policy" design philosophy,
Sender ID makes the "zombies versus hobbyists" tradeoff in favour of
hobbyists who are assumed to control the forward DNS of a domain they
own. The important thing is to establish accountability: if a spammer
wishes to designate a zombie as a permitted sender, the message is
Sender-ID conformant; it is the responsibility of the reputation system
to reject the message.
Unlike Sender-ID, a forward DNS query can be comprehensive in that it
offers no areas for abusers to hide, whereas Sender-ID will allow
viruses to continue unabated. A reputation system MUST assess ONLY the
domain handling policy and the mail stream. There are no sure methods
using Sender-ID to enable assessment of accountability for mail found to
be abusive.
6.1.2. Am I an MTA for the HELO domain?
The next simplest scheme asks the domain of the HELO command if the IP
address is a permitted sender for that domain.
- DRIP
- CSV
Authenticating the HELO identity is useful for whitelisting by MTA
hostname.
Reputation services could evaluate relays identified in the HELO
domain.
CSV enables accreditation and reputation services for ALL domains
sending mail, and is not limited to just use with relays. Those domains
that fail to abate abuses can be themselves abated. Sender-ID does not
allow accreditation and never stops the introduction of abusive messages
with an ability to hide within a myriad of open Sender-ID records.
Sender-ID may thwart a type of message fraud, but do not expect this to
stop abuse nor fraud nor ensure its abatement.
-Doug