Re: [notmuch] Mailing list Reply-To munging and notmuch reply

Subject: Re: [notmuch] Mailing list Reply-To munging and notmuch reply

Date: Sat, 28 Nov 2009 12:11:49 -0800

To: Jed Brown, notmuch@notmuchmail.org

Cc:

On Sat, 28 Nov 2009 20:26:52 +0100, Jed Brown <jed@59A2.org> wrote:
> I'm not sure I follow (at least not when comparing to the sanitized
> headers shown in the online archives).  Could you send me one of these
> headers?

No problem. See attached.

The mail on cairo-commit has a From: address that is auto-generated by
the username of the committer, (so is likely not even valid for a
reply). The To: address (cairo-commit@cairographics.org) also does not
accept any mail. So a reply to either of those addresses will not be
useful.

Instead, the mail sets a Reply-To: to the general
cairo@cairographics.org list.

So that's not your typical Reply-to munging on a mailing list, (in this
case, there's no incoming mail where the munging could break a user's
manually set Reply-To header).

And it sounds like your idea would not break the replying to this list,
(replies would still be directed to cairo@ which is what I want). If I
understand correctly, it would still also reply to cairo-commit@ which
will end up bouncing, until we add something for "reply to sender only".
And that's the same behavior I've had with any MUA and this list.

> When mailing lists munge, do they ever just add to that field (RFC-2822
> says Reply-To may contain multiple addresses)?

I have no idea about that myself.

-Carl

part-000.sig (application/pgp-signature)

Envelope-to: cworth@localhost
Delivery-date: Fri, 27 Nov 2009 04:50:53 -0800
To: cairo-commit@cairographics.org
Message-Id: <20091127125016.C147710051@kemper.freedesktop.org>
Date: Fri, 27 Nov 2009 04:50:16 -0800 (PST)
From: ajohnson@kemper.freedesktop.org (Adrian Johnson)
Subject: [cairo-commit] src/cairo-pdf-surface.c
Precedence: list
Reply-To: cairo@cairographics.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: cairo-commit-bounces@lists.cairographics.org
Errors-To: cairo-commit-bounces@lists.cairographics.org

 src/cairo-pdf-surface.c |    5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

New commits:
commit 02d7e123d640d62db46ef03d7faecbc7598444e1
Author: Adrian Johnson <ajohnson@redneon.com>
Date:   Fri Nov 27 23:11:56 2009 +1030

    PDF: Remove extraneous \n from end of jpeg/jp2 data
    
    PDF requires a '\n' between the end of stream data and the "endstream"
    that is not included in the stream length. Ensure this is always added
    in _close_stream where it is not included in the stream length.
    
    Previously the jpeg/jp2 embedding functions were adding the '\n'. This
    resulted in the '\n' becoming part of the stream data.

diff --git a/src/cairo-pdf-surface.c b/src/cairo-pdf-surface.c
index 62178dc..e8335f0 100644
--- a/src/cairo-pdf-surface.c
+++ b/src/cairo-pdf-surface.c
@@ -1332,13 +1332,12 @@ _cairo_pdf_surface_close_stream (cairo_pdf_surface_t *surface)
 	surface->output = surface->pdf_stream.old_output;
 	_cairo_pdf_operators_set_stream (&surface->pdf_operators, surface->output);
 	surface->pdf_stream.old_output = NULL;
-	_cairo_output_stream_printf (surface->output,
-				     "\n");
     }
 
     length = _cairo_output_stream_get_position (surface->output) -
 	surface->pdf_stream.start_offset;
     _cairo_output_stream_printf (surface->output,
+				 "\n"
 				 "endstream\n"
 				 "endobj\n");
 
@@ -2010,7 +2009,6 @@ _cairo_pdf_surface_emit_jpx_image (cairo_pdf_surface_t   *surface,
 	return status;
 
     _cairo_output_stream_write (surface->output, mime_data, mime_data_length);
-    _cairo_output_stream_printf (surface->output, "\n");
     status = _cairo_pdf_surface_close_stream (surface);
 
     return status;
@@ -2058,7 +2056,6 @@ _cairo_pdf_surface_emit_jpeg_image (cairo_pdf_surface_t   *surface,
 	return status;
 
     _cairo_output_stream_write (surface->output, mime_data, mime_data_length);
-    _cairo_output_stream_printf (surface->output, "\n");
     status = _cairo_pdf_surface_close_stream (surface);
 
     return status;
_______________________________________________
cairo-commit mailing list
cairo-commit@lists.cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo-commit

Previous message (by thread): Re: [notmuch] [PATCH 2/2] notmuch-reply.c: Handle munged `Reply-To' headers.

Thread:

Jed Brown—[notmuch] Mailing list Reply-To munging and notmuch reply [inbox, signed, unread]
- Carl Worth—Re: [notmuch] Mailing list Reply-To munging and notmuch reply [inbox, signed, unread]
  - Jed Brown—Re: [notmuch] Mailing list Reply-To munging and notmuch reply [inbox, signed, unread]
    - Carl Worth—Re: [notmuch] Mailing list Reply-To munging and notmuch reply [attachment, inbox, signed, unread]
      - Jed Brown—[notmuch] [PATCH 1/2] notmuch-reply.c: factor adding recipients into common function [inbox, unread]
        Jed Brown—[notmuch] [PATCH 2/2] notmuch-reply.c: Handle munged `Reply-To' headers. [inbox, unread]
        Jed Brown—[notmuch] [PATCH] notmuch-reply.c: early exit for munged Reply-To when header is not present [inbox, unread]
        Carl Worth—Re: [notmuch] [PATCH 2/2] notmuch-reply.c: Handle munged `Reply-To' headers. [inbox, signed, unread]
        Jed Brown—Re: [notmuch] [PATCH 2/2] notmuch-reply.c: Handle munged `Reply-To' headers. [inbox, unread]