Re: [Asrg] DNS-based Email Sender Authentication Mechanisms: aCritical Review

[Alessandro Vesely <[e-mail]>]

Amir Herzberg wrote:
> http://amir.herzberg.googlepages.com/somerecentpapers.

I've marked a number of snippets where reading faltered. Most of them 
are typos or language doubts (my English barely supports me) while 
some may stir some discussion... I just paste that stuff below, hoping 
some of it may help you better your paper.

format: "---" snippet empty-line "(" comment ")"

---
extremely low-cost, especially when sending ‘bulk’ mail

(formally incorrect, the cost doesn't usually decrease with scale)
---
Spam: there are different definitions of spam; we use the term spam to 
refer to email sent to many recipients (‘bulk’), who have not 
expressed desire to receive it.

(This also includes "legal" advertising, with variations on the extent 
to which providing one's email address expresses the desire to receive 
advertisements. Zombie-based spam is a different beast)
---
These mechanisms use the DNS system (in different ways), to securely 
identify the sender

(drop /securely/...)
---
SIDF: The Sender-ID Framework (SDIF)

(typo)
---
In particular, we make the following observations and recommendations

(Perhaps s/particular/conclusion/? All observation are unjustified at 
this point. It is not obvious for a reader whether this is an 
executive's summary and the recommendations will be derived later. 
BTW, I'd suggest to relegate part of the introductory material to some 
appendixes, so as to get to the core without interruptions)
---
There is also a side-benefit: eliminating unnecessary filtering, esp. 
the computationally intensive and imprecise content-based filtering.

(This stance disagrees with the recommendation "Do not filter emails 
based solely on SPF, DKIM and/or SIDF failures" a few lines below. The 
side-benefit is probably limited to _help_ eliminating content-based 
filtering...)
---
it is recommended that senders would mark their use of SPF in the 
email envelope,

(How? Possibly using VHLO or other non-standard protocol extension?)
---
e.g. www.foo.org.

(www.example.com is more canonical)
---
an the top is a set of root DNS

(typo, an=and)
---
Reverse DNS (rDNS) record [...] However, notice that small 
organizations [...] ownership of the corresponding rDNS entries.

(s/However, notice that/Depending on the "reseller",/: When choosing 
an ISP for connecting a mail server, would you recommend to consider 
how do they arrange for rDNS and whois? Also, s/ownership/delegation/. 
Isn't it worth to mention "PTR"?)
---
Blacklist DNS records

(should note that DNSBL are not authoritative/hierarchical)
---
DNS Security. The DNS provides an open directory service[...]

("DNS vulnerabilities" may be a more appropriate subtitle)
---
Bob’s MUA, MUABob, picks up email from the MDA.

(formally incorrect, it picks it up from the mailbox where the MDA 
delivered it.)
---
When the MUA is an application running on the same machine as the MDA, 
mail pickup is done via the file system.

(not necessarily; in addition, MDAs may run LMTP or any other network 
transport)
---
either using either an appropriate web-mail form, or using a mail 
pickup protocol, typically either

(too many "either", rewording is advisable)
---
S/MIME [27] and OpenPGP [12], use public key encryption and signatures 
to provide end-to-end protection of the confidentiality and 
authenticity of email

(Not necessarily end-to-end: I've heard of ESPs who crypt messages at 
the MDA stage, in order to grant confidentiality to their IMAP mailbox 
storage. It may be mentioned that eavesdropper who work at the ESP's 
are difficult to guard against, if the question or trusting one's ESP 
is raised.)
---
but can do use a fake domain

(is "can do" syntactically correct?)
---
claiming to be an outgoing MTA of a.com

(formally incorrect, SMTP doesn't allow a sender to say whose domain 
it belongs to --again, unless using VHLO)
---
cannot do not have

(is that syntactically correct?)
---
cannot intercept the ISN sent by the other party, therefore it can 
only guess the

(RFC1948 is of 1996, Vulnerability Note VU#498440 is of 2002, so TCP 
should now be safe. However, RFC 3552 of 2003 still considers blind 
attacks... Is it because old hardware may still be vulnerable?)
---
not all companies and ISPs enforce port 25 blocking.

(This is a good occasion to recommend port 587)
---
SPF validation is performed using the email address specified by the 
sending MTA in the HELO directive, identifying the domain that the 
sending MTA belongs to.

("email address" is formally incorrect, EHLO specifies a host name)
---
which IP addresses it intents to use

(typo)
---
spf1.0 +IP4 : 1:2:3:4 all

(typos)
---
The receiving mail agent (MUA or MTA) evaluates the terms

(Here you assume that MUAs can learn IP addresses parsing the Received 
headers and then carry out SPF checks --see discussion with Doug)
---
aa.bb.cc= 1.2.3.4

(typo)
---
Fig. 2

(The policy says ~all, different than the text)
---
if Bob is an MTA and transfers the email

(if Bob's MTA accepts the email message)
---
‘fake bounces’ are sometimes referred to as ‘Joe-job attack’

("backscatter" is also a frequently used term)
---
However, this implies that the recipient will consider this email as 
originating from foo.org.

(formally incorrect, most recipients consider the "From" header instead)
---
This will allow the recipient to avoid ‘false positives’ (incorrectly 
blocking valid mail for spam/phishing)

(SPF checking is typically done at the MAIL FROM stage, much before 
Authentication-results has a chance of being evaluated)
---
the receivers still have to make two DNS queries.

(didactic style requires to explain they are one for TXT and one for SPF)
---
we can place the policy record in an arbitrary DNS record controlled 
by the sender

(this proposal to change the SPF specs should be identified as such; 
BTW, rewriting rfc4408 is somewhat overdue)
---
retrieving the policy record policy from DNS.

(typo)
---
One clear conclusion here is that the receiving MTA should use a 
dedicated DNS proxy

(Well, this is a good advice also for performance reasons. However, it 
is not clear if you intend to suggest using multiple DNS proxies, e.g. 
a different one for outgoing mail, host maintenance and auto upgrades, 
nearby clients, etcetera.)
---
Based on experimental works on phishing [10, 16], we low detection rates

(who is "we"?)
---
SIDF records specify the relevant identifier (or identifiers) by the 
MFROM and PRA keywords

(Those keywords define the so-called "scope" of SIDF checking. Using 
such term may result in better wording of the following text, where it 
is explained that incompatibility stems from defining an incompatible 
default scope)
---
In addition, both proposals required complex key-management

(key-management is never simple. Certainly, it is not because of that 
complexity that so few clients can handle PGP. The fact is that 
classical encryption has been retrofitted, while DKIM is email-born. 
They can be viewed as complementary, though)
---
these standards do not define how a sender can specify that all of its 
email is signed

(Instead of "specify", terms such as "announce" or "publish" are not 
misunderstood as operative configuration rules)
---
(d) support for signing email headers

(what about "support for signing a signer-chosen selection of email 
headers"?)
---
19. Kucherawy, M.: Message Header Field for Indicating Message 
Authentication Status. Internet draft 
draft-kucherawy-sender-auth-header-15 (2008)

(this is now RFC 5451, April 2009)