(Sorry -- messed up EMAILCORE mailing list address -- please ignore
earlier copy and respond, if at all, to this one)
(EMAILCORE copied, subject line changed)
--On Friday, November 1, 2024 15:33 -0400 Michael StJohns
<mstjohns=40comcast.net@xxxxxxxxxxxxxx> wrote:
>...
>> And most importantly, it is sender-push rather than
>> recipient-pull, so you have no control over what you receive.
>
> This triggered a vague memory and led to me taking a quick look at
> 5321 and the draft. Section E.1 talks about the TURN command
> which does something that is not exactly sender-push or
> recipient-pull. The command has been deprecated at least since
> 2001 - but in a somewhat wishy-washy way:
>
>> This command, described in RFC 821, raises important security
>> issues since, in the absence of strong authentication of the
>> host requesting that the client and server switch roles, it
>> can easily be used to divert mail from its correct
>> destination. Its use is deprecated; SMTP systems SHOULD NOT
>> use it unless the server can authenticate the client.
FWIW, that test was present in RFC 2821, so is more than 23 years old.
> In this new version of the document - perhaps we make this more
> directive? E.g. either prohibit it (obsolete it) entirely, or do
> a MUST be rejected unless provided inside a client-cert
> authenticated TLS session or be more specific about what
> "authenticate the client" means?
I can't remember the WG discussing this at all this time around. Wrt
the first suggestion above, there is, of course, some question about
how the relevant server can reliably know that sort of authenticated
TLS session is involved, especially if one cares about the hop-by-hop
model. One might not in this case... but then I question whether
encryption is necessary especially if it does not provide significant
compression as a useful side effect.
My instinct (but I've only thought about this for a few minutes)
would be to look toward SMTP AUTH (Cf RFC 4954) and SASL rather than
TLS.
Ticket #108 created for discussion at the EMAILCORE meeting next
week. Please join us if possible (there might be a second slot
announced so, if you can get to one and not the other, please let the
chairs know).
> I'm now kind of curious how many SMTP servers still support TURN.
No clue, but probably not hard to add back in if needed (see below).
> ps - I believe at one point the email system at Mc Murdo station
> used TURN as its satellite connectivity at the time was very
> intermittent. But that would have been pre Iridium.
As I said, I don't believe EMAILCORE discussed this at all and am not
positive it came up when the document that became RFC 5321 was
reviewed (although I could be wrong about either or both). But at
least some of the reason we've been reluctant to do away with TURN
entirely rather than making SHOULD NOT statements parallel that
example. In extremely poor or intermittent connectively situations
-- maybe the next one will be a client on the moon or Mars, relaying
through a fast-moving (rather than Lunar-stationary or
Mars-stationary) satellite -- TURN, especially in combination with
PIPELINING, might have some of the same advantages for which it was
originally included in the SMTP protocol and might have been used as
you describe above.
If any of that reasoning applies, then, for reasons very similar to
those that have been under discussion for STARTTLS, we should perhaps
be thinking about a discussion in the Applicability Statement with,
at most, a forward pointer from the appendix in rfc5321bis (such a
pointer is more easily justified for TURN than for STARTTLS because
TURN is part of SMTP).
Should we decide to say more about TURN (other than completely
prohibiting it), we should also review whether, we should require its
announcement in EHLO in parallel with EXPN (see rfc5321bis Section
3.5.2).
Of course and again if we are not going to prohibit it entirely, a
completely different way to handle the issues would be to reach out
to the DTN RG, the IURC (Internet Under Rotten Conditions) WG or RG I
periodically wish for, and any interplanetary folks who might be
interested, and plan some future document that would explore the
issues and mechanisms with TURN in depth and update rfc5321bis, RFC
4954, and other documents as needed for that particular set of cases.
If only because of my desire to get rfc5321bis and the EMAILCORE WG
wrapped up without inventing new ways to get bogged down, that seems
like the more attractive approach.
john
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
