On 2022-01-11 03:29, Jaroslaw Rafa via mailop wrote:
Dnia 10.01.2022 o godz. 19:30:02 Dave Warren via mailop pisze:
How would it know the difference if it was Thunderbird, or the user?
You can guess by timing.
If the message is moved to spam folder immediately after being fetched by
client, then it is an automated filter action. If there is at least a few
seconds delay, then it is probably the user manually moving the message into
spam folder (the user needs some time to look at least at the subject of
the message and click the appropriate button).
Or conversely, what steps should an IMAP user take to report spam
properly?
Maybe set up an address like spamrep...@your-provider.com where users should
forward all messages they consider to be spam?
Over the last 1-2 decades I implemented just this! A spam/non-spam
address that users could forward mail to, plus dedicated shared
#ReportAsSpam #ReportAsNotSpam folders that users could use.
I don't think I managed to get a single person to forward an EML file to
the spam/non-spam addresses even once in over a decade.
Teaching users to forward spam is just bad for a whole number of reasons
and I wouldn't do it today. Even though the intent is only an internal
"send your spam to spam@localdomain or spam@provider-name", good luck
getting users to understand that forwarding spam is otherwise bad. The
"we hacked your email and watched you do private things" are especially
bad because users legitimately get worried and forward these to their
partners or others to get advice.
Forwarded non-spam without the EML was useful if their client bothered
to forward enough of the original From header that I could toss the
address on a "User wants this mail" list, although that wasn't
particularly scalable, and didn't actually give me anything that webmail
address books and whitelisting outbound mail didn't also give me.
User's "Archive" folders seem to be a good proxy for not-spam, if a user
had a lot of messages over a reasonable period of time in their Archive
folder I'd point SA's bayesian learning at it.
A few used the #ReportAs shared folders. This was safer because it
didn't use their mailbox's own Junk folder so it required explicit
action. These got used by the webmail interface too so it is hard to
judge if users explicitly used the folders. If we were to redesign
protocols from scratch, having an explicit "The user marked this as junk
and wants to unsubscribe, or have it blocked, or file a report" would
all be excellent things, but outside of webmail providers who control
their servers and interface, this won't be a thing.
(EML, meaning anything that attached the original message with headers
and at least some body).
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
