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)
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg