From 60389620d98dd09d4722f078b3523c6a0425f173 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Thu, 15 May 1997 06:41:38 +0000 Subject: [PATCH] Better >From handling. svn path=/trunk/; revision=1010 --- NEWS | 2 ++ driver.c | 23 +++++++++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/NEWS b/NEWS index 3a66249f..4685c5a3 100644 --- a/NEWS +++ b/NEWS @@ -24,6 +24,8 @@ every user entry in a multi-user poll declaration. pl 3.9.5 (): * Add an error notification when an incoming message has embedded NULs. +* Throw out >From lines in headers to prevent getting hosed by upstream + sendmails with the 'E' option on. pl 3.9.4 (Wed May 14 12:27:22 EDT 1997): * Fixed a compilation glitch for systems like SunOS & others without atexit(3). diff --git a/driver.c b/driver.c index 894c58c0..f0ed9f2c 100644 --- a/driver.c +++ b/driver.c @@ -519,6 +519,28 @@ char *realname; /* real name of host */ break; } + /* + * This code prevents fetchmail from becoming an accessory after + * the fact to upstream sendmails with the `E' option on. This + * can result in an escaped Unix From_ line at the beginning of + * the headers. If fetchmail just passes it through, the client + * listener may think the message has *no* headers (since the first) + * line it sees doesn't look RFC822-conformant) and fake up a set. + * + * What the user would see in this case is bogus (synthesized) + * headers, followed by a blank line, followed by the >From, + * followed by the real headers, followed by a blank line, + * followed by text. + * + * We forestall this lossage by tossing anything that looks + * like an escaped From_ line in headers. These aren't RFC822 + * so our conscience is clear... + */ + if (!strncasecmp(line, ">From ", 6)) + { + free(line); + continue; + } /* * OK, this is messy. If we're forwarding by SMTP, it's the @@ -539,6 +561,7 @@ char *realname; /* real name of host */ if (!ctl->mda && !strncasecmp("Return-Path:", line, 12)) { return_path = xstrdup(nxtaddr(line)); + free(line); continue; } -- 2.43.2