bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi,
when replying to github I have now this message from gmail:

--8<---------------cut here---------------start------------->8---
Delivery to the following recipient failed permanently:

     notifications@github.com

Technical details of permanent failure: 
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550-5.1.1 The email account that you
tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 ci15si58841657wjb.6 (state 13).
--8<---------------cut here---------------end--------------->8---

this happen when using emacs from trunk.
When I switch to emacs-24 branch Gnus works fine, gmail doesn't send
such mails.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Andreas Schwab]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> when replying to github

What does "replying to github" mean?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Lars Magne Ingebrigtsen]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Delivery to the following recipient failed permanently:
>
>      notifications@github.com
>
> Technical details of permanent failure: 
> Google tried to deliver your message, but it was rejected by the
> recipient domain. We recommend contacting the other email provider for
> further information about the cause of this error. The error that the
> other server returned was: 550 550-5.1.1 The email account that you
> tried to reach does not exist. Please try
> 550-5.1.1 double-checking the recipient's email address for typos or
> 550-5.1.1 unnecessary spaces. Learn more at
> 550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 ci15si58841657wjb.6 (state 13).

Gmail seems to claim that notifications@github.com doesn't exist.

Is that the address you tried to send something to?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Delivery to the following recipient failed permanently:
>>
>>      notifications@github.com
>>
>> Technical details of permanent failure: 
>> Google tried to deliver your message, but it was rejected by the
>> recipient domain. We recommend contacting the other email provider for
>> further information about the cause of this error. The error that the
>> other server returned was: 550 550-5.1.1 The email account that you
>> tried to reach does not exist. Please try
>> 550-5.1.1 double-checking the recipient's email address for typos or
>> 550-5.1.1 unnecessary spaces. Learn more at
>> 550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 ci15si58841657wjb.6 (state 13).
>
> Gmail seems to claim that notifications@github.com doesn't exist.
And it doesn't exists.

> Is that the address you tried to send something to?
No.

When you receive a mail from somebody that report you a bug on github
the "From" header is like this:

From: Bob <notifications@github.com>

And then Gnus ask:

--8<---------------cut here---------------start------------->8---
Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y
Sending...
Sending via mail...
Delivering message to emacs-helm/helm <reply+i-9131322-4209e327b45ec8b02eff867a89ed150cbee7298b-1533939@reply.github.com>...
--8<---------------cut here---------------end--------------->8---

and it doesn't (shouldn't) try to send to <notifications@github.com> 
but it does so when replying with emacs-24.3.50.1 (trunk).
As I said this doesn't happen with emacs-24 branch (I replied several
times today with no problems)

Note: I use "F" to reply on github as always. (The mail is Cc'ed to the
real address of sender)

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Lars Magne Ingebrigtsen]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> When you receive a mail from somebody that report you a bug on github
> the "From" header is like this:
>
> From: Bob <notifications@github.com>
>
> And then Gnus ask:
> Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y

And Then Gnus asks?  Spontaneously?  Or do you use a command first?  In
which case, what command?

And could you forward me one of these messages?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> When you receive a mail from somebody that report you a bug on github
>> the "From" header is like this:
>>
>> From: Bob <notifications@github.com>
>>
>> And then Gnus ask:
>> Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y
>
> And Then Gnus asks?  Spontaneously?
Yes, but not always and it does the same on emacs-24 branch without
trying to send on <notifications@github.com>.

> Or do you use a command first?  In which case, what command?
>
> And could you forward me one of these messages?
Done.

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Lars Magne Ingebrigtsen]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> When you receive a mail from somebody that report you a bug on github
>>> the "From" header is like this:
>>>
>>> From: Bob <notifications@github.com>
>>>
>>> And then Gnus ask:
>>> Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y
>>
>> And Then Gnus asks?  Spontaneously?
> Yes, but not always and it does the same on emacs-24 branch without
> trying to send on <notifications@github.com>.
>
>> Or do you use a command first?  In which case, what command?

You ... do something ... and then Gnus spontaneously starts asking you a
question about "helm@noreply.github.com"?

That sounds very odd indeed.  Gnus normally doesn't send email messages
without being told that it should do so.

Are you sure you're not using a command to send an email or something?
Like `f' or `r' or something?

> To: Vitalie Spinu <notifications@github.com>
> Cc: emacs-helm/helm <helm@noreply.github.com>,  emacs-helm/helm <reply+i-9557813-c0b9a117fc3917ba742be603d9d06b7266481271-1533939@reply.github.com>


-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>
>>>> When you receive a mail from somebody that report you a bug on github
>>>> the "From" header is like this:
>>>>
>>>> From: Bob <notifications@github.com>
>>>>
>>>> And then Gnus ask:
>>>> Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y
>>>
>>> And Then Gnus asks?  Spontaneously?
>> Yes, but not always and it does the same on emacs-24 branch without
>> trying to send on <notifications@github.com>.
>>
>>> Or do you use a command first?  In which case, what command?
>
> You ... do something ... and then Gnus spontaneously starts asking you a
> question about "helm@noreply.github.com"?
>
> That sounds very odd indeed.  Gnus normally doesn't send email messages
> without being told that it should do so.
If you want you can submit a fake bug report here:
https://github.com/emacs-helm/helm/issues?state=open

And then we could try answering each other using Gnus. (I will switch to
trunk to reproduce)
Probably you should hit the bug too (Maybe use a Gmail address?) 

Note: I will not have the time today, I am outdoor. (maybe tonight or tomorrow).

> Are you sure you're not using a command to send an email or something?
> Like `f' or `r' or something?
1) I open and read mail
2) I hit "F"
3) Edit my reply ...
4) C-c C-c
5) Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)


-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>
>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>>
>>>>> When you receive a mail from somebody that report you a bug on github
>>>>> the "From" header is like this:
>>>>>
>>>>> From: Bob <notifications@github.com>
>>>>>
>>>>> And then Gnus ask:
>>>>> Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y
>>>>
>>>> And Then Gnus asks?  Spontaneously?
>>> Yes, but not always and it does the same on emacs-24 branch without
>>> trying to send on <notifications@github.com>.
>>>
>>>> Or do you use a command first?  In which case, what command?
>>
>> You ... do something ... and then Gnus spontaneously starts asking you a
>> question about "helm@noreply.github.com"?
>>
>> That sounds very odd indeed.  Gnus normally doesn't send email messages
>> without being told that it should do so.
> If you want you can submit a fake bug report here:
> https://github.com/emacs-helm/helm/issues?state=open
>
> And then we could try answering each other using Gnus. (I will switch to
> trunk to reproduce)
> Probably you should hit the bug too (Maybe use a Gmail address?) 
>
> Note: I will not have the time today, I am outdoor. (maybe tonight or tomorrow).
>
>> Are you sure you're not using a command to send an email or something?
>> Like `f' or `r' or something?
> 1) I open and read mail
> 2) I hit "F"
> 3) Edit my reply ...
> 4) C-c C-c
> 5) Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)

