This is another attempt at a semantics. Pete Resnick posted his
30% solution, trying to simplify SPF functionality. This proposal ignores
SPF and attempts a zero-based solution.
My debt to Dave Crocker should be obvious; but I have no hope to stay
in sync with him for long. I tack on reputation services, because it
simplifies so many things; and enables adoption of entirely useful MARID
services without programming complexity.
In brief, I propose that the HELO string shall always be checked, and
that a trusted reputation service shall be used to give an opinion of the
trustworthyness of the domain advertising MARID records. If that domain
advertises a sufficient level of MARID compliance, and the reputation
service agrees, no further checking is needed.
====
The MARID RR record shall be placed at the subdomain level of the
HELO/EHLO string, and may be placed at other subdomain levels as needed
to authorize particular MAIL-FROM domains.
THE MARID RR shall return a MARID level as <integer>.<integer> (exact
meanings to be defined in later documents) and a text string listing
suggested reputation services which will corroborate compliance with this
standard. This text string shall allow for keyword-encoded future
extensions to the standard.
At that same subdomain level, there shall be a "_HELO" subdomain to
hold records similar to PTR records which shall be queried by an encoding
of an IP address and shall return values distinguishing:
- known-good IP addresses;
- believed-good IP addresses;
- IP addresses unknown; and
- IP addresses believed bad.
"Known-good" shall mean that there is known to be a MTA at that IP
address under the control of the management of this domain; that there is
policy in place to enforce the conditions of the MARID level quoted; that
reports of abuse of that policy are welcomed at <abuse(_at_)subdomain>; and that
action on violations of the policy will be taken within <blank> business
days.
"Believed-good" shall mean that the management has no reason to distrust
an MTA at that address, and recommends they be trusted; and that reports of
abuse are welcomed as above.
"Believed-bad" shall mean that the management recommends not trusting
such MTAs, and may choose to ignore reports of abuse.
There shall also be a "_MAILFROM" subdomain to hold similar records
relating to policy on the use of email addresses with that subdomain on the
right-hand side of the "@" sign.
"Known-good" shall mean that the MTA at that IP address is known to
enforce a policy that prohibits the use of misleading MAIL-FROM addresses,
and that reports of abuse of that policy are welcomed at <abuse(_at_)domain>.
"Believed-good" shall mean that MTAs at those IP addresses are believed
to support the policy, but not known to enforce it; and that reports of
abuse are welcomed at <abuse(_at_)domain>.
"Believed-bad" shall mean that management recommends against trusting
MAIL-FROM addresses coming from MTAs at those IP addresses.
In future versions of this standard, there will likely be other
subdomains defined.
====
A MARID-compliant MTA, at the outset of each SMTP session, shall do a
DNS lookup for a MARID record for the exact domain-name contained in the
HELO/EHLO command.
The DNS response (if any) shall contain an indication of MARID level
supported and a list of suggested reputation services, as well as text
field(s) available for keyword-defined expansions.
Ideally, the DNS response will contain the IP address matching the SMTP
sender, indicating that the SMTP sender is authorized, or a complete set
of authorized IP addresses (indicating that the IP address of the SMTP
sender is not authorized). If not, a separate lookup will be required, to
be accomplished by prepending an encoding of the actual IP address to the
HELO/EHLO string, and the result of that lookup will show whether the
IP address represents an MTA that is 1) known-good, 2) believed-good,
3) believed-bad, or 4) unknown.
The receiving MTA shall query whatever reputation service it chooses
with the HELO/EHLO string and the list of suggested reputation services
(if any was received). It is suggested, but not required, that whenever
one of the reputation services suggested is among its own list of trusted
reputation services, the receiving MTA should query that service.
If no DNS response is received within a reasonable timeout, the
receiving MTA MAY give a temporary error noting that fact; but it SHOULD
query its preferred reputation service with just the HELO/EHLO string if
the lack of response persists for more than a few hours.
If the DNS response gives a MARID level equal to or greater than the
MARID level adopted as policy by the receiving MTA's management, and the
IP address is found to be known-good, and the reputation service returns a
"fully trusted" response, that fact should be noted in a prepended header
and no further MARID processing is appropriate.
Otherwise, the receiving MTA SHOULD proceed to MAIL-FROM processing.
MAIL-FROM processing MAY be deferred until after RCPT command(s) are
received, and MAY be omitted entirely if all RCPT strings designate
receivers to which delivery can by made or refused without any need for
processing which is not accomplished before the end of the DATA command
(including the need to forward to another MTA).
The receiving MTA shall extract an email address from the MAIL-FROM
string, using the usual syntax rules, and extract from that the right-hand
side as a domain. A MARID DNS query shall be done using that domain string;
and if no MARID RR is returned, successive subdomain strings shall be
stripped from the left and DNS queries shall be done on the superdomain
until a MARID RR is returned or the string is exhausted. (Negative
responses for the top-level domains should be cached for the appropriate
Time-To-Live periods and need not be repeated.)
If a MARID RR is returned, and its MARID level shows support for
MAIL-FROM authorization, a DNS query shall be done by prepending an
encoding of the actual IP address to the domain-name which returned a
MARID RR, and the result of that lookup will show whether the IP address
represents an MTA that is 1) known-good, 2) believed-good, 3) believed-bad,
or 4) unknown. If this lookup fails, the receiving MTA MAY return a
temporary error; otherwise it SHOULD treat the situation as if an "unknown"
status was returned.
If the IP address is shown as known-good, that fact shall be noted in
a prepended header, and MARID processing shall be complete, subject to
change in a later version of this standard to add testing of RFC2822
headers.
If the IP address is shown as believed-bad, the receiving MTA shall
return a permanent error before accepting a DATA command. If the IP address
is shown as unknown, the receiving MTA MAY return an error as a local
option; otherwise the receiving MTA SHOULD note this fact in a prepended
header and substitute a MAIL-FROM string known to not annoy innocent
parties if the email is later forwarded to another MTA which generates a
bounce message.
====
That's it: fire away!
--
John Leslie <john(_at_)jlc(_dot_)net>