As someone who would like to participate more in the development of Debian, my personal experience is that making contributions is like dropping a message in a bottle into the sea. It feels like a complete crap-shot
whether I'll even receive a comment on any code contribution (including debian-devel RFS, salsa MR, or BTS patch).
Antonio Russo wrote:It is off by default unless that was changed recently-ish.
As someone who would like to participate more in the development of Debian, my personal experience is that making contributions is like dropping a message in a bottle into the sea. It feels like a complete crap-shot whether I'll even receive a comment on any code contribution (including debian-devel RFS, salsa MR, or BTS patch).
For salsa and BTS, one reason for lack of reply can be that the maintainer is never notified. I get surprised sometimes that salsa has merge requests waiting for me. I suspect that either the email notification is broken or off
by default and I never saw instructions to enable it.
In the case of the BTS: it used to email me but that broke a couple years ago and apparently it is hard to fix. So currently a class of us don't get email from any bug reports.What is that class?
In the case of the BTS: it used to email me but that broke a couple years
ago and apparently it is hard to fix. So currently a class of us don't get email from any bug reports.
On Friday, December 29, 2023 2:18:41 P.M. CST Steven Robbins wrote:
In the case of the BTS: it used to email me but that broke a couple years
ago and apparently it is hard to fix. So currently a class of us don't get >> email from any bug reports.
Andrey Rakhmatullin asked "what is that class?".
It's unclear to me. From the last discussion [1], it seems like it should be >everyone. Maybe it is everyone whose mail infrastructure looks at DMARC [2]?
I think SĂ©bastien Noel's 2021 note to the bug report is germane to this >discussion:
"""
Same observation here:
DMARC aggregate reports notifies me that emails sends to the BTS
are not delivered to the final recipient.
I should not be surprised anymore if bugreports are left un-answered, >maintainers are simply not getting notification...
Since the last comment of this bug, 4 months have passed and no
reaction.
I suspect that nobody recieved the last email, and my guts tell me
that i'm writing to /dev/null rigth now :(
Without a working BTS, i'm wondering :
Is the project still interested by users' feedback ?
"""
[1] https://lists.debian.org/debian-devel/2022/09/msg00273.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
"Scott" == Scott Kitterman <debian@kitterman.com> writes:
On January 2, 2024 6:04:18 PM UTC, Steven Robbins <steve@sumost.ca> wrote: >>On Friday, December 29, 2023 2:18:41 P.M. CST Steven Robbins wrote:working fine for me.
In the case of the BTS: it used to email me but that broke a couple years >>> ago and apparently it is hard to fix. So currently a class of us don't get >>> email from any bug reports.
Andrey Rakhmatullin asked "what is that class?".
It's unclear to me. From the last discussion [1], it seems like it should be
everyone. Maybe it is everyone whose mail infrastructure looks at DMARC [2]? >>
I think SĂ©bastien Noel's 2021 note to the bug report is germane to this >>discussion:
"""
Same observation here:
DMARC aggregate reports notifies me that emails sends to the BTS
are not delivered to the final recipient.
I should not be surprised anymore if bugreports are left un-answered, >>maintainers are simply not getting notification...
Since the last comment of this bug, 4 months have passed and no
reaction.
I suspect that nobody recieved the last email, and my guts tell me
that i'm writing to /dev/null rigth now :(
Without a working BTS, i'm wondering :
Is the project still interested by users' feedback ?
"""
[1] https://lists.debian.org/debian-devel/2022/09/msg00273.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
Alternatively, BTS users that are interested in others getting their emails might be better off posting from a domain that doesn't have a DMARC policy that's designed to be used for domains that send only transactional email (i.e. no human users). It's
Scott K
Do not discount them just because you know and can act accordingly.
Cheers
Mike
Am 2. Januar 2024 20:10:27 MEZ schrieb Scott Kitterman <debian@kitterman.com>: >>s working fine for me.
On January 2, 2024 6:04:18 PM UTC, Steven Robbins <steve@sumost.ca> wrote: >>>On Friday, December 29, 2023 2:18:41 P.M. CST Steven Robbins wrote:
In the case of the BTS: it used to email me but that broke a couple years >>>> ago and apparently it is hard to fix. So currently a class of us don't get
email from any bug reports.
Andrey Rakhmatullin asked "what is that class?".
It's unclear to me. From the last discussion [1], it seems like it should be
everyone. Maybe it is everyone whose mail infrastructure looks at DMARC [2]?
I think SĂ©bastien Noel's 2021 note to the bug report is germane to this >>>discussion:
"""
Same observation here:
DMARC aggregate reports notifies me that emails sends to the BTS
are not delivered to the final recipient.
I should not be surprised anymore if bugreports are left un-answered, >>>maintainers are simply not getting notification...
Since the last comment of this bug, 4 months have passed and no >>>reaction.
I suspect that nobody recieved the last email, and my guts tell me
that i'm writing to /dev/null rigth now :(
Without a working BTS, i'm wondering :
Is the project still interested by users' feedback ?
"""
[1] https://lists.debian.org/debian-devel/2022/09/msg00273.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754809
Alternatively, BTS users that are interested in others getting their emails might be better off posting from a domain that doesn't have a DMARC policy that's designed to be used for domains that send only transactional email (i.e. no human users). It'
Scott K
Scott> Alternatively, BTS users that are interested in others
Scott> getting their emails might be better off posting from a
Scott> domain that doesn't have a DMARC policy that's designed to be
Scott> used for domains that send only transactional email (i.e. no
Scott> human users). It's working fine for me.
Would including a warning about the domain you are sending from be more >tractable as an improvement than SRS-style header rewriting?
(This directed more at people who know the BTS code).
At least people could be warned that because of the domain they send
from their mail might not get through.
My guess is that such a warning email (which is the only way we'd have
to do it) would also cause a lot of complaints. Ultimately, I think
we (for some value of we that doesn't include me doing the work) will
need to have the BTS send all emails from bugs.debian.org role
addresses and not use the sender's email in From anymore.
At least people could be warned that because of the domain they send
from their mail might not get through.
My guess is that such a warning email (which is the only way we'd have to
do it) would also cause a lot of complaints.
I think we [...] will need to have the BTS send all emails from bugs.debian.org role addresses and not use the sender's email in From anymore.
Just to make sure I understand the constraints: we can determine[...]
at sending time whether a particular domain is going to cause
trouble or not, right? If so could this rewrite scheme be applied
only for recipients where it's absolutely necessary?
On Wed, Jan 03, 2024 at 05:10:43PM +0000, Scott Kitterman wrote:
At least people could be warned that because of the domain they sendMy guess is that such a warning email (which is the only way we'd have to
from their mail might not get through.
do it) would also cause a lot of complaints.
I think we [...] will need to have the BTS send all emails from
bugs.debian.org role addresses and not use the sender's email in From
anymore.
Just to make sure I understand the constraints: we can determine at sending >time whether a particular domain is going to cause trouble or not, right?
If so could this rewrite scheme be applied only for recipients where it's >absolutely necessary?
That way DDs, who are likeley to care more about their BTS email workflow >than the average user, don't have to deal with the negative consequences of >the address rewriting if they're already behind a polite mailserver.
Further if this discrimination is possible I wonder if it might not also be >possible to accomodate the subset of BTS users who are behind broken mail >providers but use sensible mail clients (mutt and such).
Specifically I think when you embedd an message/rfc822 part mutt allows me
to autoview the message inline, see the (pretty set) of headers, and reply
to this message instead of the "envelope".
So when BTS sees a broken domain it could generate the usual message with >address rewriting applied, but also attach in an multipart/alternative the >untouched version for this set of users to use.
Not sure that all works out, just a crazy idea,
--Daniel
On Wed, Jan 03, 2024 at 05:10:43PM +0000, Scott Kitterman wrote:
At least people could be warned that because of the domain they send
from their mail might not get through.
My guess is that such a warning email (which is the only way we'd have to do it) would also cause a lot of complaints.
I think we [...] will need to have the BTS send all emails from bugs.debian.org role addresses and not use the sender's email in From anymore.
Just to make sure I understand the constraints: we can determine at sending time whether a particular domain is going to cause trouble or not, right?
If so could this rewrite scheme be applied only for recipients where it's absolutely necessary?
On Wed, Jan 03, 2024 at 05:10:43PM +0000, Scott Kitterman wrote:
At least people could be warned that because of the domain they sendMy guess is that such a warning email (which is the only way we'd have to >> > do it) would also cause a lot of complaints.
from their mail might not get through.
I think we [...] will need to have the BTS send all emails from
bugs.debian.org role addresses and not use the sender's email in From
anymore.
Just to make sure I understand the constraints: we can determine at sending >> time whether a particular domain is going to cause trouble or not, right?
If so could this rewrite scheme be applied only for recipients where it's
absolutely necessary?
I haven't looked into this in a lot of detail, but my concern would be
that that would end up being flaky and confusing in practice. I think
people want the behaviour of the BTS to be easily predictable without
having to get an advanced degree in MTA debugging first.
On 2024-01-04 15:54:28 +0100 (+0100), Daniel Gröber wrote:
could this rewrite scheme be applied only for recipients where it's absolutely necessary?
Unfortunately no. It *used* to be a popular assumption that you could
look at the published DKIM/DMARC policies [...] but [...] Gmail decided
to treat messages from its own users more strictly than the policy it publishes for them in DNS. And since Gmail does custom domain hosting
too, you can't simply limit the workaround to treating their well-known domain specially. Given its popularity (near ubiquity) as a freemail
provider these days,
telling users they'll have to get an address somewhere else to interact
with the BTS is unlikely to end well either.
That's certainly not something I'd advocate for. I want us to minimize the PITA for the technically literate without sacrifising general usability.
Any good reason we cannot look at the MX domain (or in the worst case) ASN associated with mailserver IP to special case particularly offensive implementations such as this if looking at the DMARC policy works in the average case?[...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 25:52:41 |
| Calls: | 6,707 |
| Calls today: | 1 |
| Files: | 12,239 |
| Messages: | 5,352,401 |