In the last reply I sent on github with emacs from trunk, it seems I was
NOT asked for 5), could it be that Gnus ignore 'helm@noreply.github.com'
and when ignoring this, a reply is sent to  <notifications@github.com> ?

Also, I am sending my mails asynchronously (`smtpmail-send-it' is
wrapped in a function that use another emacs to send), does something
new happen (modification of headers) at this time ?

-- 
  Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Lars,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>
>>>> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>>>
>>>>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>>>>
>>>>>> When you receive a mail from somebody that report you a bug on github
>>>>>> the "From" header is like this:
>>>>>>
>>>>>> From: Bob <notifications@github.com>
>>>>>>
>>>>>> And then Gnus ask:
>>>>>> Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)  y
>>>>>
>>>>> And Then Gnus asks?  Spontaneously?
>>>> Yes, but not always and it does the same on emacs-24 branch without
>>>> trying to send on <notifications@github.com>.
>>>>
>>>>> Or do you use a command first?  In which case, what command?
>>>
>>> You ... do something ... and then Gnus spontaneously starts asking you a
>>> question about "helm@noreply.github.com"?
>>>
>>> That sounds very odd indeed.  Gnus normally doesn't send email messages
>>> without being told that it should do so.
>> If you want you can submit a fake bug report here:
>> https://github.com/emacs-helm/helm/issues?state=open
>>
>> And then we could try answering each other using Gnus. (I will switch to
>> trunk to reproduce)
>> Probably you should hit the bug too (Maybe use a Gmail address?) 
>>
>> Note: I will not have the time today, I am outdoor. (maybe tonight or tomorrow).
>>
>>> Are you sure you're not using a command to send an email or something?
>>> Like `f' or `r' or something?
>> 1) I open and read mail
>> 2) I hit "F"
>> 3) Edit my reply ...
>> 4) C-c C-c
>> 5) Address `helm@noreply.github.com' might be bogus.  Continue? (y or n)
>
> In the last reply I sent on github with emacs from trunk, it seems I was
> NOT asked for 5), could it be that Gnus ignore 'helm@noreply.github.com'
> and when ignoring this, a reply is sent to  <notifications@github.com> ?
>
> Also, I am sending my mails asynchronously (`smtpmail-send-it' is
> wrapped in a function that use another emacs to send), does something
> new happen (modification of headers) at this time ?
I tried using "normally" `smtpmail-send-it', not the async function and
get same error from gmail:

--8<---------------cut here---------------start------------->8---
X-Failed-Recipients: notifications@github.com
Subject: Delivery Status Notification (Failure)
Message-ID: <047d7ba979245cb55404d5a39fda@google.com>
Date: Wed, 13 Feb 2013 23:37:16 +0000
--8<---------------cut here---------------end--------------->8---

So Gnus is still trying to send to "notifications@github.com".

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Lars,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

I have isolated the problem to message.el, so when I load the message.el
of emacs-24 branch the problem disapear.
I will try to (re)diff the file to found out what is wrong there.
Perhaps you can have a look on your side too ?

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Lars,

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi Lars,
>
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
> I have isolated the problem to message.el, so when I load the message.el
> of emacs-24 branch the problem disapear.
> I will try to (re)diff the file to found out what is wrong there.
> Perhaps you can have a look on your side too ?

So the problem comes from `message-get-reply-headers', more exactly this
piece of code:

--8<---------------cut here---------------start------------->8---
      ;; Make sure this message goes to the author if this is a wide
      ;; reply, since Reply-To address may be a list address a mailing
      ;; list server added.
      (when (and wide author)
	(setq cc (concat author ", " cc)))
      (when (or wide (not author))
	(setq author (or (message-fetch-field "from") ""))))
--8<---------------cut here---------------end--------------->8---

