From 60389620d98dd09d4722f078b3523c6a0425f173 Mon Sep 17 00:00:00 2001
From: "Eric S. Raymond" <esr@thyrsus.com>
Date: Thu, 15 May 1997 06:41:38 +0000
Subject: 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;
}
--
cgit v1.2.3