Ted,
Thanks for the comprehensive list.
I agree with your conclusions.
Cheers,
Andy
On Thu, Nov 3, 2016 at 6:21 PM, Ted Lemon <mellon(_at_)fugue(_dot_)com> wrote:
My understanding is that there are really four possible approaches:
1. Bounce messages from sites that have p=REJECT; users at those sites
have to use some other email address for IETF business.
2. Rewrite From: header on messages from sites that have p=REJECT to
point at discard address
3. Rewrite all From: headers to point at discard address
4. Rewrite all From: headers to reply to addresses that forward to
senders for senders with p=REJECT
What it means to rewrite a From: header to point at a discard address is
probably that the mailbox name will be changed to some admin address that
is silently discarded, and the display name will be changed to add "via
mailing-list". So e.g., Ted Lemon <mellon(_at_)fugue(_dot_)com> would be
changed
to Ted Lemon via ietf <drop-silently(_at_)ietf(_dot_)org>. For extra credit,
drop-silently(_at_)ietf(_dot_)org could drop silently if the To: and Cc:
headers
contain multiple addresses, but generate a bounce if the _only_ address is
drop-silently(_at_)ietf(_dot_)org. There would probably need to be a list
ID so
that the bounce message could make sense—it would probably say something
like "you tried to reply to sender, but it didn’t work, here’s why, here’s
what to do."
Advantages of 1:
- Relatively easy
- Does not alter sender information, so no unexpected behavior in MUAs
- Supported by mailman.
Disadvantages of 1:
- Substantial inconvenience for people who are unfortunate enough to
work for orgs that use p=REJECT
- Possible snowball effect if more sites adopt p=REJECT (e.g.,
gmail.com).
- Requires checking p=REJECT when processing mail
Advantages of 2:
- Does not inconvenience senders from sites with p=REJECT
- Minimizes whose headers are rewritten
- Supported by mailman
Disadvantages of 2:
- Lots of moving parts (e.g., have to check p=REJECT when processing
mail)
- Email from senders at sites with p=REJECT can’t be sorted the same
way mail from other senders can be; inconvenient for users who use
rule-based sorting on IETF lists
- Harder to send off-list replies if sender is from site with
p=REJECT; reply-to-sender in MUA will be handled as described above.
Advantages of 3:
- Does not inconvenience senders from sites with p=REJECT
- Does not require checking to see whether p=REJECT is in effect for a
particular user
Disadvantages of 3:
- Email from all senders can no longer be sorted as before, so
everybody’s procmail filters, etc, break maximally
- Harder to send off-list replies, reply-to-sender in MUA will be
handled as described above.
Advantages of 4:
- Doesn’t inconvenience any mailing list user
- Behavior is as it always was
Disadvantages of 4:
- Requires state for each sender from a site with p=REJECT
- Possible resource exhaustion attack
- Probably requires substantial programming and testing work; risk of
data loss
- Would take a long time to deploy; might not be quicker than waiting
for ARC outcome
I think it is really up to the IESG to decide which of these plans to
adopt. However, if people are interested in talking about what to do, I
think this is a decent enumeration of the options (please correct me if I
am wrong). My personal opinion is that option 2 is the least disruptive
option, and I believe it is supported by mailman. Option 1 is the most
technically correct option that we have right now, but I think technical
correctness is not the right value to optimize for _right now_. Technical
correctness can be restored once ARC completes and is deployed at the sites
we are having trouble with; right now, I think the solution that removes
the most pain is the best one.
I mentioned options 3 and 4 for completeness, but I think 3 is
unnecessarily heavy, and option 4 is too much work.