In our case the "from" field contain "notification@github.com" which is
the place where we should never reply.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi Lars,
>
> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>
>> Hi Lars,
>>
>> Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:
>>
>> I have isolated the problem to message.el, so when I load the message.el
>> of emacs-24 branch the problem disapear.
>> I will try to (re)diff the file to found out what is wrong there.
>> Perhaps you can have a look on your side too ?
>
> So the problem comes from `message-get-reply-headers', more exactly this
> piece of code:
>
>       ;; Make sure this message goes to the author if this is a wide
>       ;; reply, since Reply-To address may be a list address a mailing
>       ;; list server added.
>       (when (and wide author)
> 	(setq cc (concat author ", " cc)))
>       (when (or wide (not author))
> 	(setq author (or (message-fetch-field "from") ""))))
>
> In our case the "from" field contain "notification@github.com" which is
> the place where we should never reply.

Here the commit that introduce this bug:

--8<---------------cut here---------------start------------->8---
2559724 * 
        | Author: Katsumi Yamaoka <yamaoka@jpl.org>
        | Date:   Mon Nov 19 06:24:03 2012 +0000
        | 
        |     message.el (message-get-reply-headers): Make sure the reply goes to the author if it is a wide reply
        | 
        |  lisp/ChangeLog  |    5 +++++
        |  lisp/message.el |   13 +++++++++----
        |  2 files changed, 14 insertions(+), 4 deletions(-)
--8<---------------cut here---------------end--------------->8---

With this change, here what is happening, sending a reply in same topic
on github:

;; BAD emacs-24.3.50
;; To: Le Wang <notifications@github.com>
;; Cc: emacs-helm/helm <helm@noreply.github.com>,  emacs-helm/helm <reply+i-[...]1533939@reply.github.com>

;; GOOD emacs-24.2.93
;; To: emacs-helm/helm <reply+i-[...]33939@reply.github.com>
;; Cc: emacs-helm/helm <helm@noreply.github.com>


-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

Thierry Volpiatto wrote:
> Here the commit that introduce this bug:
> 2559724 *
>| Author: Katsumi Yamaoka <yamaoka@jpl.org>
>| Date:   Mon Nov 19 06:24:03 2012 +0000
>|
>|     message.el (message-get-reply-headers): Make sure the reply goes to the author if it is a wide reply

This log message suggested that the author (i.e., the From: address)
of a mail didn't appear in a message header when starting composing
a wide reply.  I mean, if you perform a wide reply using the `F' or
the `S W' command to a mail like the following:

From: the-author@example.com.invalid
To: the-mailing-list@example.com.invalid
Cc: foo@example.com.invalid
Reply-To: the-mailing-list@example.com.invalid

The old one will compose a draft as follows:

To: the-mailing-list@example.com.invalid
Cc: foo@example.com.invalid

But the present one does:

To: the-author@example.com.invalid
Cc: the-mailing-list@example.com.invalid, foo@example.com.invalid

This is much better for a wide reply, isn't it?  The root cause of
this difference is due to the Reply-To header, that some mailing
list servers are likely to add (it may be because many mail clients
compose a draft to send to only the author, I guess).

Is your problem that the From address is invalid?  If so, if there
is a valid Reply-To header, you can use R rather than F.  Otherwise,
feel free to forward an example mail to me.

Regards,

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Thierry Volpiatto wrote:
>> Here the commit that introduce this bug:
>> 2559724 *
>>| Author: Katsumi Yamaoka <yamaoka@jpl.org>
>>| Date:   Mon Nov 19 06:24:03 2012 +0000
>>|
>>|     message.el (message-get-reply-headers): Make sure the reply goes to the author if it is a wide reply
>
> This log message suggested that the author (i.e., the From: address)
> of a mail didn't appear in a message header when starting composing
> a wide reply.  I mean, if you perform a wide reply using the `F' or
> the `S W' command to a mail like the following:
>
> From: the-author@example.com.invalid
> To: the-mailing-list@example.com.invalid
> Cc: foo@example.com.invalid
> Reply-To: the-mailing-list@example.com.invalid
>
> The old one will compose a draft as follows:
>
> To: the-mailing-list@example.com.invalid
> Cc: foo@example.com.invalid
>
> But the present one does:
>
> To: the-author@example.com.invalid
> Cc: the-mailing-list@example.com.invalid, foo@example.com.invalid
>
> This is much better for a wide reply, isn't it?  The root cause of
> this difference is due to the Reply-To header, that some mailing
> list servers are likely to add (it may be because many mail clients
> compose a draft to send to only the author, I guess).
>
> Is your problem that the From address is invalid?
Yes.

> If so, if there is a valid Reply-To header, you can use R rather than
> F.

Anyway even when hitting "F" this shouldn't happen.

> Otherwise, feel free to forward an example mail to me.
Will (re)send in next post.

Here a patch that fix the problem, please review, I am not familiar with
all these mails headers.
Note that the second when clause is not needed when setting author
before, and don't corrupt further the "to" header when wide is not used.

Also my english is not very good, but I don't understand your comments,
please fix it (I leave long lines to see better).

Thanks.


diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
index 808e1ed..8b9df3c 100644
--- a/lisp/gnus/message.el
+++ b/lisp/gnus/message.el
@@ -6720,17 +6720,17 @@ The function is called with one parameter, a cons cell ..."
 			       ", "))
 	    mct (message-fetch-field "mail-copies-to")
 	    author (or (message-fetch-field "mail-reply-to")
-		       (message-fetch-field "reply-to"))
+		       (message-fetch-field "reply-to")
+                       (message-fetch-field "from")
+                       "")
 	    mft (and message-use-mail-followup-to
 		     (message-fetch-field "mail-followup-to")))
       ;; Make sure this message goes to the author if this is a wide
-      ;; reply, since Reply-To address may be a list address a mailing
-      ;; list server added.
+      ;; reply, FIXME: please fix the commented line following, it seem the second one is good and the first one wrong.
+      ;; since Reply-To address may be a list address a mailing list server added.
+      ;; since Reply-to adress may be a mailing list address with server added.
       (when (and wide author)
-	(setq cc (concat author ", " cc)))
-      (when (or wide (not author))
-	(setq author (or (message-fetch-field "from") ""))))
-
+	(setq cc (concat author ", " cc))))
     ;; Handle special values of Mail-Copies-To.
     (when mct
       (cond ((or (equal (downcase mct) "never")

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> feel free to forward an example mail to me.
This is my reply rejected, I will send the original mail in next post
(the one I reply to)

--8<---------------cut here---------------start------------->8---
Delivery to the following recipient failed permanently:

     notifications@github.com

Technical details of permanent failure: 
Google tried to deliver your message, but it was rejected by the server for the recipient domain github.com by aspmx.l.google.com. [173.194.65.27].

The error that the other server returned was:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://support.google.com/mail/bin/answer.py?answer=6596 r7si54774070eeo.56 - gsmtp

----- Original message -----

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=x-received:from:to:cc:subject:organization:references:date
         :in-reply-to:message-id:user-agent:mime-version:content-type;
        bh=QnkowhoNn3E1OVqXjQgJR202Dxb2qUbVOi7SbdlJg7c=;
        b=FUvLhze0DYaug4h9gwGh68s6uVH5HZHtiD1eN+oIdmLlKxrqs2WsACAc52p6yx+3/C
         B2mGeWWuI55F4OS/E2AqskKhlmjR8CI8aArB9juHv2V2Eus4DclgIaPyzL2fQ8d4L8WG
         JTIn3A2aY7+LEM4P69e5SoH6juoeWnL5HYxnT/Tvt6UOCrURBxZKd+QkIn0xpBC3bmce
         lTLxfOrnBE7uAlvAMbS7exIaZ/wsHLAFEC4BBnx6wtB8LDia9eyc0xfbKi1YaYiPl/8p
         W5MAGC1YjCVFrJCjQAHMWP1KacPIUVwjQ2i64ECDXDOFATyijJNDJWyGwi3bDB93jpEA
         ZPjA==
X-Received: by 10.14.218.71 with SMTP id j47mr81954311eep.28.1361464821499;
        Thu, 21 Feb 2013 08:40:21 -0800 (PST)
Return-Path: <thierry.volpiatto@gmail.com>
Received: from dell-14z (lbe83-2-78-243-104-167.fbx.proxad.net. [...])
        by mx.google.com with ESMTPS id a1sm90649428eep.2.2013.02.21.08.40.19
        (version=TLSv1.2 cipher=RC4-SHA bits=128/128);
        Thu, 21 Feb 2013 08:40:20 -0800 (PST)
From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
To: Le Wang <notifications@github.com>
Cc: emacs-helm/helm <helm@noreply.github.com>,  emacs-helm/helm <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
Subject: Re: [helm] install project oriented file selector sub-project (#75)
Organization: Emacs Helm
References: <emacs-helm/helm/issues/75@github.com>
	<emacs-helm/helm/issues/75/13890635@github.com>
Date: Thu, 21 Feb 2013 17:40:17 +0100
In-Reply-To: <emacs-helm/helm/issues/75/13890635@github.com> (Le Wang's
	message of "Thu, 21 Feb 2013 06:20:10 -0800")
Message-ID: <87fw0pr572.fsf@gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain

Gnus test please ignore, I will possibly send 4 or 5 more messages like
this ignore them, sorry for inconvenience.
--8<---------------cut here---------------end--------------->8---

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> feel free to forward an example mail to me.
And this is the original where I reply to:
So the "Reply-To" should take precedence on the "from" header and goes
in the "to" header when replying, when "wide" is used "from" is added
anyway to "cc".

--8<---------------cut here---------------start------------->8---
Delivered-To: thierry.volpiatto@gmail.com
Received: by 10.227.197.78 with SMTP id ej14csp14052wbb; Thu, 21 Feb 2013 06:20:13 -0800 (PST)
X-Received: by 10.52.27.138 with SMTP id t10mr27289568vdg.59.1361456412613; Thu, 21 Feb 2013 06:20:12 -0800 (PST)
Return-Path: <noreply@github.com>
Received: from smtp1-ext.rs.github.com (smtp1-ext.rs.github.com.
 [207.97.227.250]) by mx.google.com with ESMTP id
 cu8si28670005vdc.66.2013.02.21.06.20.11; Thu, 21 Feb 2013 06:20:12 -0800
 (PST)
Received-SPF: pass (google.com: domain of noreply@github.com designates 207.97.227.250 as permitted sender) client-ip=207.97.227.250;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of noreply@github.com designates 207.97.227.250 as permitted sender) smtp.mail=noreply@github.com
Date: Thu, 21 Feb 2013 06:20:10 -0800
From: Le Wang <notifications@github.com>
Reply-To: emacs-helm/helm <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
To: emacs-helm/helm <helm@noreply.github.com>
Cc: Thierry Volpiatto <thierry.volpiatto@gmail.com>
Message-ID: <emacs-helm/helm/issues/75/13890635@github.com>
In-Reply-To: <emacs-helm/helm/issues/75@github.com>
References: <emacs-helm/helm/issues/75@github.com>
Subject: Re: [helm] install project oriented file selector sub-project (#75)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_51262d1ad0666_5f80715ed087131"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Recipient: thierryvolpiatto
X-GitHub-Reason: mention
List-ID: emacs-helm/helm <helm.emacs-helm.github.com>
List-Archive: https://github.com/emacs-helm/helm
List-Post: <mailto:reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
List-Unsubscribe: <mailto:unsub+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>,
 <https://github.com/notifications/unsubscribe/80HvPz8ZWvRqWmqQN2GsxLztsDjDRpTCk8CPvqKw7W1r2ZCbhzH9_3QZw83xIpl5>
X-GitHub-Recipient-Address: thierry.volpiatto@gmail.com
--8<---------------cut here---------------end--------------->8---

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Thierry Volpiatto wrote:
>> Here the commit that introduce this bug:
>> 2559724 *
>>| Author: Katsumi Yamaoka <yamaoka@jpl.org>
>>| Date:   Mon Nov 19 06:24:03 2012 +0000
>>|
>>|     message.el (message-get-reply-headers): Make sure the reply goes to the author if it is a wide reply
>
> This log message suggested that the author (i.e., the From: address)
> of a mail didn't appear in a message header when starting composing
> a wide reply.  I mean, if you perform a wide reply using the `F' or
> the `S W' command to a mail like the following:
It is failing also when replying with `R' because your second when
clause which is wrong.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

