[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Lack of replies




On January 4, 2024 2:54:28 PM UTC, "Daniel Gröber" <dxld@darkboxed.org> wrote:
>Hi Scott,
>
>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?
>
>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

That's consistent with things I've seen proposed and implemented for mitigation of DMARC issues with mailing lists.  I don't know if the multipart solution has ever been implemented.  From/Mail From definitely have been.

If I were designing it, I would lean heavily on Colin Watson's experience with DMARC mitigation in Launchpad.  I've done some consulting work in this area, but I have never implemented it.

Scott K


Reply to: