Re: Options for temporary operational solution to DMARC problem

[John Leslie <[e-mail]>]

   Alas, I'm hard up for time to address this as it deserves. :^(

   But it _is_ very helpful to move to discussing _particular_ remediations;
so I'll take a shot at it.

Ted Lemon <[e-mail]> wrote:
> 
> My understanding is that there are really four possible approaches:

   IMHO, the universe is bigger than four; but let's see if we _can_
divide "omnia Gallia" into four pieces.

> Bounce messages from sites that have p=REJECT; users at those sites
> have to use some other email address for IETF business.

   This is obviously reasonable and _very_ easy to implement.

   (p=reject _means_ "Please reject this if it didn't come from me.")

> Rewrite From: header on messages from sites that have p=REJECT to point
> at discard address

   This doesn't seem helpful (for various reasons I won't list).

   But why limit this option to "discard" addresses? There's quite a
universe of other rewrite options which could actually reach the sender.

   Also, there's quite a universe of even "discard" addresses which could
properly identify the sender: why not specify that the "discard" address
uniquely identify the actual sender?

> Rewrite all From: headers to point at discard address

   This breaks things for participants experiencing no problems now. I
would hope we could start from a "do no harm" paradigm.

   (I know Ted has requested a list of potential harms: I may get around
to writing one; but I think this is the wrong thread for it. As an operator
I found from painful experience that it's impossible to consider _every_
possible harm before taking a seemingly-harmless action.)

> Rewrite all From: headers to reply to addresses that forward to senders
> for senders with p=REJECT

   Oops! That was option #4.

   Ted certainly left out most of the universe.

   First examle: I consider this a subcase of #2: why should we harm folks
not seeing any problem?

   Second example: there's the universe of "solutions" involving forwarding
to a special-purpose server which could implement different strokes for
different folks... There's no satisfactory reason to limit our consideration
to excluding things our current version of Mailman doesn't know how to do.

   (The rest of the email I'm responding to discusses what "discard" means:
I see no reason to enter that flame-war. Also, I choose not to take sides
among the choices in _this_ email.)

--
John Leslie <[e-mail]>