thierry.volpiatto@gmail.com wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
[...]
>> I mean, if you perform a wide reply using the `F' or
>> the `S W' command to a mail like the following:
>>
>> From: the-author@example.com.invalid
>> To: the-mailing-list@example.com.invalid
>> Cc: foo@example.com.invalid
>> Reply-To: the-mailing-list@example.com.invalid
>>
>> The old one will compose a draft as follows:
>>
>> To: the-mailing-list@example.com.invalid
>> Cc: foo@example.com.invalid
>>
>> But the present one does:
>>
>> To: the-author@example.com.invalid
>> Cc: the-mailing-list@example.com.invalid, foo@example.com.invalid
>>
>> This is much better for a wide reply, isn't it?
[...]
>> Is your problem that the From address is invalid?

> Yes.

>> If so, if there is a valid Reply-To header, you can use R rather than
>> F.

> Anyway even when hitting "F" this shouldn't happen.

Please let me say that a wide reply doesn't contain the author
of an original mail in the recipient list is a bug.  To exclude
an invalid address from a wide reply is not a feature; that is
a rare exception that the poison is efficacious.  Please imagine,
a wide reply to your mail doesn't go to you only:

(You send a mail)

From: Thierry Volpiatto
To: emacs-devel
Cc: Lars
Reply-To: emacs-devel

(I reply to your mail)

-> From: Katsumi Yamaoka
   To: emacs-devel
   Cc: Lars
   Reply-To: emacs-devel

(You reply to my reply that you happen to find in Gmane)

-> From: Thierry Volpiatto
   To: emacs-devel
   Cc: Lars
   Reply-To: emacs-devel

