Ted, *:
a) Fluffy's original mail also described illigitimate senders DOS
attacks to auto-unsubscribe IETF mailing list participants.
I only remember two answers in this long thread to that question:
RTFML from JohnL and "have mailman do DMARC rejections itself" from mcr.
Has this problem been observed (auto-unsubscribe because of explicit
attacks ?) How would it change under your proposed options
(you seem to only focus on the impact of legitimiate p=reject senders).
To me, mcr's recommendation sounds good, and i don't believe ARC adoption
would ever be fast/complete enough to to not do it but "just wait for ARC".
b) Given how your proposed solutions have all pro/cons, i would strongly
suggest to also consider first options to raise awareness to the
problem via mailman:
Eg: Does IETF mailman send any mails to senders or receivers to
inform them if/when they are DMARC victims ? And warn of potentially
impending auto-unsubscribe to receivers ... ? Or give suggestions/hints
to senders/receiver including eg:
- use a DMARC-free email account for sending
- Check email archives or add another receiver account with
digest if you fear you're loosing emails due to DMARC issues
- subscribe to dmarc(_at_)ietf(_dot_)org if you're technically versed and
want
to contribute
Typically all mailman error messages are totally cryptic and
non-decipherable for non-mail-gurus.
c) Wrt to your options:
- do DMARC check in mailman, reject p-reject failures (mcr)
- provide good visibility on rejection
- rewrite accepted DMARC p=reject sender address stateless, eg:
orig-sender%orig-domain(_at_)dmarc-reply(_dot_)ietf(_dot_)org
Ideally, do this only if the sender has opted in, eg: via
a subscription option. Of course the reply alias should only work
for mailing list participants so it ha the same DOS protection as
other mailman forwarders.
Kinda a mix of your 2+4
Cheers
Toerless
On Thu, Nov 03, 2016 at 06:21:45PM -0400, Ted Lemon wrote:
My understanding is that there are really four possible approaches:
Bounce messages from sites that have p=REJECT; users at those sites have to
use some other email address for IETF business.
Rewrite From: header on messages from sites that have p=REJECT to point at
discard address
Rewrite all From: headers to point at discard address
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
<mailto:mellon(_at_)fugue(_dot_)com>> would be changed to Ted Lemon via ietf
<drop-silently(_at_)ietf(_dot_)org
<mailto:drop-silently(_at_)ietf(_dot_)org>>. For extra credit,
drop-silently(_at_)ietf(_dot_)org <mailto: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 <mailto: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
<http://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.
--
---
tte(_at_)cs(_dot_)fau(_dot_)de