add "Auto-Submitted: auto-generated" to generated EMails?

[Grant Taylor]

On 3/12/23 1:29 PM, Russ Allbery wrote:
> So, I admit it's been a long time since I've run a large mail server 
> or had to deal with spam filter tuning directly (I have my own quirky 
> personal thing that's tuned for only me and that doesn't have any of 
> these problems because it has an entirely different set of problems), 
> but my recollection is that spammers *loved* hiding phishing 
> and malware in various types of unusual attachments, particularly 
> attachments that would automatically be decoded by a client.  And as 
> a result spam filters frequently added rules to drop or reject any 
> messages that have that sort of nested structure because they diagnose 
> it as attempting to hide malware from spam filters.

Ya.  There's a slippery slope of servers filtering unknown attachments. 
But message/rfc822 is not an unknown attachment.

There's also a slippery slope of filtering -- what are broadly referred 
to as -- archives, especially those that contain nesting.  But agian, 
message/rfc822 is not an unknown archive and it's an archive (of sorts) 
that is being parsed.  There is some room for detecting and thwarting 
recursion.

But I believe the days of blocking all but a specifically curated list 
of attachments are largely behind us as it has has too much collateral 
damage and is relatively easy to defeat.

> message/rfc822 is recursively inspectable, so hopefully 
> good spam filters do that instead of restrict it and given 
> the prevelance of forwarded mail, you're probably right.

Ya, deep recursion can be a problem.  But it's possible to more 
intelligently reject with a message related to deep recursion.

> application/news-transmission... I dunno.  I'm pessimistic, but 
> possibly unduly.

Fair enough.

Though I think it could be possible to handle it much like 
message/rfc822 if someone wanted to.  But the current deployment will stand.

> The email path up to the point where the moderator sees the message 
> to do something with it.  That can include local post-delivery spam 
> filtering by their ISP.

Thank you for clarifying what I suspected.  That rules out filtering in 
moderation software from the part of the discussion that I'm trying to have.

> This battle was lost years and years ago for most email.  The majority 
> of email addresses used by regular people silently throw away messages.

Let's agree to disagree.

> Sometimes that's in the form of putting them in a spam folder no one 
> looks at, but that's basically the same thing in practice.

I don't think so.  It may be a similar effect, but it's definitely not 
the same thing.

The message is there for the user if they want to get it.  The message 
was not lost in the email network.

> Now, maybe this isn't true of moderators, who are probably odd, unusual 
> people compared to most email users.  But also note that rejecting 
> a moderated group submission is in practice equivalent to silently 
> dropping it; the bounce message is unlikely to go anywhere useful 
> unless you have a particularly obsessive local news administrator.

I don't know what the expected norm is for moderated newsgroups.  With 
my postmaser hat on, I'd somewhat expect a message to go back to the 
purported poser indicating that their message had been rejected.  Though 
this can be a slippery slope for a number of reasons.  Rate limiting and 
Joe jobs come to mind.

> Out of curiosity, I checked, and only two moderators currently use 
> Gmail as a submission address (and I suspect those are both dead 
> groups; almost all moderated gorups are dead).

/me winces

Given Gmail's propensity to filter things, I suspect that moderated 
messages rarely make it into the moderator's mailboxes.

> Sure, but in a sense this just moves the problem.  If we send 
> application/news-transmission to such a server, which then removes the 
> encapsulation and sends the same message as today, we've just made a 
> more complicated version of today's system.  We don't see any benefit 
> until we can send the encapsulated message directly to the moderator, 
> and moderators use a wide variety of different email providers.

To clarify, I was thinking that the encapsulation would happen on the 
news server sending the message for moderation and that the 
decapsulation would happen after SMTP, likely as part of the LDA, on the 
moderator's email system.

> So one way or the other we have to figure out how to get moderators 
> to change their software, and since they're not all going to do that 
> at once, some way to figure out when they have done so and can receive 
> ecapsulated messages.

I feel like moderators are somewhat beholden to keeping their software 
relatively current to be able to do their function as a moderator.

I also feel like there is room to do this on a per-moderated-newsgroup 
basis.

I don't see the need for a Usenet wide flag day.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20230312/4f77ed12/attachment-0001.bin>