Technique: Use the RFC2822 From Mailbox Domain to reference a Mail
Channel prescription to refuse non-conforming messages.
Problem as a result of this technique-
If this From Mailbox Domain were applied generally to reference the Mail
Channel prescription, much of the mail would be refused.
Sender-ID response to this issue-
The Purported Responsible Address (PRA) algorithm prioritizes the
headers used to reference the Mail Channel prescription as a means to
reduce the number of messages refused. Many messages will still be
refused even with comprehensive Mail Channel prescription records
however. To enable exceptions, dangerous "open-ended" lists are allowed
in the Mail Channel prescriptions.
Deployment response to this issue-
The use of the PRA Mailbox Domain selection invites a practice of
routinely adding a Resent-From header to the mail message to override
the Mail Channel prescription for problems not generally solved with the
PRA Mailbox Domain selection. This header would be added to ameliorate
problems with mail forwarding, or support issues with customers using
their well-known return address, among others.
PRA defeats the goal of the RFC2822 From being protected.
Sender-ID response to this issue-
Sender-ID assumes differing mail user agents will indicate which header
is being examined and make this header visible to the user, provided the
MUA vendor has a signed contract with Microsoft. Sender-ID also assumes
selection of this displayed header will be the header checked by the
receiving MTA, assuming the MTA vendor also has a signed contract with
Microsoft. The complex level of parsing required may invite security
issues of the display not matching the check and not easily addressed
with diverse implementations.
Alternative solution as illustrated in:
Use of the EHLO domain authenticates the administrative domain
accountable for policies of the sending MTA, and thus provides a more
reliable and less easily spoofed identity without forcing changes on the
mail system. With the PRA algorithm, an MTA could purport being within
the prescribed Mail Channel of millions of Mailbox Domains, while never
being specifically authorized by any such domain. Sender-ID allows
exceptions using syntax like "?all" or "+all" which enables spoofing.
Should use of the Resent-From header become widely used as a deployment
solution, there would be little difference between the identity within
the Resent-From and that of the EHLO domain. Use of the EHLO domain
does ensure the same field is always checked and is also
administratively related to the MTA. This identity selection can happen
without stringent parsing conformance checks or signed contracts.
If each MTA employs authentication operating on behalf of the recipient,
these servers can add or overlay a tag in the RFC2822 From header which
indicates the proximal sending MTA outside the recipient's
administrative realm. This EHLO identity is the entity accountable for
the delivery of the message and is actually the entity being trusted as
a broker with respect to message content. This identity would then be
visible to the end user and thwart spoofing more effectively than
reliance on PRA, especially once deployment solutions are considered. A
typical MTA already knows local Mailbox Domains or inbound Mailbox
Domains relayed. If an MTA receives mail from outside these
administered domains, it can strip and add the RCVD tag for their
From: “[rcvd: mx01.some.domain.com*]” someone
The “*” would indicate successful authentication. This tag would be
applied or reapplied when entering from outside the administrative
domain of the recipient based upon the EHLO domain information and
successful authentication and confirmation of authorization. Such a
practice should not require an IPR license for implementation, nor
require extensive changes to existing SMTP software, nor require
extensive changes in the use of mail. Reputation services will be
needed to exclude most of the abuse, and the EHLO domain is an identity
that can be used for this purpose, unlike the domain selected using the
Refused From Protection? Was this the goal?
To extend protection when there is no reputation service, institutions,
commonly having their Mailbox Domain forged, may wish to request a
restriction or verification as to whether the message is from their
servers with respect to the RFC2822 From Mailbox Domain. This would
assume the institution has control over those able to send from the
prescribed Mail Channel. This is not always the case.
Although refusal protection is not always possible in the general case,
as illustrated by the use of the PRA algorithm, there may be
institutions willing to endure these limitations for specific
sub-domains. To that end, an absolute restriction would be possible by
publishing a PTR list of acceptable EHLO domains for this Mailbox
Domain. This would also be a means to prescribe the Mail Channel with a
single DNS lookup! This list could be published without requesting a
restriction and but assume the MUA will provide some type of indication
of the message's status. If restricted, the institution could not
expect this message to be forwarded through a mailing list without
reliance on other means to verify the Mailbox Domain. This would
provide an institution an exceptionally strong conformance check on the
RFC2822 From Mailbox Domain Mail Channel and, in addition, by making the
EHLO domain visible to the user, would greatly reduce phishing and
spoofing far better than could be achieved by Sender-ID.
Better recipient/sender protection.
Policy enforcement facilitated.
Reputation services enabled.
Stronger identification with less overhead.
No burden on normal use.
No risk of DoS.
No sequential DNS lookups.