|
Re: Additional Changes for RFC2821 MAIL FROM checking
2004-04-01 22:53:43
John Leslie wrote:
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.)
I am not referring to the cases your mentioned, rather to all of the use
cases in #3 below such as alumni forwarders, some mailing lists, n
newspapers, greeting cards, etc. All of those would be affected.
In many of these cases, it would be impossible to establish a
relationship with every single sender or receiver, so some kind of
solution would be needed.
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.
Forwarders on the receiver's side would do that. For example, when you
send email to "acm.org" address, it will forward it further with the
RFC2821 MAIL FROM unchanged. Such site would probably not have enough
resources to handle all the bounces themselves, and it would want to
relay the bounces back to the sender. The senders in this case having no
relationships with the forwarder would not list its IPs in DNS. Forcing
the receiver's to do that is also hard, so the least cost solution in
this case would be rewriting.
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.)
These "middleman" forwarders are the ones I am referring to. Examples of
these would be alumni sites where it might not be possible to make
arrangements with the sender or receiver especially when they are simply
end-users which have no control over their DNS. We also need to take
into account the fact that many of these services are run at very little
cost, and any changes would increase their costs possibly forcing them
to close.
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.)
Well, SpamAssassin does checking after the MTA level in many cases and
so do many other filters. So I am not sure if it is wise to ignore them.
On the other hand, we can just say that this type of check is needed
only on the MTA level, and if you want to do it at MUA or filtering
level, you are on your own.
So this would basically come down to the fact that RFC2821 MAIL FROM
checking if done on the filtering or MUA level is not any different from
the HELO-only checking, which is all we need to picking identities. We
can discuss the filtering implications once the identity has been picked.
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.
We might need to look over RFC2476 in detail about rewriting of bounce
addresses. From a glance it seems that the MSA is not allowed to rewrite
RFC2821 MAIL FROM and only has an option of rejecting invalid ones. In
that case, MAIL FROM checking would either need change in the MSA and
the SUBMIT spec to allow MAIL FROM rewriting, OR leave it unchanged and
have the MSA bounce the mail back to the user forcing him to use a valid
RFC2821 MAIL FROM address. In the second case, this would increase the
configuration complexity for the end-user by requiring them to enter a
valid MAIL FROM. Since many mail clients generate the MAIL FROM based on
the "From" or "Sender" address, this might require MUA changes.
Maybe even a reference to
(http://www.ietf.org/internet-drafts/draft-hall-email-srv-00.txt) might
be useful here for configuring MUAs. So there might be some MUA changes
after all.
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.
I addressed the rewriting issue above. Regarding MTAs serving more than
one domain, there would be higher complexity configuring MAIL FROM
checking since more domains are involved than HELO where only one domain
is involved. But I would venture to say that handling bounce addresses
in HELO-only case would probably not be relevant to the configuration
complexity of MARID. While there might be higher complexity with
checking these, it will not be directly relevant to the configuration
complexity of HELO-only checking.
However, in regards to keeping information in sync between DNS and
MTA configuration it is probably the same as HELO checking.
Agreed.
I am actually more hesitant about this now, see my comments below (more
domains than HELO case).
There is also an issue with the need to change configuration
whenever an MTA changes IPs.
The same as for HELO-only checking, IMHO.
It is a bit more complex than HELO-only checking. In HELO only checking,
only the domain that is used in the HELO argument needs to be updated,
while the MTA may relay email for multiple domains within one SMTP
transaction. With MAIL FROM checking, every domain used in the bounce
address needs to be updated, which is more updates than HELO. Of course
with some form of redirection or reference mechanism like the one in
SPF, that might be less of a problem, but there are still more domains
that have records.
I would add along the same lines, that every domain that is used in MAIL
FROM needs initially to be configured with MARID records, while with
HELO only one domain does. This would increase the configuration
complexity somewhat.
I would also add that as per RFC2821, section 4.1.1.1, the HELO argument
is a FQDN of the MTA which to me seems to need to match the rDNS entry.
If I am reading it correctly, that means that the MTA cannot use the TLD
in the HELO argument unless its rDNS record resolves to that TLD. That
means that for HELO checking, the MARID records need to appear in the
forward DNS for the FQDN which might not be a TLD, but could be a
subdomain. This would also increase the complexity of HELO checking
somewhat over the MAIL FROM checking. But then again we are only talking
about one domain.
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.)
I agree with this as well, just not sure how painful it would be.
Forwarders I addressed with my comments all the way above.
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.
So unless a user has access to an MSA and a valid bounce address to go
along with it (or one assigned by the MSA), they will not be able to
send email to most domains. I am not sure where we disagree.
Another point, as per RFC2476 as it is currently defined, I don't see
how the MSA can rewrite or supply a valid RFC2821 bounce address.
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.
That's what I was saying.
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.)
I am not sure what you mean here - can you elaborate on how a per-user
basis authorization would work? DNS might not be dynamic enough for that.
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.
After reading the SUBMIT RFC, I don't see how the MSA can do that other
than rejecting the message with an error code and a suggested bounce
address in the error message.
4) Needed infrastructure changes.
No essential change from the HELO-only case.
I am still not sure about the question - whose infrastructure are we
talking about? If it is the entire Internet, than MAIL FROM would have
implications in regards to store-and-forward functionality of SMTP.
5) Considerations for use in both IPv4 and IPv6.
No essential change from the HELO-only case.
Agreed.
Yakov
|
|