(I don't notice it)

Though the emacs-devel list doesn't add Reply-To, not a few lists
do it.  I don't think that GitHub doesn't use a valid address in
the From header is a bad manner.  But it should have a valid
Reply-To if it allows a mail reply, or should have something like
a link to a web form.

>> Otherwise, feel free to forward an example mail to me.
> Will (re)send in next post.

Have you sent it already?  If so, it may be delayed or...
Anyway I don't need it now, maybe.

> Here a patch that fix the problem, please review, I am not familiar with
> all these mails headers.

Unfortunately it's a regression. :(

> Note that the second when clause is not needed when setting author
> before, and don't corrupt further the "to" header when wide is not used.

> Also my english is not very good, but I don't understand your comments,
> please fix it (I leave long lines to see better).

Sorry for my further poor English.

[...]
> -      ;; [...]since Reply-To address may be a list address a mailing
> -      ;; list server added.

I omitted a relative pronoun in front of "a mailing list server".
Though I don't know whether it is barbarous, it is taught in Japan's
school. ;-p

Regards,

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Please let me say that a wide reply doesn't contain the author
> of an original mail in the recipient list is a bug.  To exclude
> an invalid address from a wide reply is not a feature;

It is not excluded in the patch, it is added to "cc" only if "wide" is
specified.

> that is a rare exception that the poison is efficacious.  Please
> imagine, a wide reply to your mail doesn't go to you only:
>
> (You send a mail)
>
> From: Thierry Volpiatto
> To: emacs-devel
> Cc: Lars
> Reply-To: emacs-devel
>
> (I reply to your mail)
>
> -> From: Katsumi Yamaoka
>    To: emacs-devel
>    Cc: Lars
>    Reply-To: emacs-devel
>
> (You reply to my reply that you happen to find in Gmane)
>
> -> From: Thierry Volpiatto
>    To: emacs-devel
>    Cc: Lars
>    Reply-To: emacs-devel
>
> (I don't notice it)

Please have a look at the mail examples I sent in other posts.

> Though the emacs-devel list doesn't add Reply-To, not a few lists
> do it.  I don't think that GitHub doesn't use a valid address in
> the From header is a bad manner.  But it should have a valid
> Reply-To if it allows a mail reply,

It have a valid "Reply-To" and with the patch I sent it is used instead
of "from".

> or should have something like a link to a web form.
>
>>> Otherwise, feel free to forward an example mail to me.
>> Will (re)send in next post.
>
> Have you sent it already?  If so, it may be delayed or...
> Anyway I don't need it now, maybe.
>
>> Here a patch that fix the problem, please review, I am not familiar with
>> all these mails headers.
>
> Unfortunately it's a regression. :(
Don't know, but it is better than receiving warning mails from gmail
like this:

From: Mail Delivery Subsystem <mailer-daemon@googlemail.com>
Subject: Delivery Status Notification (Failure)

Which is not an improvement IMO.

Note that with the current state it is impossible to reply with Gnus on
github with `R' `F' or whatever without beeing rejected; 
The patch I sent fix this.

The point is that with the patch I sent + the headers of the rejected
mail and the original mail where I reply to, you will be able to
understand what happen and fix it.

Thanks.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

thierry.volpiatto@gmail.com wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> Please let me say that a wide reply doesn't contain the author
>> of an original mail in the recipient list is a bug.  To exclude
>> an invalid address from a wide reply is not a feature;

> It is not excluded in the patch, it is added to "cc" only if "wide" is
> specified.
[...]
> Please have a look at the mail examples I sent in other posts.

Hm, I haven't gotten it yet.  Could you try replying to a mail
attached in this message as well (copy it to a mail group and do
F)?

[...]
> The point is that with the patch I sent + the headers of the rejected
> mail and the original mail where I reply to, you will be able to
> understand what happen and fix it.

Ok, I'll surely try it.


[-- Attachment #2: Type: application/octet-stream, Size: 271 bytes --]

Message-ID: <871uc8nbq1.fsf@totally-fudged-out-message-id>
To: the-mailing-list@example.com.invalid
Cc: foo@example.com.invalid
Subject: test
Reply-To: the-mailing-list@example.com.invalid
From: the-author@example.com.invalid
Date: Fri, 22 Feb 2013 13:07:34 +0900

test.

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> thierry.volpiatto@gmail.com wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Please let me say that a wide reply doesn't contain the author
>>> of an original mail in the recipient list is a bug.  To exclude
>>> an invalid address from a wide reply is not a feature;
>
>> It is not excluded in the patch, it is added to "cc" only if "wide" is
>> specified.
> [...]
>> Please have a look at the mail examples I sent in other posts.
>
> Hm, I haven't gotten it yet.

I see them on Gmane:

https://lists.gnu.org/archive/html/bug-gnu-emacs/2013-02/msg01077.html
https://lists.gnu.org/archive/html/bug-gnu-emacs/2013-02/msg01078.html

> Could you try replying to a mail attached in this message as well
> (copy it to a mail group and do F)?

I have no mail group to copy to, but with the links above you should see
clearly the problem.

> [...]
>> The point is that with the patch I sent + the headers of the rejected
>> mail and the original mail where I reply to, you will be able to
>> understand what happen and fix it.
>
> Ok, I'll surely try it.

Thanks.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> thierry.volpiatto@gmail.com wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Please let me say that a wide reply doesn't contain the author
>>> of an original mail in the recipient list is a bug.  To exclude
>>> an invalid address from a wide reply is not a feature;
>
>> It is not excluded in the patch, it is added to "cc" only if "wide" is
>> specified.
> [...]
>> Please have a look at the mail examples I sent in other posts.
>
> Hm, I haven't gotten it yet.  Could you try replying to a mail
> attached in this message as well (copy it to a mail group and do
> F)?
>
> [...]
>> The point is that with the patch I sent + the headers of the rejected
>> mail and the original mail where I reply to, you will be able to
>> understand what happen and fix it.
>
> Ok, I'll surely try it.

Also on a side note, this change can be done also in this same function:

-	(if to (setq recipients (concat recipients ", " to)))
-	(if cc (setq recipients (concat recipients ", " cc)))
-	(if extra (setq recipients (concat recipients ", " extra)))
-	(if mct (setq recipients (concat recipients ", " mct)))))
-      (if (>= (length recipients) 2)
-	  ;; Strip the leading ", ".
-	  (setq recipients (substring recipients 2)))
+	(loop for h in `(,to ,cc ,extra ,mct)
+	      for recip = (and recipients (not (string= recipients "")))
+	      when h do (setq recipients (concat recipients (and recip ", ") h)))))

And also in first loop in beginning of function `thereis' can be used.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> thierry.volpiatto@gmail.com wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Please let me say that a wide reply doesn't contain the author
>>> of an original mail in the recipient list is a bug.  To exclude
>>> an invalid address from a wide reply is not a feature;
>
>> It is not excluded in the patch, it is added to "cc" only if "wide" is
>> specified.
> [...]
>> Please have a look at the mail examples I sent in other posts.
>
> Hm, I haven't gotten it yet.  Could you try replying to a mail
> attached in this message as well (copy it to a mail group and do
> F)?
>
> [...]
>> The point is that with the patch I sent + the headers of the rejected
>> mail and the original mail where I reply to, you will be able to
>> understand what happen and fix it.
>
> Ok, I'll surely try it.

And you can probaly get rid of this while loop too by removing
duplicates in first place:

-	     (message-tokenize-header recipients)))
-      ;; Remove all duplicates.
-      (let ((s recipients))
-	(while s
-	  (let ((address (car (pop s))))
-	    (while (assoc address s)
-	      (setq recipients (delq (assoc address s) recipients)
-		    s (delq (assoc address s) s))))))
+	     ;; Remove all duplicates.
+	     (loop with recip for mess in (message-tokenize-header recipients)
+		   unless (member mess recip) collect mess into recip
+		   finally return recip)))
 
