unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
* Bug/Issue: References header doesn't wrap in emacs package
@ 2015-10-01 19:00 Allan Streib
  2015-10-02 12:08 ` David Bremner
  2017-03-05 11:45 ` David Bremner
  0 siblings, 2 replies; 8+ messages in thread
From: Allan Streib @ 2015-10-01 19:00 UTC (permalink / raw)
  To: notmuch

Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1

Replying to a message in a deeply nested thread can trigger a complaint:

  sendmail: command failed: 550 5.7.1 Delivery not authorized, message refused: Message is not RFC 2822 compliant

The problem is a References header that is too long/not wrapped.

Regards,

Allan

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2015-10-01 19:00 Bug/Issue: References header doesn't wrap in emacs package Allan Streib
@ 2015-10-02 12:08 ` David Bremner
  2015-10-03  1:21   ` David Bremner
  2017-03-05 11:45 ` David Bremner
  1 sibling, 1 reply; 8+ messages in thread
From: David Bremner @ 2015-10-02 12:08 UTC (permalink / raw)
  To: Allan Streib, notmuch

Allan Streib <astreib@indiana.edu> writes:

> Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1
>
> Replying to a message in a deeply nested thread can trigger a complaint:
>
>   sendmail: command failed: 550 5.7.1 Delivery not authorized, message refused: Message is not RFC 2822 compliant
>
> The problem is a References header that is too long/not wrapped.
>

Hi Allan;

Thanks for the report.  I can see how notmuch-reply would generate a
long references header in that situation. We rely on message-mode (part
of Gnus) to actually send the message, and it isn't clear to me yet if
message-mode (or some function it invokes) normally folds long headers.
So the first step is to figure out where to best fix this.  As a not so
nice workaround, if you remove References from message-hidden-headers
(using e.g. customize), you'll be able to hand wrap the references line.

d

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2015-10-02 12:08 ` David Bremner
@ 2015-10-03  1:21   ` David Bremner
  2016-06-07  2:50     ` Sanjoy Mahajan
  0 siblings, 1 reply; 8+ messages in thread
From: David Bremner @ 2015-10-03  1:21 UTC (permalink / raw)
  To: Allan Streib, notmuch

David Bremner <david@tethera.net> writes:

> Allan Streib <astreib@indiana.edu> writes:
>
>> Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1
>>
>> Replying to a message in a deeply nested thread can trigger a complaint:
>>
>>   sendmail: command failed: 550 5.7.1 Delivery not authorized, message refused: Message is not RFC 2822 compliant
>>
>> The problem is a References header that is too long/not wrapped.
>>
>
> Hi Allan;
>
> Thanks for the report.  I can see how notmuch-reply would generate a
> long references header in that situation. We rely on message-mode (part
> of Gnus) to actually send the message, and it isn't clear to me yet if
> message-mode (or some function it invokes) normally folds long headers.

I have reported this as an emacs bug.

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21608

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2015-10-03  1:21   ` David Bremner
@ 2016-06-07  2:50     ` Sanjoy Mahajan
  2016-06-07 10:28       ` David Bremner
  0 siblings, 1 reply; 8+ messages in thread
From: Sanjoy Mahajan @ 2016-06-07  2:50 UTC (permalink / raw)
  To: David Bremner, Allan Streib, notmuch

On 2015-10-02 21:21, David Bremner <david@tethera.net> wrote:

>>> The problem is a References header that is too long/not wrapped.
>>>
>>
>> Hi Allan;
>>
>> Thanks for the report.  I can see how notmuch-reply would generate a
>> long references header in that situation. We rely on message-mode (part
>> of Gnus) to actually send the message, and it isn't clear to me yet if
>> message-mode (or some function it invokes) normally folds long headers.
>
> I have reported this as an emacs bug.
>
>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21608

I'm not sure whether fixing it in emacs is right.  The command 'notmuch
reply' is itself (with the sexp or json formats) generating the too-long
References: header.  Shouldn't it generate an RFC-compliant message?

Or should the json/sexp formats remain agnostic about line length,
because wrapping doesn't make sense with key/value pairs?  In that case,
I agree that message-mode should fix any long lines.

By the way, the latest Exim release (4.87), at least as configured in
Debian, does limit lines to 998 characters, and that limit has been
causing me a few hiccups -- usually when I reply to a message sent by
gmail with a zillion references (perhaps it lists every message in the
thread).

-Sanjoy

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2016-06-07  2:50     ` Sanjoy Mahajan
@ 2016-06-07 10:28       ` David Bremner
  2016-06-07 15:51         ` Sanjoy Mahajan
  0 siblings, 1 reply; 8+ messages in thread
