Re: [ietf-smtp] Curious, with this now being associated to emailcore, sh

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-494e424f582e6
> > 47261667473
> >  X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Informati
> > on
> >  X-Ms-Exchange-Crosstenant-Originalattributedtenantconnectingip
> >  X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Spamcheck
> >  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