From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.2 required=3.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=ham autolearn_force=no version=3.4.6 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 0CEF11F626; Fri, 17 Feb 2023 10:28:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=80x24.org; s=selector1; t=1676629709; bh=VNmHq/ricgtXpR+Z+FYFbqao7mGzt78b4+NIvPxKIJY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GvMsoxLycPuOWsk7UlHmwgs0zt/GOE3eEdgY21TOS/9YeYui/U94FTeil/Ngeck4y PG3cXbE/k6OPVkHiwupbrhpegRYdMEvR/4zY/X4IncVFAKHhSdkqdtTwhTvD71zXpo YpTXQmzdyW5G64KhUdrkTi4R9UabVNvf4WQz8chA= Date: Fri, 17 Feb 2023 10:28:28 +0000 From: Eric Wong To: Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= Cc: meta@public-inbox.org Subject: Re: Bug related to (maybe?) / in Message-Id Message-ID: <20230217102828.M907338@dcvr> References: <20230216210546.eo73kyzvtzaxwxko@pengutronix.de> <20230216213628.M187845@dcvr> <20230217085255.xcsaoozloz2yuxil@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230217085255.xcsaoozloz2yuxil@pengutronix.de> List-Id: Uwe Kleine-König wrote: > Hello Eric, > > first of all: Thanks for your quick answer. No problem. I've been stuck on coderepo indexing stuff and needed the distraction :< > Playing around with slashes got my admin and me on the right trail: > https://httpd.apache.org/docs/current/mod/core.html#allowencodedslashes > > We set that to "On" and now it (mostly) works. Maybe it's worth adding > this hint to the documentation even though apache isn't the most > recommended setup? Maybe other servers have a similar security setting? Thanks for figuring that out. Perhaps a note in Documentation/public-inbox.cgi.pod suffices (patch welcome :). > I wrote "mostly" because > > https://lore.ptxdist.org/ptxdist/Y+07h0l%2FzJJAgs9s@falbala.internal.home.lespocky.de/ > https://lore.ptxdist.org/ptxdist/Y+07h0l%2FzJJAgs9s@falbala.internal.home.lespocky.de > https://lore.ptxdist.org/ptxdist/Y+07h0l/zJJAgs9s@falbala.internal.home.lespocky.de/ > > work as expected; > > https://lore.ptxdist.org/ptxdist/Y+07h0l/zJJAgs9s@falbala.internal.home.lespocky.de > > however does not, that yields a short "Not Found". Most importantly, public-inbox itself only generates the first URL, right? (`%2F' and trailing `/') > With the patch applied the logged stuff for these URLs is mostly > identical. REMOTE_PORT differs which is expected. Otherwise only > PATH_INFO, PATH_TRANSLATED and REQUEST_URI differ. They are > respectively: Actually, only REQUEST_URI matters for mail retrieval URLs, > "REQUEST_URI" => "/ptxdist/Y+07h0l%2FzJJAgs9s\@falbala.internal.home.lespocky.de/", > "REQUEST_URI" => "/ptxdist/Y+07h0l%2FzJJAgs9s\@falbala.internal.home.lespocky.de", > "REQUEST_URI" => "/ptxdist/Y+07h0l/zJJAgs9s\@falbala.internal.home.lespocky.de/", I'm pleasantly surprised the 3rd case works, actually :> I do hope we're not generating those URLs on our own. > "REQUEST_URI" => "/ptxdist/Y+07h0l/zJJAgs9s\@falbala.internal.home.lespocky.de", > . Not sure making the last URL work is easily possible (and worth the > effort)? If a Message-Id ends in "/T" or similar the result will always > be ambigous? I think the last case is fixable and should be fixed. It's reasonable a user unfamiliar w/o URL encoding knowledge would paste `/' w/o encoding it to `%2F', first > One thing I just noticed is: > > $ curl https://lore.ptxdist.org/ptxdist/Y+07h0l/zJJAgs9s@falbala.internal.home.lespocky.de/T > Redirecting to https://lore.ptxdist.org/ptxdist/Y+07h0l/zJJAgs9s@falbala.internal.home.lespocky.de/T > > which makes Firefox say: "The page isn’t redirecting properly". It works > fine with the / replaced by %2F: > > $ curl https://lore.ptxdist.org/ptxdist/Y+07h0l%2fzJJAgs9s@falbala.internal.home.lespocky.de/T > Redirecting to https://lore.ptxdist.org/ptxdist/Y+07h0l%2fzJJAgs9s@falbala.internal.home.lespocky.de/T/#u Yeah, that's another case that should work. I don't really like the current giant if/elsif block of route possibilities in lib/PublicInbox/WWW.pm but have some ideas on how to improve it... But a lot on my plate already and way overdue for another release :< It's a tragedy that mutt changed their default Message-ID format :< Newer versions allow overriding $message_id_format in muttrc, but mutt 2.0.5 in Debian 11 won't have it. Fwiw, I run mutt on several machines/arches/OSes, getting them all to the same new version of mutt will take many years and I don't want compile + keep numerous binaries up-to-date in the mean time. I also use msmtp and distribute my muttrc + ~/bin to all of them, so I wrote this msmtp wrapper which is mutt-version-agnostic: $ cat $HOME/bin/msmtp-msgid eval 'exec perl -w -S $0 ${1+"$@"}' if 0; # running under some shell # in muttrc: # set sendmail = msmtp-msgid use v5.12; my ($hdr, $bdy) = split(/\n\n/, do { local $/; }, 2); if ($hdr !~ /^Message-ID:\s*<\d{14}\b/aims) { my $h; if ($hdr =~ /^Message-ID:[^@]+\@([^>]+)>/ims) { $h = $1; } else { require Sys::Hostname; $h = Sys::Hostname::hostname(); } require POSIX; require Time::HiRes; my ($time, $msec) = Time::HiRes::gettimeofday(); my $msgid = POSIX::strftime("%Y%m%d%H%M%S.M$msec", gmtime($time)); $hdr =~ s/^Message-ID:[^\n]+/Message-ID: <$msgid\@$h>/msi; } my $pid = open(my $fh, '|-', 'msmtp', @ARGV) // die "popen: $!"; print $fh $hdr, "\n\n", $bdy or die "print $!"; close $fh or die "msmtp \$?=$?"; __END__