BTS hint about unreachable submitters

[Bob Proulx]

Bernhard Voelker wrote:
> I had to take out your email address to be able to reply to this issue:
> 
>   An error occurred while sending mail. The mail server responded:
>   Requested action not taken: mailbox unavailable
>   invalid DNS MX or A/AAAA resource record.

There is a useful feature of the BTS that allows one to reply to the
BTS and then have the BTS send the message on to other places.

Sometimes a bug submitter will have blacklisted all but whitelisted
the project site, or other such things.  In this case the submitter's
address did not have an MX record but did have A records.
Traditionally mail is still delivered to sites with only A records
although that is frowned upon these days.  (Sites wishing to declare
that they do not receive mail should use the new-ish "null MX" record
these days.)

But there are many different possibilities of problems sending to a
submitter.  This BTS feature allows the project site to send the
message to the submitter instead of our own local distributed mail
servers.  I use this feature frequently.

  https://www.debian.org/Bugs/Developer#followup
    address@hidden — these are also sent to the submitter
    and forwarded to debian-bugs-dist, but not to the package maintainer;

Therefore if one were to reply to a bug and have a problem with the
sender it would be possible to change the To: recipient list 

  -To: address@hidden, address@hidden
  +To: address@hidden, address@hidden

And then @debbugs.gnu.org would deal with both destinations.  One to
the bug and one to the bug submitter.  This should give the best
chance of reaching a submitter since the message is then coming from
the debbugs.gnu.org domain and host and not our distributed sites from
which we reply.

Of course doing this means that any delivery problems to the submitter
are not visible to the person doing the reply, because errors are
handled by the BTS, and handled in this case means discarded.  But it
does mean that delivery is escalated upstream to the project site, in
this case debbugs.gnu.org and if the submitter will not take delivery
from there then it eliminates any local distributed configuration
policy from the transmission path and clearly indicates a problem on
the submitter side.

Note that sending to nnn-submitter does not include the bug ticket.
(AFAIK.  I haven't actually tested this.)  The bug ticket must be
explicit for it to be included.  Usually one would send to both as in
the example above.

Additionally this supports another rare-ish use case.  A long lived
bug that exists alive over a long time might have a submitter actually
change addresses!  In which case nnn-submitter will send to the
address it was changed to in the BTS that may have happened since the
message being replied to had been sent to the system.

  https://www.debian.org/Bugs/server-control#submitter

At least that is the way I read the documentation on it.  I should
test this and verify that it changes the "Reported by:" field of a BTS
bug.

Anyway...  Thought this might be useful or at least somewhat
interesting... :-)

Bob