Re: resending bounces: DKIM and Message-ID:

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Greg Troxel <gdt@lexort.com> writes:

> 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.

At this point it feels like we're just turning SDb into SDe, except an
SDe that works on a received bounce rather than the user's original sent
message. I understand that all this is annoying, and points to a real
issue, but it also doesn't quite seem worth disturbing
compatibility/expected behavior. WDYT?