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

Grant Taylor <[email protected]> writes:

> 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.

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.

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.  application/news-transmission... I dunno.  I'm
pessimistic, but possibly unduly.

> 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?

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.

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

This battle was lost years and years ago for most email.  The majority of
email addresses used by regular people silently throw away messages.
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.

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.

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).

> 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?

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.

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.

-- 
Russ Allbery ([email protected])             <https://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <https://www.eyrie.org/~eagle/faqs/questions.html> explains why.
-- 
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers