Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
1) Amount of change in software components (MDA, MTA, MUA, DNS servers,
DNS resolvers).
MAIL FROM checking would require changes to support some form of
rewriting or aliasing if the message is forwarded with the same
bounce address,
This is not actually true, except in the so-called "general case",
which is actually fairly rare. (Isn't English wonderful! ;^)
The actually common cases of forwarding follow an "outbound" path,
where emails travel from MTA to MTA for policy reasons until one of
them actually forwards based on MX records; then follow an "inbound"
path, where emails travel from MTA to MTA for firewalling reasons or
for "backup MX" purposes.
This structure need not ever rewrite bounce addresses.
The sending domain simply includes all "outbound" MTAs in the set
of known-good MTAs; and the receiving domain simply ensures that the
authorization DNS records are checked on its first MTA, while the
rest of their MTAs trust what comes from that first MTA. Thus the
bounce address need never change.
(Backup MX might even become useful again, under that scenario.)
and an ability to relay the bounce messages back to the sender
(unless each site has its own bounce address).
If someone actually wants to set up an "open" relay, not listed
for the sending domain, there's nothing to stop them from munging
the bounce address so that it comes back to them (which would pass
any MARID checks), and is then forwarded to the original bounce.
This will raise the issue of spammers guessing the bounce format
and using it to pass along spam, and there are proposals that
address it.
Yes, spammers _could_ fake the munging, but I believe that's
easy enough to control; and only relay MTAs unassociated with
either sending or receiving domains would need to consider that.
(Any such middleman that could arrange to be "trusted" by the
receiving domain wouldn't need to do this trick at all.)
Of course the more complex the rewriting scheme gets, the more
changes will be required to implement it.
I see no reason for us to worry about any rewriting scheme.
Any changes one would require are local to the MTA that does the
rewriting.
Filtering software past the initial MTA including the MUA (like
in CID) would need to start parsing "Received" headers and check
them against the "Return-Path" header, if MARID checking is
desired on that layer.
I don't believe that's necessary at all (for RFC2821 MAIL FROM
checking, which is all I'm discussing). If you're talking the
final receiving MUA, whether it chooses to parse headers is an
entirely local decision, not at all necessary to accomplish
verification of bounce addresses.
(Which is not to deny that people may write MUA filtering
programs which do all that: but they are fundamentally beyond our
scope. We certainly will not recommend that as the appropriate
way to do MARID checking.)
I don't see any changes in MUAs or MDAs, or MSAs, other than the
need to make sure that the bounce address is configured properly
on the sender's side.
I expect we will recommend that the sending domain's MSA perform
checking and rewriting as recommended by RFC2476, to ensure that
what it passes on as the RFC2821 MAIL FROM will in fact pass the
expected MARID checks. This burden does not seem heavy, but of
course the originating MUA could easily be configured to always
send a known-authorized MAIL FROM to its MSA.
2) Configuration complexity.
For MAIL FROM checking, the configuration complexity is higher since
MTAs must be able to check and rewrite bounce addresses.
I disagree. The rewrite is unnecessary except for "open" relay MTAs.
Some MTAs, but not all, would need software to check DNS records.
(Also, please don't forget Yakov's note about MTAs serving more
than one domain: for these checking HELO only would require more
complexity to verify bounce addresses than checking RFC2821 MAIL FROM
directly.
However, in regards to keeping information in sync between DNS and
MTA configuration it is probably the same as HELO checking.
Agreed.
There is also an issue with the need to change configuration
whenever an MTA changes IPs.
The same as for HELO-only checking, IMHO.
3) Current use cases that will no longer be viable.
For RFC 2821 MAIL FROM checking, forwarders, mailing lists, greeting
card sites, newspaper "Send copy to friend" sites, etc. would not be
allowed unless their own bounce address is used or a rewriting mechanism
is utilized.
Forwarders are a somewhat different case, already discussed.
Mailing-lists already supply their own RFC2821 MAIL FROM, AFAIK.
Greeting Card, newspaper and other "Send copy to friend" sites
clearly SHOULD supply their own RFC2821 MAIL FROM. If not, rejection
at the first receiving MTA is the appropriate result.
(In other words, I agree that if there are any remaining mailing-
lists, greeting-card, send-copy-to-friend, or similar sites, full
MARID checking would break them; and I think that's a good thing.)
Mobile users will not be able to send email unless they used an MSA
they have access to or their own domain while listing the IP
dynamically in DNS.
This is not quite right. Mobile users which are denied access to
a MSA which will supply an authorized RFC2821 bounce address will
probably be prevented from sending email to most receiving domains.
Barring bureaucratic stupidity, market forces should fix that
quickly.
Users will not be able to relay email through a specific host with
their bounce address on a different system unless a rewriting scheme
is used.
I'm not sure I understand Yakov here. If he's saying, e.g., that
users will not be able to send through their work MTA using their
home email address (or vice-versa) as the RFC2821 MAIL FROM address,
I must agree that that will often be true.
If, OTOH, we adopt semantics that allow a domain to specify
authorization of MTAs on a per-user basis, this problem _could_
disappear. (I'm not saying it necessarily will; nor am I saying
it's a bad thing to break this feature: we're not talking about
the receiving-user-visible RFC2822 FROM here -- we're talking
about the address to receive bounces, which probably _should_
be the same place the message is sent from, since that will
usually receive any error message while the sending-user is
available to take corrective action.)
This would mean that someone who wants to send a personal email
via his business MTA would need a bounce address associated with
the business domain unless the MSA is rewriting his bounce address.
Note that if the MSA automatically supplies a known-valid
bounce address, the sending-user will probably never notice,
because nothing will break.
4) Needed infrastructure changes.
No essential change from the HELO-only case.
5) Considerations for use in both IPv4 and IPv6.
No essential change from the HELO-only case.
--
John Leslie <john(_at_)jlc(_dot_)net>