From: David Bremner @ 2016-06-07 10:28 UTC (permalink / raw)
  To: Sanjoy Mahajan, Allan Streib, notmuch

Sanjoy Mahajan <sanjoy@olin.edu> writes:


> I'm not sure whether fixing it in emacs is right.  The command 'notmuch
> reply' is itself (with the sexp or json formats) generating the too-long
> References: header.  Shouldn't it generate an RFC-compliant message?
>
> Or should the json/sexp formats remain agnostic about line length,
> because wrapping doesn't make sense with key/value pairs?  In that case,
> I agree that message-mode should fix any long lines.

For me the main issue is that the references header is editable by the
user before sending. So some input sanitization is needed at the sending
stage.

d

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2016-06-07 10:28       ` David Bremner
@ 2016-06-07 15:51         ` Sanjoy Mahajan
  2017-01-27  0:32           ` David Bremner
  0 siblings, 1 reply; 8+ messages in thread
From: Sanjoy Mahajan @ 2016-06-07 15:51 UTC (permalink / raw)
  To: David Bremner, Allan Streib, notmuch

On 2016-06-07 06:28, David Bremner <david@tethera.net> wrote:

> Sanjoy Mahajan <sanjoy@olin.edu> writes:
>
>
>> I'm not sure whether fixing it in emacs is right.  The command 'notmuch
>> reply' is itself (with the sexp or json formats) generating the too-long
>> References: header.  Shouldn't it generate an RFC-compliant message?
>>
>> Or should the json/sexp formats remain agnostic about line length,
>> because wrapping doesn't make sense with key/value pairs?  In that case,
>> I agree that message-mode should fix any long lines.
>
> For me the main issue is that the references header is editable by the
> user before sending. So some input sanitization is needed at the sending
> stage.

Further supporting that argument, the user could also include a
1000-character line in the message body, which would require sanitizing
at the sending stage.

-Sanjoy

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2016-06-07 15:51         ` Sanjoy Mahajan
@ 2017-01-27  0:32           ` David Bremner
  0 siblings, 0 replies; 8+ messages in thread
From: David Bremner @ 2017-01-27  0:32 UTC (permalink / raw)
  To: Allan Streib, notmuch

Sanjoy Mahajan <sanjoy@olin.edu> writes:

> On 2016-06-07 06:28, David Bremner <david@tethera.net> wrote:
>
>> Sanjoy Mahajan <sanjoy@olin.edu> writes:
>>
>>
>>> I'm not sure whether fixing it in emacs is right.  The command 'notmuch
>>> reply' is itself (with the sexp or json formats) generating the too-long
>>> References: header.  Shouldn't it generate an RFC-compliant message?
>>>
>>> Or should the json/sexp formats remain agnostic about line length,
>>> because wrapping doesn't make sense with key/value pairs?  In that case,
>>> I agree that message-mode should fix any long lines.
>>
>> For me the main issue is that the references header is editable by the
>> user before sending. So some input sanitization is needed at the sending
>> stage.
>
> Further supporting that argument, the user could also include a
> 1000-character line in the message body, which would require sanitizing
> at the sending stage.
>
> -Sanjoy

Headers are now folded in emacs master, apparently

        http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21608

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug/Issue: References header doesn't wrap in emacs package
  2015-10-01 19:00 Bug/Issue: References header doesn't wrap in emacs package Allan Streib
  2015-10-02 12:08 ` David Bremner
@ 2017-03-05 11:45 ` David Bremner
  1 sibling, 0 replies; 8+ messages in thread
From: David Bremner @ 2017-03-05 11:45 UTC (permalink / raw)
  To: Allan Streib, notmuch

Allan Streib <astreib@indiana.edu> writes:

> Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1
>
> Replying to a message in a deeply nested thread can trigger a complaint:
>
>   sendmail: command failed: 550 5.7.1 Delivery not authorized, message refused: Message is not RFC 2822 compliant
>
> The problem is a References header that is too long/not wrapped.
>
> Regards,
>

This bug should now be fixed in notmuch (commit 95e9c137e18a, will be
part of notmuch 0.24)

d

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-03-05 11:45 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-01 19:00 Bug/Issue: References header doesn't wrap in emacs package Allan Streib
2015-10-02 12:08 ` David Bremner
2015-10-03  1:21   ` David Bremner
2016-06-07  2:50     ` Sanjoy Mahajan
2016-06-07 10:28       ` David Bremner
2016-06-07 15:51         ` Sanjoy Mahajan
2017-01-27  0:32           ` David Bremner
2017-03-05 11:45 ` David Bremner

Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).