NOTE: `remove-duplicates' can't be used because you require cl at compile
time only.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>> thierry.volpiatto@gmail.com wrote:
>>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>>> Please let me say that a wide reply doesn't contain the author
>>>> of an original mail in the recipient list is a bug.  To exclude
>>>> an invalid address from a wide reply is not a feature;
>>
>>> It is not excluded in the patch, it is added to "cc" only if "wide" is
>>> specified.
>> [...]
>>> Please have a look at the mail examples I sent in other posts.
>>
>> Hm, I haven't gotten it yet.  Could you try replying to a mail
>> attached in this message as well (copy it to a mail group and do
>> F)?
>>
>> [...]
>>> The point is that with the patch I sent + the headers of the rejected
>>> mail and the original mail where I reply to, you will be able to
>>> understand what happen and fix it.
>>
>> Ok, I'll surely try it.
>
> And you can probaly get rid of this while loop too by removing
> duplicates in first place:
>
> -	     (message-tokenize-header recipients)))
> -      ;; Remove all duplicates.
> -      (let ((s recipients))
> -	(while s
> -	  (let ((address (car (pop s))))
> -	    (while (assoc address s)
> -	      (setq recipients (delq (assoc address s) recipients)
> -		    s (delq (assoc address s) s))))))
> +	     ;; Remove all duplicates.
> +	     (loop with recip for mess in (message-tokenize-header recipients)
> +		   unless (member mess recip) collect mess into recip
> +		   finally return recip)))
>  
> NOTE: `remove-duplicates' can't be used because you require cl at compile
> time only.
And while we are at it this one also can be simpler:

-	(let ((plain-addrs (mapcar 'car recipients))
-	      subaddrs recip)
-	  (while plain-addrs
-	    (setq subaddrs (assoc (car plain-addrs)
-				  message-hierarchical-addresses)
-		  plain-addrs (cdr plain-addrs))
-	    (when subaddrs
-	      (setq subaddrs (cdr subaddrs))
-	      (while subaddrs
-		(setq recip (assoc (car subaddrs) recipients)
-		      subaddrs (cdr subaddrs))
-		(if recip
-		    (setq recipients (delq recip recipients))))))))
+        (setq recipients
+              (loop for (r . a) in recipients
+                    for assoc = (cdr (assoc r message-hierarchical-addresses))
+                    when assoc append assoc into recip
+                    unless (member r recip) collect (cons r a) into results
+                    finally return (cdr results))))

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> thierry.volpiatto@gmail.com wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Please let me say that a wide reply doesn't contain the author
>>> of an original mail in the recipient list is a bug.  To exclude
>>> an invalid address from a wide reply is not a feature;
>
>> It is not excluded in the patch, it is added to "cc" only if "wide" is
>> specified.
> [...]
>> Please have a look at the mail examples I sent in other posts.
>
> Hm, I haven't gotten it yet.  Could you try replying to a mail
> attached in this message as well (copy it to a mail group and do
> F)?
>
> [...]
>> The point is that with the patch I sent + the headers of the rejected
>> mail and the original mail where I reply to, you will be able to
>> understand what happen and fix it.
>
> Ok, I'll surely try it.

Here the whole patch:

