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