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

[Grant Taylor]

On 3/12/23 9:45 AM, Russ Allbery wrote:
> It's not that it's not technically fine -- it certainly is -- but the 
> main problem with moderation right now is that the email sent to the 
> moderator gets rejected or discarded along the way by spam filters.

The days of sending an email that appears to be from someone not 
associated with the source server & sending domain are quickly coming to 
a close.  I'd argue that we are well past a point where we could rely on 
that working.  I'd further argue that we are probably past a point where 
we can count on it failing for some domains.

> If we used encapsulation, this would have the advantage of no longer 
> sending email apparently from an address that has no relation to the 
> transmission path (probably good for not triggering spam filters)

Agreed.

> but the disadvantage of looking very weird and having nested 
> encapsulation structure ...

I question how weird the arriving moderated message looks.  Maybe there 
is some nuance to application/news-transmission has compared to 
message/rfc822 (from memory).  But I feel like message/rfc822 is quite 
well supported in fat MUAs and some thin web based MUAs are learning how 
to use it too.  I strongly suspect that application/news-transmission 
can ride message/rfc822's coat tails.

> (very bad for spam filtering because spam filters usually treat all 
> unusual messages as a sign of phishing).

Please elaborate on what spam filtering you're talking about?  Are you 
referring to the spam filtering in the email path?  Or are you referring 
to spam filtering in the moderation stack?

If you're referring to the spam filtering in the email path, then I 
think that message/rfc822 attachments are, and have long been, standard 
enough to not be treated as unknown and therefore blocked.

> And if I were to pick one thing that threatens the moderation system 
> the most, it would be messages going silently missing because the 
> email server of the moderator decides that a lot of the moderation 
> messages are spam and therefore all of them are spam and starts 
> silently throwing them all away.

This makes me think that you're talking about the spam filtering in the 
email path.

Any email server worth it's bits should not be silently throwing away 
messages.

I feel like there is another option that I've not yet seen discussion 
about.  What if moderated messages are sent through email as 
message/rfc822 or application/news-transmission and then on the 
receiving end, a shim of sorts is put in place between the receiving 
email server and the existing moderation stack that detaches the 
attached / moderated message and feeds just the moderated message into 
the moderation software?  Wouldn't that both avoid the now 10+ year old 
email hygiene and conform to the old method that the existing moderation 
stacks are expecting?  I think that this shim would be relatively small 
and easy to use.  I also think that it would quite likely allow the 
existing moderation software stacks to work mostly as they are today.



-- 
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/0abe390e/attachment.bin>