Re: Lack of replies
Hi Jeremy, On Thu, Jan 04, 2024 at 03:11:59PM +, Jeremy Stanley wrote: > 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, 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? > 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. --Daniel signature.asc Description: PGP signature
Re: Lack of replies
Hi Scott, On Wed, Jan 03, 2024 at 05:10:43PM +, 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? 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 signature.asc Description: PGP signature
Re: Community renewal and project obsolescence
Hi, On Fri, Dec 29, 2023 at 08:48:28AM -0800, Antonio Russo wrote: > [...] 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). This is also my experience. A related question I've been pondering: did salsa make this worse for new contributors because some maintainers (seem to) ignore issues/MRs there? I figure for the many people coming from GH style platforms nowerdays being ignored on salsa would be a major discouragment to contributing. > If there were a single thing that could be done, in my mind it would be > to have someone make sure that contributions do not go entirely ignored. I've been thinking along those lines too. Perhaps we just need an aggregator that flags mails/comments/other contributions by new people that are being ignored. I've been meaning to do something like that for the d-mentors list but perhaps we need to think bigger. --Daniel signature.asc Description: PGP signature
