John C Klensin wrote:
Sigh. I wasn't explicit enough. Suppose we have
(1) MUA -> (2) Submission-MTA ->
(3) Real-relay ->
(5) Delivery-MTA -> (6) Mailbox or MDA etc.
Oh... yes, I immediately see a terminology problem, whenever
you said "delivery MTA" I thought that you mean the same
thing as an "MDA". But apparently you mean something where
I'd say MX (?)
Before going into the details: could we add some common
definitions for MSA and MDA to 2821bis ? In the (failed)
"last call" for draft-hutzler-spamops that was one of the
objections:
2476(bis) offers definitions for MUA (1) and MSA (2), but
IIRC draft-hutzler had no precise definition for MDA (6).
being a real relay, (3) doesn't have a list of the valid
addresses at (6)
Okay, in the most simple case (3) is a "mailout" behind (2),
the "border MTA" of the sending side (1+2+3).
Or it's some kind of "redistributor" (mailing list), or any
"forwarder, in Dave's mail-arch that would be a "mediator".
Or it's an "open relay". I don't care much about open relays,
but we can neither forbid nor ignore them. Not in 2821bis.
Put differently, if it starts inspecting content, if isn't
a real relay, it is something else.
That could eliminate the "mediator" cases, a "mediator" does
something, e.g. modify the RCPT TO. OTOH the RCPT TO isn't
in the content, it's in the envelope... probably you don't
want to eliminate the "mediator at (3)" case here for this
scenario (?)
Now, let's say we decide to avoid having negative results
(inability to deliver or content-based decision to not
deliver) returned to (2) or (1) by mail messages.
To (1) is impossible, (2) has to do something if it gets a
reject from (3), or a NDN ("bounce") from (3) or (5) or (6).
All we can do is say to (3): "please reject when possible".
Because then it won't hit (1), because the spam was not
really sent via (2), it was sent sent from a zombie (2')
with a forged MAIL FROM (1). Nobody cares what (2') does
if it gets a reject from (3).
At this point we have to add the missing (4), your (3) is
actually (4), and the case "mailout" (1+2+3) doesn't belong
to (4), revised scenario:
| (3) "Mail-out" -> (4) Real-relay ->
Probably we can also eliminate the "open relay" case, (3)
has no business to use an "open relay" (4) if it actually
wants to talk with somebody at or behind (5).
Therefore (4) is more than only a "real relay". You could
still push (4) to the side of (5), maybe (4) is a backup-MX
of (5), and (3) was forced to talk with (4) because (5) was
down or busy.
That leaves two cases: (4) as backup MX, or (4) as mediator.
[back to your (3), now identified as backup MX or mediator]
The transactions (2) -> (3) -> (5) have to be
(2) opens connection to (3)
(3) 220 hi there
(2) EHLO confused.example.com
[...]
(2) RCPT TO:<melvin(_dot_)furd(_at_)bogus(_dot_)domain(_dot_)name>
(3) opens connection to (5)
That's the call-forward-idea: (3) tries to verify that the
RCPT TO is okay _while_ still talking with (2). Bruce pointed
out that this has some interesting timing issues.
For a backup-MX it's impossible while (5) is really down or
busy. For a "mediator" = mailing list it's also impossible.
For a "mediator" = 5.3.6(a) forwarder it's near to impossible.
It could work for a backup-MX if (5) is _not_ down or busy
(ignoring Bruce's timing questions for the moment).
[...]
(3->5) RCPT TO:<melvin(_dot_)furd(_at_)bogus(_dot_)domain(_dot_)name>
(5->3) 550 At least to you I deny knowing anyone named melvin
(3->5) QUIT **
(5->3) 221 sweet dreams **
(3) closes connection **
(3->2) 550 user unknown
(2) QUIT
(3) 221 spammers should all rot
(2) closes connection
** these three steps can occur asynronously from what follows.
I like your example. It shows that "call-forward-verification"
(or whatever the proper name is) is something between tricky
and impossible.
From my POV it also shows that (3) as backup-MX should be very
reluctant to accept mail. How it manages to be reluctant is
out of scope for 2821bis (use some BLs and WLs probably, plus
new protocols or schemes like MTAMARK / CSV / SPF / etc.)
As far as 2821bis is concerned we only have to get the message
out that an MTA in the position of your (3) should be reluctant
to accept mail. In doubt a backup-MX (3) could reject with 4xx
until (5) is up and ready again.
Note that, if (5)'s reasons for rejecting the transmission
involves content, not addresses, (3) would need to get back
an OK from (5) after the RCPT TO, send DATA
[...]
That's even more impossible while still talking with (2). And
it shows that the main line of defense has to be at the border,
in your scenario (3), the defenses at (4) or (5) are too late,
they could only pick "(or drop)".
One difference, the backup-MX (3) could block more radically
than (5), after all (3) is not some kind of spam backdoor, or .
rather it shouldn't be.
Now I suggest to you that this scenario is not going to work,
at least without keeping connections open much longer than
necessary in normal cases
I don't disagree, "call-forward" is tricky at best. But (3)
has many other options, not defined in 2821bis, helping in its
decision to 'accept' or 'reject'.
A very simple solution is "let's not outsource the backup MX,
that's only more trouble".
inserting a second relay at (4) would require the relay at
(3) to maintain an open connection to it, and (2) to maintain
an open connection to (3), while it negotiates with (5).
Oh, here's the missing (4), yes, "forward-verifcation" with
more than one hop is also one of the "more impossible" cases.
Now, what are you proposing that 2821 be redesigned to
"favour"?
(3) or any border-MTA on the receiving side should be reluctant
to accept mail. As soon as they accept it it's too late, later
they can only "return or drop", and with Murpy there will be
errors (either 'return' to innocent bystander => get into BLs,
or drop legit mail => have a chat with your legal department).
[old "accept + return (or drop)" model]
It talks about "drop", but only in the context of protection
against attack. IMO, that is how it should be.
Okay, SMTP is most definitely under attack, all the time today.
The alternative, it seems to me, is to turn the email
environment into one is which there is no expectation of
reliable delivery. And that, again IMO, is the point at
which it is time to abandon SMTP and design something else
instead.
We completely agree (apparently). The "(or drop)" case is too
dangerous, "return blindly" can be also bad (= users start to
fight back), the only chance is "make sure that you know what
you're doing if you accept mail, and otherwise better reject".
Bye, Frank