bukys(_at_)cs(_dot_)rochester(_dot_)edu wrote:
EXCEPT that it interferes with the everyday common use of relaying via
aliases (with no rewriting of SMTP envelope-from), which means that:
IF my domain starts publishing an RMX record,
THEN mail from my users can no longer reliably be forwarded
without an envelope sender re-write,
SO ALL of my users suddenly can't reach anyone who uses (e.g.)
a .forward file pointing to any RMX-aware MTA, and they have to
send out notes to the effect that "sorry, but I can't reach you
any more unless you adopt something new" but, well, those notes
can't reach their intended recipients either.
<claps loudly>
That's be the best objection to RMX I've seen yet. Detailed,
quantitative, iterates over possible scenarios, and totally lacking in
misunderstanding of the proposal.
While it may be a "good idea" to abolish aliases and .forward files,
actually doing it is a traumatic transition, and it is one that is
NOT under the control of the RMX publisher or the RMX-obeying MTA, but
depends on the cooperation of the vast unwashed body of RMX-non-adopters.
I agree.
Isn't this a serious impediment at least short-term?
It would appear, so long as envelope sender re-writing is not done.
Now let's look at the problems with the current use of .forward
files. You receive a message from an MTA in example.com, with the
envelope & body "from" being example-2.com.
Q1: Is it spam?
A1: You don't know.
Q2: Is it non-spam?
A2: You don't know.
Q3: Is the user at example-2.com permitted to use the MTA in example.com?
A3: By implication, it would appear so.
Q4: How can you tell this situation from open relays, "owned"
machines, etc?
A4: You can't.
In keeping with the charter of this group, I will now discuss
consent. Within the context of SMTP, RMX allows the originating
domain and MTA do explicitely publish their consentual relationship.
In this case, if envelope sender re-writing is done, we can use RMX to
establish that the domain 'example.com' consented to have that
particular MTA send an email with a body "from" of 'example-2.com'.
In this case, the answers to questions 1 and 2 stay the same. The
answer to question 3 now becomes an explicit "yes, consent exists."
The answer to question 4 becomes "the originating MTA is not an open
relay or 'owned' machine, unless the attacker has additionally taken
over the DNS records."
So the solution to .forward files, is to have the forwarding MTA
explicitely declare it's consent to forwarding messages for another
domain.
In contrast, the simple act of forwarding messages tells you
nothing about consent, other than that forwarding is occuring.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg