Hmm, I was mostly thinking “oh, you already have technical measures against backscatter” (like sending the bounce only when SPF/DKIM are defined and match), and deducing from there that maybe the same protection granted to a “moderation pending” email would work?
Basically, I'm thinking “moderation pending” is overall the same as “permission denied,” but then maybe spam moderation would be a source of too much backscatter? I haven't made stats on how many spams come with existing and matching spf/dkim policies but spoofed bounce address, but I wouldn't think it is high, thanks to spf/dkim being designed to prevent spoofing? (and “backscatter” to a spammer-owned email address doesn't sound like a big deal to me) On 11/23/2017 02:47 AM, Brandon Long wrote: > So, you're answer to whether we should make more backscatter is that we > already make some so what's the big deal? > > Hmm > > This seems like the most obvious case of backscatter, when we think > something is spam. > > I never liked the design choice which said permission failure had to > look like nonexistence, especially when permission can only be decided > based on the full message, so it can't be done at rcpt to time. > > Brandon > > On Wed, Nov 22, 2017, 4:21 PM Leo Gaspard <mailop@leo.gaspard.ninja> wrote: > > On 11/22/2017 04:51 PM, Brandon Long wrote: > > If you send me the full headers I can take a look, but yes, sounds > like > > either moderation or spam moderation. > > So after checking, it was indeed spam moderation. Thanks Brandon! > > I'd just like to raise the issue of whether to send a “your message is > pending moderation” answering messages that are enqueued to the > moderator's queue. > > To me, the main advantage is not letting people think their messages are > dropped (I plead guilty to this one), and the main drawback is the risk > of backscatter. > > However, for backscatter, currently google groups do send a bounce when > an email is sent to a moderation-only group from a non-in-group email > address: > > ----------8<----------8<---------- > From: Mail Delivery Subsystem <mailer-dae...@google.com > <mailto:mailer-dae...@google.com>> > Subject: Delivery Status Notification (Failure) > > Hello [source email address], > > We're writing to let you know that the group you tried to contact > ([group name]) may not exist, or you may not have permission to post > messages to the group. A few more details on why you weren't able to > post: > > * You might have spelled or formatted the group name incorrectly. > * The owner of the group may have removed this group. > * You may need to join the group before receiving permission to post. > * This group may not be open to posting. > > If you have questions related to this or any other Google Group, visit > the Help Center at https://groups.google.com/support/. > > Thanks, > > Google Groups > > > > ----- Original message ----- > > [full copy with headers of the original message] > ---------->8---------->8---------- > > So, currently google groups are already a source of potential > backscatter, as far as I understand. > > I guess there are countermeasures in place to avoid doing this for any > incoming mail, and so believe with the same countermeasures a “message > pending moderation” email could be sent without additional damage? > > Just in case there are no countermeasures (and maybe this would deserve > another thread, if it is controversial?), a simple countermeasure could, > I guess, be to check the incoming message passes SPF and only send a > bounce in this case: if SPF passes then the MAIL FROM email is > legitimate, and thus the bounce would be sent to the right address. (If > the bounce is sent to the From: address checking DKIM passed would sound > equally right to me). > This would amount to a header check, as by the time the email is put in > the moderation queue its headers already include the spf=pass dkim=pass > dmarc=pass from ARC-Authentication-Results (if I can guess how the > moderation queue is handled based on message timings from the headers). > > What do you all think about this? > > _______________________________________________ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
