Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
John Leslie wrote:
Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
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"...
I am not referring to the cases you 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.
I think that, except for alumni forwarders, these are adequately
discussed elsewhere.
I am not personally familiar with alumni forwarders, except those
that allow you to appear to have a local mailbox at alumni.school.
I don't see a problem with those. Could someone explain how the ones
which would break actually function?
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.
Munging would handle this just fine. (I do believe that forwarding
with _no_ changes to RFC2821 MAIL FROM should be discouraged.)
The senders in this case having no relationships with the forwarder
would not list its IPs in DNS.
I assume Yakov means the sending domain of the bounce messages.
Forcing the receiver's to do that is also hard, so the least cost
solution in this case would be rewriting.
I believe Yakov is recommending that the "acm.org"-type forwarders
rewrite the RFC2821 MAIL FROM when relaying the bounce messages back
to the address which forwarded through them. I almost agree.
However, we must remember that most if not all of these bounce
messages will arrive with empty RFC2821 MAIL FROM, which wouldn't
present any problem because the originator's MTA would then verify
against the HELO, which is the acm.org MTA.
(It is certainly appropriate to note this case among necessary
changes to forwarding MTAs which are neither outbound nor inbound.)
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.
I don't deny the possibility; however without such changes these
sites seem all too easy for spammers, etc., to exploit. The changes
seem fairly minor -- and I have no doubt open-source software will
be available to handle them.
2) Configuration complexity.
...
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.
Agreed.
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.
Various MTAs now check for this; so we shouldn't break it.
3) Current use cases that will no longer be viable.
...
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.
Hopefully we don't. I'm just more careful to state _exactly_ what
I mean.
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.
...
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.
It's really not a issue of dynamic DNS: it's a matter of specifying
a user account as part of a DNS query, and the DNS reply giving info
specific to that user account. I expect there to be demand for such
a feature, though it could be implemented by user-specific subdomains.
--
John Leslie <john(_at_)jlc(_dot_)net>