diff --git a/lisp/message.el b/lisp/message.el
index 21847ac..d92c9ae 100644
--- a/lisp/message.el
+++ b/lisp/message.el
@@ -6753,8 +6753,7 @@ The function is called with one parameter, a cons cell ..."
       ;; message-header-synonyms.
       (setq to (or (message-fetch-field "to")
 		   (and (loop for synonym in message-header-synonyms
-			      when (memq 'Original-To synonym)
-			      return t)
+			      thereis (memq 'Original-To synonym))
 			(message-fetch-field "original-to")))
 	    cc (message-fetch-field "cc")
 	    extra (when message-extra-wide-headers
@@ -6764,16 +6763,15 @@ The function is called with one parameter, a cons cell ..."
 			       ", "))
 	    mct (message-fetch-field "mail-copies-to")
 	    author (or (message-fetch-field "mail-reply-to")
-		       (message-fetch-field "reply-to"))
+		       (message-fetch-field "reply-to")
+		       (message-fetch-field "from") "")
 	    mft (and message-use-mail-followup-to
 		     (message-fetch-field "mail-followup-to")))
       ;; Make sure this message goes to the author if this is a wide
       ;; reply, since Reply-To address may be a list address a mailing
       ;; list server added.
       (when (and wide author)
-	(setq cc (concat author ", " cc)))
-      (when (or wide (not author))
-	(setq author (or (message-fetch-field "from") ""))))
+	(setq cc (concat author ", " cc))))
 
     ;; Handle special values of Mail-Copies-To.
     (when mct
@@ -6829,13 +6827,9 @@ want to get rid of this query permanently.")))
 	(setq recipients (concat ", " mft)))
        (t
 	(setq recipients (if never-mct "" (concat ", " author)))
-	(if to (setq recipients (concat recipients ", " to)))
-	(if cc (setq recipients (concat recipients ", " cc)))
-	(if extra (setq recipients (concat recipients ", " extra)))
-	(if mct (setq recipients (concat recipients ", " mct)))))
-      (if (>= (length recipients) 2)
-	  ;; Strip the leading ", ".
-	  (setq recipients (substring recipients 2)))
+	(loop for h in `(,to ,cc ,extra ,mct)
+	      for recip = (and recipients (not (string= recipients "")))
+	      when h do (setq recipients (concat recipients (and recip ", ") h)))))
       ;; Squeeze whitespace.
       (while (string-match "[ \t][ \t]+" recipients)
 	(setq recipients (replace-match " " t t recipients)))
@@ -6854,31 +6848,20 @@ want to get rid of this query permanently.")))
 			    (cons (downcase (mail-strip-quoted-names addr))
 				  addr))
 		 (cons (downcase (mail-strip-quoted-names addr)) addr)))
-	     (message-tokenize-header recipients)))
-      ;; Remove all duplicates.
-      (let ((s recipients))
-	(while s
-	  (let ((address (car (pop s))))
-	    (while (assoc address s)
-	      (setq recipients (delq (assoc address s) recipients)
-		    s (delq (assoc address s) s))))))
+	     ;; Remove all duplicates.
+	     (loop with recip for mess in (message-tokenize-header recipients)
+		   unless (member mess recip) collect mess into recip
+		   finally return recip)))
 
       ;; Remove hierarchical lists that are contained within each other,
       ;; if message-hierarchical-addresses is defined.
       (when message-hierarchical-addresses
-	(let ((plain-addrs (mapcar 'car recipients))
-	      subaddrs recip)
-	  (while plain-addrs
-	    (setq subaddrs (assoc (car plain-addrs)
-				  message-hierarchical-addresses)
-		  plain-addrs (cdr plain-addrs))
-	    (when subaddrs
-	      (setq subaddrs (cdr subaddrs))
-	      (while subaddrs
-		(setq recip (assoc (car subaddrs) recipients)
-		      subaddrs (cdr subaddrs))
-		(if recip
-		    (setq recipients (delq recip recipients))))))))
+        (setq recipients
+              (loop for (r . a) in recipients
+                    for assoc = (cdr (assoc r message-hierarchical-addresses))
+                    when assoc append assoc into recip
+                    unless (or (member r recip) (assoc r results))
+                    collect (cons r a) into results finally return results)))
 
       (setq recipients (message-prune-recipients recipients))
 

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> thierry.volpiatto@gmail.com wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Please let me say that a wide reply doesn't contain the author
>>> of an original mail in the recipient list is a bug.  To exclude
>>> an invalid address from a wide reply is not a feature;
>
>> It is not excluded in the patch, it is added to "cc" only if "wide" is
>> specified.
> [...]
>> Please have a look at the mail examples I sent in other posts.
>
> Hm, I haven't gotten it yet.  Could you try replying to a mail
> attached in this message as well (copy it to a mail group and do
> F)?
>
> [...]
>> The point is that with the patch I sent + the headers of the rejected
>> mail and the original mail where I reply to, you will be able to
>> understand what happen and fix it.
>
> Ok, I'll surely try it.

To summarize the problem here some more example, with also the patch
modified to fix previous errors when removing duplicates.
Note that the changes applied further in the patch are not related with
this bug, they just try to improve the code.
Note also that one loop is removing extra spaces (I have noticed that in
some mails, addresses are separated with two spaces in "CC").

,----[ Replying on github ]
| A "reply-to" header exists:
| 
| From: Le Wang <notifications@github.com>
| Reply-To: emacs-helm/helm <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
| To: emacs-helm/helm <helm@noreply.github.com>
| 
| I send a reply with my patch applied:
| 
| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
| To: emacs-helm/helm <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
| Cc: emacs-helm/helm <helm@noreply.github.com>
| 
| I send a reply with actual code (bug)
| 
| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
| To: Le Wang <notifications@github.com>
| Cc: emacs-helm/helm <helm@noreply.github.com>,  emacs-helm/helm <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
`----

,----[ Replying on emacs.dev ]
| No "reply-to" header:
| 
| From: Katsumi Yamaoka <yamaoka@jpl.org>
| To: thierry.volpiatto@gmail.com
| Cc: 13321@debbugs.gnu.org
| 
| I send a reply with my patch applied:
| 
| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
| To: Katsumi Yamaoka <yamaoka@jpl.org>
| Cc: 13321@debbugs.gnu.org
| 
| With original code it is the same (no bug in this case)
| 
| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
| To: Katsumi Yamaoka <yamaoka@jpl.org>
| Cc: 13321@debbugs.gnu.org
`----

And here the last version of patch:

diff --git a/lisp/message.el b/lisp/message.el
index 21847ac..44f1ee4 100644
--- a/lisp/message.el
+++ b/lisp/message.el
@@ -6753,8 +6753,7 @@ The function is called with one parameter, a cons cell ..."
       ;; message-header-synonyms.
       (setq to (or (message-fetch-field "to")
 		   (and (loop for synonym in message-header-synonyms
-			      when (memq 'Original-To synonym)
-			      return t)
+			      thereis (memq 'Original-To synonym))
 			(message-fetch-field "original-to")))
 	    cc (message-fetch-field "cc")
 	    extra (when message-extra-wide-headers
@@ -6764,16 +6763,19 @@ The function is called with one parameter, a cons cell ..."
 			       ", "))
 	    mct (message-fetch-field "mail-copies-to")
 	    author (or (message-fetch-field "mail-reply-to")
-		       (message-fetch-field "reply-to"))
+		       (message-fetch-field "reply-to")
+		       (message-fetch-field "from") "")
 	    mft (and message-use-mail-followup-to
 		     (message-fetch-field "mail-followup-to")))
-      ;; Make sure this message goes to the author if this is a wide
-      ;; reply, since Reply-To address may be a list address a mailing
-      ;; list server added.
+      ;; Make sure this message goes to the author if this is a wide reply.
+      ;; If a '*reply-to' header is found use it, otherwise use the 'from'
+      ;; header and add it to 'cc'.
+      ;; If "wide" is not specified, "author" will end later in "to" header.
+      ;; We should not force using "from" for "author" when not using "wide"
+      ;; because it will go in this case in "to" and in some cases the address
+      ;; from "from" is invalid like on github (bug#13321).
       (when (and wide author)
-	(setq cc (concat author ", " cc)))
-      (when (or wide (not author))
-	(setq author (or (message-fetch-field "from") ""))))
+	(setq cc (concat author ", " cc))))
 
     ;; Handle special values of Mail-Copies-To.
     (when mct
@@ -6829,13 +6831,9 @@ want to get rid of this query permanently.")))
 	(setq recipients (concat ", " mft)))
        (t
 	(setq recipients (if never-mct "" (concat ", " author)))
-	(if to (setq recipients (concat recipients ", " to)))
-	(if cc (setq recipients (concat recipients ", " cc)))
-	(if extra (setq recipients (concat recipients ", " extra)))
-	(if mct (setq recipients (concat recipients ", " mct)))))
-      (if (>= (length recipients) 2)
-	  ;; Strip the leading ", ".
-	  (setq recipients (substring recipients 2)))
+	(loop for h in `(,to ,cc ,extra ,mct)
+	      for recip = (and recipients (not (string= recipients "")))
+	      when h do (setq recipients (concat recipients (and recip ", ") h)))))
       ;; Squeeze whitespace.
       (while (string-match "[ \t][ \t]+" recipients)
 	(setq recipients (replace-match " " t t recipients)))
@@ -6854,31 +6852,21 @@ want to get rid of this query permanently.")))
 			    (cons (downcase (mail-strip-quoted-names addr))
 				  addr))
 		 (cons (downcase (mail-strip-quoted-names addr)) addr)))
