Commit graph

9 commits

Author SHA1 Message Date
Mechiel Lukkien
01bcd98a42
add flag to ruleset that indicates a message is forwarded, slightly modifying how junk analysis is done
part of PR #50 by bobobo1618
2023-08-09 22:31:37 +02:00
Mechiel Lukkien
9c31789c56
add option to ruleset to accept incoming spammy messages to a configured mailbox
this is based on @bobobo1618's PR #50. bobobo1618 had the right idea, i tried
including an "is forwarded email" configuration option but that indeed became
too tightly coupled. the "is forwarded" option is still planned, but it is
separate from the "accept rejects to mailbox" config option, because one could
still want to push back on forwarded spam messages.

we do an actual accept, delivering to a configured mailbox, instead of storing
to the rejects mailbox where messages can automatically be removed from.  one
of the goals of mox is not pretend to accept email while actually junking it.
users can still configure delivery to a junk folder (as was already possible),
but aren't deleted automatically. there is still an X-Mox-Reason header in the
message, and a log line about accepting the reject, but otherwise it is
registered and treated as an (smtp) accept.

the ruleset mailbox is still required to keep that explicit. users can specify
Inbox again.

hope this is good enough for PR #50, otherwise we'll change it.
2023-08-09 22:25:10 +02:00
Mechiel Lukkien
e81930ba20
update to latest bstore (with support for an index on a []string: Message.DKIMDomains), and cyclic data types (to be used for Message.Part soon); also adds a context.Context to database operations. 2023-05-22 14:40:36 +02:00
Mechiel Lukkien
08eb1a5472
in store/, change functions from calling panic to returning errors
this is a library package, errors should be explicit. callers had to be careful
when calling these "X" functions. now it's explicit.
2023-04-20 14:16:56 +02:00
Mechiel Lukkien
73bfc58453
fix handling of reputation for messages that were moved out of the rejects mailbox
the idea of the rejects mailbox is to show messages that were rejected.  you can
look there, and if you see a message that should have been delivered, you can
move it to your inbox or archive.  next time a deliver attempt by that user is
attempted, they should be accepted, because you corrected the reject.  but that
wasn't happening, because the reputation-calculation is per-delivery mailbox
(e.g. Inbox) and we look at MailboxOrigID when calculating the reputation. and
that was set to the Rejects mailbox id, so the message wasn't considered. the
same applies to moving messages from Rejects to Junk (to train your filter).

we now keep track of a MailboxDestinedID, that is set to the mailbox that we
would have delivered to if we would not have rejected the message. then, when a
message is moved out of the Rejects mailbox, we change MailboxOrigID to
MailboxDestinedID. this essentially makes the message look like it was
delivered normally.
2023-03-03 13:19:27 +01:00
Mechiel Lukkien
26fcaa17f5
consistently use lower-cased field names for logging lines 2023-02-25 12:37:59 +01:00
Mechiel Lukkien
5c33640aea
consistently use log.Check for logging errors that "should not happen", don't influence application flow
sooner or later, someone will notice one of these messages, which will lead us
to a bug.
2023-02-16 13:22:00 +01:00
Mechiel Lukkien
87854cfde3
change some log levels from info to debug, and use lower case log messages 2023-02-11 23:54:22 +01:00
Mechiel Lukkien
cb229cb6cf
mox! 2023-01-30 14:27:06 +01:00