search

marlam / mpop

POP3 client
https://marlam.de/mpop
GNU General Public License v3.0
13 stars 1 forks source link

mistaking for included 822 header as a new message? #10

Closed greg-minshall closed 2 years ago

greg-minshall commented 2 years ago

greetings. i received an odd message today, with very few Received-By lines, etc. here it is as it appears in my inbox:

small-minshall_hv.txt

it appears it should have been part of a larger message (from my nospam.mbox -- see below):

weird-minshall_hv.txt

(in my inbox, the latter message was truncated, i.e., did not included the embedded message.)

i run procmail. i have a line at the beginning of my procmail rc file

:0 c
$BULKMAIL/nospam.mbox

which contained the above "weird" text.

also in my procmail rc file, i do 

LOGABSTRACT=all
LOGFILE=$BULKMAIL/procmail-log.txt

and, for what seems the right point in procmail-log.txt, i see:

 Subject: new nongnu elpa package candidate: cpupower
  Folder: rcvstore +emacs-devel                                            5512
 Subject: [PATCH] * elpa-packages (cpupower): New package
  Folder: rcvstore +inbox                                                  2671

which i take to mean procmail was invoked twice, once for the "envelope", once for the embedded message.

my .mpoprc is pretty generic. it includes

# Deliver mail via procmail:
delivery mda /usr/bin/procmail ~/.procmailrc-client

i'm running

bash apollo2 (master): {50532} mpop --version
mpop version 1.4.13
Platform: x86_64-pc-linux-gnu
TLS/SSL library: GnuTLS
Authentication library: built-in
Supported authentication methods:
user plain external apop cram-md5 login oauthbearer xoauth2
IDN support: disabled
NLS: enabled, LOCALEDIR is /usr/local/share/locale
Keyring support: Gnome
Configuration file name: /home/minshall/.mpoprc

Copyright (C) 2021 Martin Lambers and others.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

i'll upgrade to 1.4.15, but i don't see anything in the git log that looks like a candidate.

i notice that the above inclusion was embedded with >From (rather than > From with a space), but i notice several other messages in nospam.mbox that lack the space, and appear to have been received correctly.

marlam commented 2 years ago

Hi, I just tested by serving your file weird-minshall_hv.txt via mpopd to mpop. When used with delivery maildir, mpop delivers the message exactly as it is (plus the Received: header). I also checked with procmail and the bits of configuration that you posted, and on my system the resulting nospam.mbox file is again exactly the same as the input plus the Received header. I cannot exactly reproduce the problem, but it seems unlikely that the splitting of one input mail into two mails is done by mpop; is there maybe some procmail rule that could cause this?

greg-minshall commented 2 years ago

hi, Martin, thanks for taking a look. i'm sorry, but not immensely surprised, the problem didn't repeat.

is there maybe some procmail rule that could cause this?

i suspect that "friends don't let friends read their .procmailrc files" :). but, here it is, in case anything jumps out at you.

procmailrc-client.txt

otherwise, i guess i'll try to keep my eyes open. possibly i've had this happen before, but not noticed what was happening. cheers.

marlam commented 2 years ago

I'm sorry, but it's been years since I meddled with procmail rules; I can't help with that. I'm closing this issue now since it does not seem to be related to mpop.