-	     (message-tokenize-header recipients)))
-      ;; Remove all duplicates.
-      (let ((s recipients))
-	(while s
-	  (let ((address (car (pop s))))
-	    (while (assoc address s)
-	      (setq recipients (delq (assoc address s) recipients)
-		    s (delq (assoc address s) s))))))
+	     ;; Remove all duplicates.
+	     (loop with recip for m in (message-tokenize-header recipients)
+                   for mess = (replace-regexp-in-string "^ " "" m)
+                   unless (member mess recip) collect mess into recip
+                   finally return recip)))
 
       ;; Remove hierarchical lists that are contained within each other,
       ;; if message-hierarchical-addresses is defined.
       (when message-hierarchical-addresses
-	(let ((plain-addrs (mapcar 'car recipients))
-	      subaddrs recip)
-	  (while plain-addrs
-	    (setq subaddrs (assoc (car plain-addrs)
-				  message-hierarchical-addresses)
-		  plain-addrs (cdr plain-addrs))
-	    (when subaddrs
-	      (setq subaddrs (cdr subaddrs))
-	      (while subaddrs
-		(setq recip (assoc (car subaddrs) recipients)
-		      subaddrs (cdr subaddrs))
-		(if recip
-		    (setq recipients (delq recip recipients))))))))
+        (setq recipients
+              (loop for (r . a) in recipients
+                    for assoc = (cdr (assoc r message-hierarchical-addresses))
+                    when assoc append assoc into recip
+                    unless (or (member r recip) (assoc r results))
+                    collect (cons r a) into results finally return results)))
 
       (setq recipients (message-prune-recipients recipients))

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

Thierry Volpiatto wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> Ok, I'll surely try it.

I tried the last patch.

[...]
> ,----[ Replying on github ]
>| A "reply-to" header exists:
>|
>| From: Le Wang <notifications@github.com>
>| Reply-To: emacs-helm/helm
>| <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
>| To: emacs-helm/helm <helm@noreply.github.com>
>|
>| I send a reply with my patch applied:
>|
>| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>| To: emacs-helm/helm
>| <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
>| Cc: emacs-helm/helm <helm@noreply.github.com>

Why this /wide reply/ doesn't go to "Le Wang"?  Even if Le Wang
is a subscriber, a regular visitor, or a staff of the Emacs Helm
list, don't we usually include the author of an original mail in
the recipients list if it is a wide reply?  Otherwise if Le Wang's
address is invalid and you want Gnus to exclude it from the recipients
list, you can use the user option `message-dont-reply-to-names'.

>| I send a reply with actual code (bug)
>|
>| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>| To: Le Wang <notifications@github.com>
>| Cc: emacs-helm/helm <helm@noreply.github.com>, emacs-helm/helm
>| <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
> `----

Is it ok that both the cases contain <helm@noreply.github.com>?
You can omit it as well using `message-dont-reply-to-names' (if
you want).

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> you can use the user option `message-dont-reply-to-names'.

Or `message-prune-recipient-rules'.
cf. (info "(message)Wide Reply")

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Thierry Volpiatto wrote:
>> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>>> Ok, I'll surely try it.
>
> I tried the last patch.
>
> [...]
>> ,----[ Replying on github ]
>>| A "reply-to" header exists:
>>|
>>| From: Le Wang <notifications@github.com>
>>| Reply-To: emacs-helm/helm
>>| <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
>>| To: emacs-helm/helm <helm@noreply.github.com>
>>|
>>| I send a reply with my patch applied:
>>|
>>| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>>| To: emacs-helm/helm
>>| <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
>>| Cc: emacs-helm/helm <helm@noreply.github.com>
>
> Why this /wide reply/ doesn't go to "Le Wang"?

Because it is an invalid address, everybody when replying will get the
same address, e.g if you reply to github your address will be 
"Katsumi Yamaoka <notifications@github.com>", it is why github provide a
reply-to header and internally, github will send to the real address of
Le Wang.

> Even if Le Wang is a subscriber, a regular visitor, or a staff of the
> Emacs Helm list, don't we usually include the author of an original
> mail in the recipients list if it is a wide reply?

Yes unless a "reply-to" header is provided, which is the case here.

> Otherwise if Le Wang's address is invalid and you want Gnus to exclude
> it from the recipients list, you can use the user option
> `message-dont-reply-to-names'.

This is an option yes, but I think that when a "reply-to" header is
provided, it should take precedence on the "to" header actually
provided, isn't it the purpose of the "reply-to" header ?
 
>>| I send a reply with actual code (bug)
>>|
>>| From: Thierry Volpiatto <thierry.volpiatto@gmail.com>
>>| To: Le Wang <notifications@github.com>
>>| Cc: emacs-helm/helm <helm@noreply.github.com>, emacs-helm/helm
>>| <reply+i-5357313-fd4754a13604e0814f8932f6f63f437dff55f8d0-1533939@reply.github.com>
>> `----
>
> Is it ok that both the cases contain <helm@noreply.github.com>?
> You can omit it as well using `message-dont-reply-to-names' (if
> you want).

This one should not be omitted IMO.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

Thierry Volpiatto wrote:
> I think that when a "reply-to" header is provided, it should take
> precedence on the "to" header actually provided, isn't it the
> purpose of the "reply-to" header ?

That may be a sound argument, but mailing lists that use Reply-To
seem not a few.  Actually, I often needed to resend my wide reply
to the author.  There was no means to help it in the old Gnus.
OTOH, you have handy options. :)

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Thierry Volpiatto]

Hi Katsumi,

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Thierry Volpiatto wrote:
>> I think that when a "reply-to" header is provided, it should take
>> precedence on the "to" header actually provided, isn't it the
>> purpose of the "reply-to" header ?
>
> That may be a sound argument, but mailing lists that use Reply-To
> seem not a few.  Actually, I often needed to resend my wide reply
> to the author.  There was no means to help it in the old Gnus.
> OTOH, you have handy options. :)
Ok, I trust you ;-), anyway using `message-dont-reply-to-names' fix the
problem.

Thanks.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

bug#13321: 24.3.0.50; Gmail error when replying from Gnus to github

[Katsumi Yamaoka]

Thierry Volpiatto wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>> Thierry Volpiatto wrote:
>>> I think that when a "reply-to" header is provided, it should take
>>> precedence on the "to" header actually provided, isn't it the
>>> purpose of the "reply-to" header ?
>>
>> That may be a sound argument, but mailing lists that use Reply-To
>> seem not a few.  Actually, I often needed to resend my wide reply
>> to the author.  There was no means to help it in the old Gnus.
>> OTOH, you have handy options. :)
> Ok, I trust you ;-), anyway using `message-dont-reply-to-names' fix the
> problem.

Thanks!