Goal- Validate identities as a basis for reputation checks.
Sender-ID identities are assumed from RFC2822 message content selected by
way of the PRA algorithm, and confirmed with an anonymous MTA remote
client address being within the prescribed Mail Channel.
Problem:
Many domains share common MTA servers. Some of this sharing may occur as
a result of transparent interception of SMTP traffic, as example. This
technique and other practices that relay mail is not well addressed within
the Sender-ID draft. Sender-ID tends to consider validation being
end-to-end, but mail is often relayed and this aspect of mail is not
properly accommodated. This interception technique is an example of a
relay practice that is highly effective at preventing abusive mail, but
depends upon low transactional overhead to handle high volumes. An
interception server often does little more than log SMTP errors for
review. Network providers using this method can detect abnormal levels of
refused mail evidenced in the logs to quickly isolate abusers.
Sender-ID requires public DNS records to prescribe the Mail Channel. A
shared MTA may not be apparent unless compared with other domains, so the
recipient should assume all Mailbox Domains may share an outbound MTA.
Miscreants can discover these shared MTA servers by comparing public
records. Should the Mailbox Domain also publish "open-ended" records for
the prescribed Mail Channel, this too will be apparent to miscreants. Any
message delivered to the shared MTA initially outside the prescribed Mail
Channel, will then appear as being within the Mail Channel as the message
is relayed. The same problem of "validation promotion" can happen when
the shared MTA fails to perform Mail Channel checks against each PRA
Mailbox Domain.
There is nothing within Sender-ID to notify a recipient the Mail Channel
has failed to perform needed checks, or that the Mail Channel is being
shared in the case of an "open-ended" record. If a miscreant decided to
market sexual aids falsifying such a Mailbox Domain, this identity could
be seen as fully validated while not prevented by the published Mail
Channel records. Just as a lapse in Mail Channel checks may occur within
an outbound relay, the same problem may also occur within an inbound
relay. In both cases, a presumption of a Mail Channel check allows
undetected spoofing.
Should a reputation service also presume Mail Channel checks were made or
that the Mail Channel is not being shared, then innocent entities, through
no action of theirs, may find their mail blocked or filtered. If the
reputation service persists in efforts to stop abuse based upon false
assumptions of the reliability of Sender-ID identities, such will likely
require legal resolution. Sender-ID fails to recognize the message
broker, and not the message, is the verifiable entity that can be safely
held accountable. Reputation services must consider the MTA, the message
broker, as being the entity to be validated and held accountable.
Sender-ID has created a false impression Mailbox identification is
trustworthy. This places every entity identified using the PRA algorithm
at risk of being blacklisted or filtered, as the recipient does have
expectations the PRA algorithm is trustworthy.
Even if Mail Channel prescription checking was initially attempted by the
provider, the potential for a DoS attack, with the required high overhead,
places this check vulnerable to being removed as a means to preserve vital
mail services. The PRA algorithm offers no means to verify the integrity
of the Mail Channel checks. The PRA algorithm also offers no means to
discover MTAs being shared with other domains. The PRA Mailbox Domain can
be spoofed within the realm of the recipient, as well within the realm of
the sender, but there is no means with PRA identities to locate which MTA
is at fault.
If the PRA domain publishes an "open" list, by appending "?all" as
example, and there are shared MTAs on the outbound path, the PRA identity
offers no means to differentiate between a message originating within the
prescribed Mail Channel from those outside the prescribed Mail Channel, if
submitted to a shared MTA, even if the prescribed Mail Channel checks are
made at the shared MTA. The use of the PRA to assess reputations would be
hazardous, as the PRA identity is untrustworthy.
An alternative illustrated in:
http://www.ietf.org/internet-drafts/draft-otis-marid-mpr-00.txt
Rather than relying upon the PRA RFC2822 Mailbox Domain validated by
anonymous client addresses, an authenticated EHLO domain if validated
offers an accountable identity, as it identifies the message broker. This
can be accomplished without adding a single additional DNS lookup, but
rather by supplanting an address record lookup.
http://www.ietf.org/internet-drafts/draft-ietf-marid-csv-csa-01.txt