Re: resending bounces: DKIM and Message-ID:

[Greg Troxel <gdt@lexort.com>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Greg Troxel <gdt@lexort.com> writes:

>> I'm basically saying that wanting to resend a bounce exactly feels rare,
>> and that even if it is the same, you want a fresh message-id and a fresh
>> dkim signature so that you don't have problems from state created
>> perhaps wrongly by the original message.
>
> I have a solution! Potentially. When a user runs SDb, we first prompt
> "Edit original (bounced) message before sending?"
>
> If the user chooses "no", we resend immediately using `message-bounce',
> including the original Message-ID and all that jazz (though still
> respecting `message-ignore-bounced-headers'). If the user chooses "yes",
> we sneakily delegate to SDe, dumping them in a *Unsent Message* buffer.

> This way the user is the one deciding "is this a new message or not?" If
> they decide to edit, they're essentially sending a new message.
>
> WDYT?

That could be ok.   I personally feel that SDb without editing is so
rare as to not be worth accomodating.   And, the headers that are
included are potentially added by other systems.   I would like to see
only headers that were present when the message was sent from gnus (or
whatever MUA) to the originating MTA.

Which makes me think that all of this should tend to keep fewer headers,
and not keep those added by intermedaite systems.

However this is getting unreasonably complicated and the idea of
explicitly dropping troublesome headers and hoping that the residual
issues are less than the effort it would take to resolve this 100%
perfectly.