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 nnn-submit...@bugs.debian.org — 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: u...@example.com, n...@debbugs.gnu.org +To: nnn-submit...@debbugs.gnu.org, n...@debbugs.gnu.org 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
