Re: resending bounces: DKIM and Message-ID:

[Greg Troxel <gdt@lexort.com>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

>> 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.
>
> Great! And yes, let's add it to the default. I poked around briefly for
> other signing-type headers that we might want to delete, but haven't
> come up with anything that puts an actual signature in the headers.
> Hashcash, maybe?

I suppose you could add hashcash, but I perceive hashcash to be
historical.  Is anybody still using it?  (I used to have it configured
both generated and scored on receipt.)

>>> 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.
>
> The command is supposed to be run on your own original message (in Sent
> or wherever), not the bounce that you got back. I think if you do that
> it should behave correctly.

Sure, and it should probably also remove DKIM, but because it's more
likely from Sent it probably won't be there.

>> 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.
>
> Okay, I'd been assuming the most common case was the not-yet-subscribed
> case. Or some other transient system-level failure, ie not an actual
> change to the message itself.

My experience is that almost all bounces are because I typed something
wrong.  Transient failures are once in a blue moon.  Not being
subscribed, subscribing and resending (vs just giving up) is rare for
me.  But I believe this is different for different PEBKAC specimens.

>>   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.
>
> I'm still coming back to the distinction between "resend-edit" and
> "resend-bounced". In terms of the commands themselves, I think they do
> the right thing: The first essentially creates a new message from an
> earlier template (which fits with the fact that it's called from your
> "Sent" folder/group), meaning that it regenerates most of the headers.

But still, the question is: Is that new message the same or not?

> The second command just repeats an earlier message, and preserves all
> the headers it can. To me it feels right that the first case gets a new
> Message-ID, and the second case doesn't.
>
> The problem is that, in your example situation, the message has been
> bounced, but the appropriate command to deal with it is actually
> "resend-edit".

It's really not that, but gnus-summary-resend-bounced-mail-edit, a
variant where you can change it, vs a variant where you can't
(readonly).  The current code lets you edit it, and I 99% do edit it, so
that seems normal.

> In a sense, it's a documentation issue: "Use `resend-bounced' unless you
> need to edit anything in the message, in that case use `resend-edit'".
> But it's unreasonable to expect anyone to keep all that in mind.

Yes, and it's further unreasoable that there are really 4 options as a
product of two choices
  modify vs not
  extract from bounce vs operate on self-bcc or Sent

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.