--- /dev/null
+Return-Path: <jf.hyqohaczlksw4tx6ae@l2015aftruuq.dns007.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id CCA1A6DE18FD\r
+ for <notmuch@notmuchmail.org>; Sun, 3 Jan 2016 12:27:52 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.283\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.283 tagged_above=-999 required=5 tests=[AWL=0.086, \r
+ DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
+ RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001,\r
+ TVD_FROM_1=0.999] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id bEZjEEjPB331 for <notmuch@notmuchmail.org>;\r
+ Sun, 3 Jan 2016 12:27:49 -0800 (PST)\r
+Received: from know-smtprelay-omc-1.server.virginmedia.net\r
+ (know-smtprelay-omc-1.server.virginmedia.net [80.0.253.65])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 178736DE18DD\r
+ for <notmuch@notmuchmail.org>; Sun, 3 Jan 2016 12:27:48 -0800 (PST)\r
+Received: from dev.koan19.net ([82.1.197.255])\r
+ by know-smtprelay-1-imp with bizsmtp\r
+ id 1YTl1s00E5X6CWA01YTlHh; Sun, 03 Jan 2016 20:27:45 +0000\r
+X-Originating-IP: [82.1.197.255]\r
+X-Spam: 0\r
+X-Authority: v=2.1 cv=AJvf2gUA c=1 sm=1 tr=0 a=D+CNGfzuhY6ArhcYgadsyQ==:117\r
+ a=D+CNGfzuhY6ArhcYgadsyQ==:17 a=jxr8AxaCAAAA:8 a=dmPqMsitAAAA:8\r
+ a=hov-Noh0Y1sA:10 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=uZvujYp8AAAA:8\r
+ a=Mtf3CE5mHBFcJ1K1414A:9 a=CjuIK1q_8ugA:10 a=pFPAoXI41dMA:10\r
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;\r
+ d=l2015aftruuq.dns007.net; i=@l2015aftruuq.dns007.net; q=dns/txt; s=l201512;\r
+ t=1451852864; h=To : Cc : Subject : References : MIME-Version : Content-Type\r
+ : In-Reply-To : From : Message-ID : Date : X-Originating-IP : Subject : From\r
+ : Date; bh=2TxZzTtcupPxkprsdWpezrUla+fEq+rzmfnIBTNbV3c=;\r
+ b=NN63EMpcsqL/y9w9Z8k01NlUqLdXxVFWzYq42xZPaIV4lqRxDWTugi49GkAg1bqbHtZe4L\r
+ RzTHWBJt+3D2dWC6Bvfk0zBngETg4pqTjzwQvJlgZIUVNGhGaCQCE0kquHxntFs24o7B9K3N\r
+ 93xWJnCi+Wnzj568Yb3dUYb7P6F3mlm+jeWEZMmux2z4k/x/s4EwJPq41vyD+sBruU+hcHmA ==\r
+To: Jani Nikula <jani@nikula.org>\r
+Cc: notmuch@notmuchmail.org\r
+Subject: Re: [PATCH] cli/insert: do not lose the SMTP envelope\r
+References: <1451647279.42.86b0a8ab@201601.l2015aftruuq.dns007.net>\r
+ <87bn92wsx4.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87bn92wsx4.fsf@nikula.org>\r
+User-Agent: Mutt/1.5.23.1 (2014-03-12)\r
+From: J Farkas <jf.hyqohaczlksw4tx6ae@l2015aftruuq.dns007.net>\r
+Message-ID: <1451852864.63.af86be8a@201601.l2015aftruuq.dns007.net>\r
+Date: Sun, 03 Jan 2016 20:27:44 +0000\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 03 Jan 2016 20:27:52 -0000\r
+\r
+On 2016-01-03 at 18:04:39, Jani Nikula wrote:\r
+> On Fri, 01 Jan 2016, J Farkas <jf.hyqohaczlksw4tx6ae@l2015aftruuq.dns007.net> wrote:\r
+> > From: Janos Farkas <chexum+dev@gmail.com>\r
+> > Subject: [PATCH] cli/insert: do not lose the SMTP envelope\r
+> >\r
+> > Make sure we store the envelope sender/recipient if provided by\r
+> > qmail-command(8) in $RPLINE and $DTLINE.\r
+> > ---\r
+> >\r
+> > I just realised that the messages delivered directly into maildir don't have\r
+> > the usual envelope addresses that qmail provides. This is a piece of\r
+> > information that's important to (at least my) troubleshooting, so I created a\r
+> > patch that seems to work well, applies cleanly to master (and 0.21), and\r
+> > provided a NEWS entry should it be necessary.\r
+> \r
+> I'd be more interested in seeing some tests for this...\r
+\r
+I was thinking of it, and it could be simply an assurance that the\r
+functionality stays there after changes too. To be honest, the only\r
+reason I didn't because the test suite is not passing in my environment,\r
+either because of some gdb peculiarity, or some differences with emacs.\r
+\r
+Answering your comment about Mallory here -- the DTLINE and RPLINE are\r
+practically qmail's way of splitting the first two headers that *should*\r
+be written in the message, they can only be affected by someone who\r
+is actually saying he wants to deliver a message, not for any other\r
+deliveries.\r
+\r
+All the data that is supplied this way to the MDA by qmail (or the local\r
+MTA), is still something that was accepted during the SMTP conversation\r
+and passed basic checks, for a locally acceptable recipient, and after\r
+any possible blocking on the sender.\r
+\r
+It's just done in this way because:\r
+\r
+- DTLINE is the Delivered-To line and qmail at this point is not sure\r
+ the file will be "delivered", or processed in some other way, only the\r
+ delivering program can actually tell what recipient will it be\r
+ delivered to. qmail uses this series of headers for loop avoidance,\r
+ so it's essential that all the checkpoints are present.\r
+\r
+- RPLINE is the Return-Path header that should be the *first* header in\r
+ the file; if it would become part of the stdio, now all delivering and\r
+ non-delivering programs would have to parse, detach it, and reattach\r
+ to the front after any headers added.\r
+\r
+It's basically a way to keep the SMTP conversation details alive along\r
+the delivery pipeline. Throwing it away is incorrect. If this is not\r
+ending up in the message, all I lose is the SMTP envelope, that can tell\r
+me what entity was directly responsible to pass this message to my SMTP\r
+server - was it sent by a mailing list, or if it's a direct message.\r
+Or, in some cases, *which* mailing list. It's a much safer way than\r
+parsing through the Received lines.\r
+\r
+Feel free to let me know if it needs further clarification why it is to\r
+be done this way.\r
+\r
+> > NEWS | 9 +++++++++\r
+> > notmuch-insert.c | 28 ++++++++++++++++++++++++++++\r
+> > 2 files changed, 37 insertions(+)\r
+> >\r
+> > diff --git a/NEWS b/NEWS\r
+> > index 6681699..13d45c8 100644\r
+> > --- a/NEWS\r
+> > +++ b/NEWS\r
+> > @@ -1,3 +1,12 @@\r
+> > +\r
+> > +\r
+> > +`notmuch insert` records the envelope addresses if available\r
+> > +\r
+> > + If the caller provides this information as qmail-command(8) does in\r
+> > + the RPLINE and DTLINE environment variables, then notmuch insert will\r
+> > + record it in the maildir file.\r
+> \r
+> We usually refer to message files. Perhaps you should also mention what\r
+> the RPLINE and DTLINE variables should contain.\r
+\r
+I don't think it's worthy for a NEWS entry with an explanation for those\r
+- perhaps you meant in the commit or comments?\r
+\r
+> > +\r
+> > Notmuch 0.21 (2015-10-29)\r
+> > =========================\r
+> > \r
+> > diff --git a/notmuch-insert.c b/notmuch-insert.c\r
+> > index 5205c17..ecc0fa0 100644\r
+> > --- a/notmuch-insert.c\r
+> > +++ b/notmuch-insert.c\r
+> > @@ -284,6 +284,26 @@ copy_fd (int fdout, int fdin)\r
+> > }\r
+> > \r
+> > /*\r
+> > + * Write zero (and LF) terminated string to the output fd. It's expected to\r
+> > + * come from getenv(), so it's not checked for correctness. NULL or empty\r
+> > + * string is ignored, successfully.\r
+> > + * Return TRUE on success, FALSE on errors.\r
+> > + */\r
+> > +static notmuch_bool_t\r
+> > +write_header (int fdout, const char *hdr)\r
+> > +{\r
+> > + ssize_t written,to_write;\r
+> > +\r
+> > + if (hdr && (to_write = strlen (hdr))) {\r
+> > + written = write (fdout, hdr, to_write);\r
+> > + if (written != to_write)\r
+> > + return FALSE;\r
+> > + }\r
+> \r
+> It's not an error for write() to return prematurely with written <\r
+> to_write. Please see the write(2) man page and the copy_fd()\r
+> implementation in this file.\r
+\r
+Yes, I considered it - I just couldn't see why any of the conditions\r
+that can cause this, makes it worth to keep trying.\r
+\r
+My manuals, and even the POSIX write()* description is only mentioning\r
+error conditions (end of medium, file size limits) and signals that can\r
+cause a split write(). In case of a hard error (which can be resolved\r
+some time later, for sure), the best choice is to abort it anyway.\r
+There's no other signal that can divert the execution, just ctrl-c, in\r
+which case the user is already expecting the program to quit.\r
+\r
+And - a "failure" in an MDA is not necessarily the worst way to handle\r
+problems - the delivery is just deferred by the local queue, it will\r
+only cause an error if it was persistently failing for a long time.\r
+\r
+But if you think it should be more robust at this point, I'll be happy\r
+to redo the error handling as expected.\r
+\r
+* http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html\r
+\r
+\r
+> Jani.\r
+> \r
+> > +\r
+> > + return TRUE;\r
+> > +}\r
+> > +\r
+> > +/*\r
+> > * Write fdin to a new temp file in maildir/tmp, return full path to\r
+> > * the file, or NULL on errors.\r
+> > */\r
+> > @@ -297,6 +317,14 @@ maildir_write_tmp (const void *ctx, int fdin, const char *maildir)\r
+> > if (fdout < 0)\r
+> > return NULL;\r
+> > \r
+> > + /* maildir(5) suggests the message should start with a Return-Path\r
+> > + * and Delivered-To lines. qmail-local(8) supplies these.\r
+> > + */\r
+> > + if (! write_header(fdout, getenv("RPLINE")))\r
+> > + goto FAIL;\r
+> > + if (! write_header(fdout, getenv("DTLINE")))\r
+> > + goto FAIL;\r
+> > +\r
+> > if (! copy_fd (fdout, fdin))\r
+> > goto FAIL;\r
+\r
projects / notmuch-archives.git / commitdiff