With the latest increase in the number of DNS lookups required to
support construction of the Sender-ID record matrix, and time allotted
being more than 3 minutes per message, the ability to defend from DDoS
attacks may prove intractable. The number of DNS queries could be
hundreds per message, as an attack intended to disable channel checks.
Sender-ID employs existing SPF records intended to qualify the RFC 2821
MAIL FROM, but then fully ignores the RFC 2821 MAIL FROM. Sender-ID
introduces "Purported Responsible Address" (PRA) from the RFC 2822
headers, where differing types trump more recent headers. Dropping the
MAIL FROM strategy of ASRG to adopt this complex and proprietary scheme,
this ensures bounce mail and phishing continues. : (
Establishing accountability of sent mail and validity of the return path
is ignored by Sender-ID. If an MTA is not checking users as messages
are received, perhaps found when selecting low preference MX records,
machines of backup MTAs, or relay providers, then these MTAs can be used
to send mail to an intended target via the return path. (There is
little advice how to handling multi-parts or malformed partitions for
PRA determination. This and header trumping could prove fertile soil
for abuse.)
The back door remains open.
MAIL FROM: <intended(_at_)target(_dot_)com> (never checked per core draft)
RCPT TO: <random-1(_at_)dup(_dot_)com> (could be local user, but is not)
Resent-From: <known(_at_)dup(_dot_)com> (any open record or not checked)
From: <intended(_at_)target(_dot_)com> (don't care per core draft)
To: <random-1(_at_)dup(_dot_)com>
Subject: Secret
...
The bounce becomes:
PRA = known(_at_)dup(_dot_)com (validated)
MAIL FROM: <root(_at_)dup(_dot_)com> (bounce not compliant)
RCPT TO: <intended(_at_)target(_dot_)com>
Subject: Undelivered Mail
...
Resent-From: <known(_at_)dup(_dot_)com>
From: <root(_at_)dup(_dot_)com>
To: <intended(_at_)target(_dot_)com>
...
From: <intended(_at_)target(_dot_)com>
...
Would this be validated as originating from known(_at_)dup(_dot_)com and sent to
the inbox. If recognized as a bounce, what would the following variant
do?
MAIL FROM: <intended(_at_)target(_dot_)com> (never checked per core draft)
RCPT TO: <random-1(_at_)dup(_dot_)com> (could be local user, but is not)
Resent-From: <Mail-Deamon(_at_)dup(_dot_)com> (any open records or not checked)
From: <intended(_at_)target(_dot_)com> (don't care per the core draft)
To: <random-1(_at_)dup(_dot_)com>
Subject: Secret
...
The bounce becomes:
PRA = <Mail-Deamon(_at_)dup(_dot_)com> (validated)
MAIL FROM: <> (compliant)
RCPT TO: <intended(_at_)target(_dot_)com>
Subject: Undelivered Mail Returned to Sender
...
From: <Mail-Deamon(_at_)dup(_dot_)com>
To: <intended(_at_)target(_dot_)com>
Subject: Secret
Resent-From: <Mail-deamon(_at_)dup(_dot_)com>
...
From: <intended(_at_)target(_dot_)com>
Phishing continues:
PRA=<796(_dot_)44(_dot_)4556(_at_)big-bank(_dot_)cc> (a personal number you may
recognize)
MAIL FROM: <accounts(_at_)big-bank(_dot_)com> (never checked per core draft)
RCPT TO: <phishee(_at_)dup(_dot_)com> (could be local user, but is not)
Resent-From: <796(_dot_)44(_dot_)4556(_at_)big-bank(_dot_)cc> (validates)
From: <accounts(_at_)big-bank(_dot_)com> (don't care per core draft)
To: <phishee(_at_)dup(_dot_)com>
Subject: Bogus Claim
...
Headers that trump more recent headers should prove to be a difficult
item to assess and equally difficult to sort. Would a mail sorting rule
ignore the From if the Resent-From does not match? As this Sender-ID
mechanism is primarily intended to assist filtering, how mail is sorted
as a result, if done differently between MUAs, could also allow an area
for confusion and fraud.
Could this be done using a DNS cache poisoning technique to even hide
real name of the PRA? The extensive set of tools available with SPF
makes this possibility greater.
CSV can close the front door for spam and Trojans. SPF or BATV can
close the back door. What feature does Sender-ID bring to the table,
other than support for folders?
-Doug