Re: resending bounces: DKIM and Message-ID:

[Greg Troxel <gdt@lexort.com>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> The proposal is to fix this by:
>>
>>   * in gnus
>>     - adding a list of headers which should be removed from bounce
>>       messages when doing gnus-summary-resend-bounced-mail
>
> I believe this is called `message-ignored-bounced-headers'! It does not
> currently include DKIM-Signature, but maybe it should. I haven't
> actually tested this, but looking at the code I believe it should take
> effect in this situation.

Wow, exactly the right thing.   Yes, I added DKIM-Signature in .emacs:

      (setq message-ignored-bounced-headers
	    "^\\(Received\\|Return-Path\\|Delivered-To\\|DKIM-Signature\\):")

and now SDb omits it.

I would say that the default value should be changed to include
DKIM-Signature.   If the message is altered at all it becomes invalid,
and the new message should get signed the same way, so having two valid
signatures one of which has an incorrect time is just not helpful.  I
cannot think of ever wanting to keep it.  It's not quite like Received
but it's close.

>>     - set the list to Message-ID and DKIM-Signature to start with
>
> This is deeper in the protocol weeds than I usually go, so this is a bit
> tentative, but I will note that there's a separate
> `gnus-summary-resend-message-edit' command, which will not preserve the
> Message-ID header. I think there's an argument to be made that, if
> you're re-sending the bounced the message, it is in fact the same
> message over again. If you're changing the "To:" or other headers, on
> the other hand, that sounds like a new message, and you should be using
> "S D e" instead.

Interesting point.  When I run that on the bounce, I am queued up to
re-send the bounce message, not the original message that was included
in the bounce.

> What do you think?

I would say that 99% of the time, when you are resending a bounce, you
are fixing what you did wrong that caused it to bounce, like mistyping a
To/CC.  In which case the new message is..  a new message.  In rare
cases, you have fixed something else (like the receiving system such as
subscribing or your MTA) and are sending the exact same message.

I think:

  Some people treat messages with the same message-id as dups.  I am not
  sure that's 100% legit but I know it happens.

  If nobody got the message, it doesn't really matter if the new
  message-id is the same or not.

  If the message is identical, and somebody got it twice (because their
  addr was right the first time), it might be marginally better to have
  the same message-id.  But doing this right requires keeping track of
  the original buffer contents and later dropping message-id if there is
  even 1 byte different, and that just feels too hard/fragile to let
  somebody filter a dup in such an edge case.

  If some people got the message and some didn't, because the original
  sender typoed one of the addresses, then the question is if the
  original successful recipients should get
    A) a 2nd copy with the same message-id and updated headers
    B) a 2nd copy with a new message-id and updated headers
    C) nothing
    D) something else
  I lean to B, because they should realize a typo was fixed, especially
  if the person added [resending due to address typo], and should thus
  delete the first and keep the second for replies.