From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from orthanc.ca ([208.79.93.154]) by ewsd; Mon Oct 5 13:03:12 -0400 2020 Received: from orthanc.ca (localhost [127.0.0.1]) by orthanc.ca (OpenSMTPD) with ESMTP id 228bc3e3 for <9front@9front.org>; Mon, 5 Oct 2020 10:03:12 -0700 (PDT) From: Lyndon Nerenberg To: 9front@9front.org Subject: Re: [9front] upas/fs: change header filters In-reply-to: References: Comments: In-reply-to ori@eigenstate.org message dated "Sun, 04 Oct 2020 20:13:56 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <96217.1601917392.1@orthanc.ca> Date: Mon, 05 Oct 2020 10:03:12 -0700 Message-ID: <3f41f3975bf6b60b@orthanc.ca> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: SVG engine wrapper dependency layer This last set of changes seems reasonable, but we really do need to pay attention to when and where this sort of header munging takes place. The underlying issue is that there are three distinct email services in play: 1) SMTP relay, and 2) Submission (initial message injection) 3) Final delivery upas predates (2) being carved out as a distinct service. In almost all cases, SMTP relay should *never* touch the headers, other than to add a Received trace header. The submission service (2) should *add* any missing required or defacto-required headers (primarily Message-ID, Date, From), but otherwise leave existing headers intact. By the time you hand off to the local delivery agent (3), the message is in the recipient's hands and all bets are off. To do all of this properly requires significant restructuring of how upas works. Since I personally consider upas a botch from start to finish I'm not willing to put any time into "fixing" it, although others might. I'd rather put the effort into replacing upas outright with something that properly breaks up this functionality, and is more in tune with the current set of email RFCs. --lyndon