ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Curious, with this now being associated to emailcore, should list name change?

2020-07-21 11:14:25
Dilyan,

It is a bit more than "questions the usefulness of".  Please see
the explanation in RFC 6648.  I'll let others respond to the
DKIM header suggestion.

best,
   john



--On Tuesday, 21 July, 2020 07:37 +0000 Dilyan Palauzov
<Dilyan(_dot_)Palauzov(_at_)aegee(_dot_)org> wrote:

Hello,

my reading is that this thread questions the usefulness of the
X- headers, spread over the internet.  The message below
contains:

Received: from localhost (localhost [127.0.0.1])
  by ietfa.amsl.com (Postfix) with ESMTP id 6B1623A08A2
  for <ietf-smtp(_at_)ietfa(_dot_)amsl(_dot_)com>; Sun, 19 Jul 2020 11:20:01
-0700 (PDT)
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
  tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
  URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
  by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port
10024)
  with ESMTP id g-1uauMMW0n1 for <ietf-smtp(_at_)ietfa(_dot_)amsl(_dot_)com>;
  Sun, 19 Jul 2020 11:20:00 -0700 (PDT)

X-headers are useful to insert information about what and why
intermediate hosts think about the spam probability of a
message.  They can prevent manual communications on this.
Unfortunately the above X-Spam headers do not include
information about which host added that headers.

As useless mail headers do make emails heavier, I am in favour
of removing DKIM-Signature headers, that are known to be
broken, e.g. because the current host has modified (and
resubmitted) the message.  Or if not completely removed, then
at least shortened by substituting to "b=invalided" or
"b=invalidated-on-host-A.B".  The latter is more useful
than just having an invalid dkim-signature. (or removing the
b=/bh= tags and putting instead a new tag containing the host
where the signature was broken, which not really an
Authenticated Receiver Chain, and does make the massage
shorter).

Greetings
   Dilyan

----- Message from John C Klensin <john-ietf(_at_)jck(_dot_)com> ---------
    Date: Sun, 19 Jul 2020 14:19:52 -0400
    From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
Subject: Re: [ietf-smtp] Curious, with this now being
associated to emailcore, should list name change?
      To: Arnt Gulbrandsen <arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>,
ietf-smtp(_at_)ietf(_dot_)org


--On Sunday, July 19, 2020 18:57 +0200 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:

On Sunday 19 July 2020 16:43:57 CEST, John Levine wrote:
Adding new names to the registry requires expert review and
I expect the expert would be sceptical of proposed names
that were a lot longer than the existing ones. I don't see
any over 35 characters which seems reasonable.

My personal server currently has 559 field names longer than
that. The 25 worst offenders:

 X-Offlineimap-X706593913-6d61646475636b2e6e6574-494e424f582
 e6 47261667473
 X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Informa
 ti on
 X-Ms-Exchange-Crosstenant-Originalattributedtenantconnectin
 gip
 X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Spamche
 ck
 X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-Information
 Staticcontent1_Header1_F731d3dc-Fd31-4161-Ad91-1083ba56853f
 Staticcontent2_Header2_F731d3dc-Fd31-4161-Ad91-1083ba56853f
 X-Mimedefang-Relay-15b21d6f94afe8e768c451e09085c007047aae7e
 X-Mimedefang-Relay-89167b66339720c294cd81d33948afd6488b114f
 X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-Spamcheck
 X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-Spamscore
...

<Sounds of virtual vomiting>

It is interesting that every one of these starts in "X-".

Presumably, by putting "X-" in front of their field names, the
perpetrators believe that they are exempt, not only from the
registry and its rules, but any rules at all.  That would be
my concern here: maybe it would be worth getting a stake in
the ground that long, or very, long field names are a bad idea
and/or a bigger stake in the ground about "X-" prefixes.
Unless we accompany it with a really strong, clear, and
persuasive discussion of the problems it causes, which might
help, I wonder if the offenders would pay any attention at
all?

The rest of this note is more or less a rejection of the
notion that because there are no protocol police, we can't do
anything (or anything useful), with some questions,
speculation, and examples about what might be done.  I
haven't made my mind up yet whether doing something would be
worthwhile; I just want to get past the idea of
impossibility.  Those who aren't interested in that
speculation, or who would prefer to leave it for the BOF or
WG, should probably stop reading here.

    -----

Perhaps more important than what the perpetrators do today,
user-defined-fields using "X-" were deprecated by RFC 2822
nineteen years ago, with that message reinforced by RFC 6648
more than eight years ago.  Much as, on principle, I hate the
idea of intermediate MTAs messing with non-trace headers,
would relays or anti-malware systems consider just deleting
the things as potentially-dangerous noise?  Do they check now
for embedded nastiness in header field data as well as body
parts?   Should we be encouraging Submission Servers to
discard them (there is enough flexibility in RFC 6409 to
allow that and, given that such servers are not supposed to
inject non-conforming stuff into the public Internet SMTP
system, our banning them would make a Submission Server that
let them pass non-conforming)? How about the interface
between the mailstore and receiving MUAs: could these things
be tossed out there?  Would any of that help and would our
saying something even stronger than what RFC 6648 says (it
mostly applies to new header field names, not older ones, but
I'd guess the vast majority of these were invented after June
2012 and almost certainly after April 2001) be useful?  Even
if the fields are, as John Levine points out, probably just
clueless rather than spammy, it is probably not a wonderful
idea to encourage noise in mail headers, those whose intent
is malicious are likely to uncover opportunities sooner or
later, and perhaps (just perhaps) people getting a little
proactive now might prevent or head off future attacks.

There aren't any protocol police, but there are certainly
implementers who can decide, especially if we make a strong
recommendation in that area to help them defend against angry
folks who produce this stuff, to not tolerate this particular
type of nonsense any more.  Should we register a
"Deleted-NonConforming-Headers:" field, treat it as an
optional trace field with "By" and timestamp information, and
then have the rest of the value showing either the number of
such fields tossed out or the header field names (but not
values)?

Would the suggestion that started this thread be consistent
with an applicability statement, either in 2822bis or the
separate document for which draft-klensin-email-core-as-00 is
a placeholder, that said something like "Header field names
starting in 'X-' or longer than NNN are prohibited unless they
are legacy registrations in the IANA registry.  They MUST NOT
be transmitted in messages and Submission Servers and other
systems encountering them MAY, and in most cases SHOULD,
delete them"?

At a whole different level, at least several of these examples
appear to be loop detection tools.  Should we be taking
another look at the loop detection support machinery in 5321
(IIR, although there have been some clarifications and
details, that machinery is not significantly changed since
RFC 821) either as part of the proposed emailcore effort or
separately?

Again, I don't yet have an opinion as to whether we should
take those, or other, actions on this topic.  I'm just
wondering what actions might be effective if we did decide to
take them.

best,
   john


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp


----- End message from John C Klensin <john-ietf(_at_)jck(_dot_)com> -----



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp




_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>