mox/junk.go

434 lines
13 KiB
Go
Raw Normal View History

2023-01-30 16:27:06 +03:00
package main
/*
note: these testdata paths are not in the repo, you should gather some of your
own ham/spam emails.
./mox junk train testdata/train/ham testdata/train/spam
./mox junk train -sent-dir testdata/sent testdata/train/ham testdata/train/spam
./mox junk check 'testdata/check/ham/mail1'
./mox junk test testdata/check/ham testdata/check/spam
./mox junk analyze testdata/train/ham testdata/train/spam
./mox junk analyze -top-words 10 -train-ratio 0.5 -spam-threshold 0.85 -max-power 0.01 -sent-dir testdata/sent testdata/train/ham testdata/train/spam
./mox junk play -top-words 10 -train-ratio 0.5 -spam-threshold 0.85 -max-power 0.01 -sent-dir testdata/sent testdata/train/ham testdata/train/spam
*/
import (
"context"
2023-01-30 16:27:06 +03:00
"flag"
"fmt"
"log"
mathrand "math/rand"
"os"
make mox compile on windows, without "mox serve" but with working "mox localserve" getting mox to compile required changing code in only a few places where package "syscall" was used: for accessing file access times and for umask handling. an open problem is how to start a process as an unprivileged user on windows. that's why "mox serve" isn't implemented yet. and just finding a way to implement it now may not be good enough in the near future: we may want to starting using a more complete privilege separation approach, with a process handling sensitive tasks (handling private keys, authentication), where we may want to pass file descriptors between processes. how would that work on windows? anyway, getting mox to compile for windows doesn't mean it works properly on windows. the largest issue: mox would normally open a file, rename or remove it, and finally close it. this happens during message delivery. that doesn't work on windows, the rename/remove would fail because the file is still open. so this commit swaps many "remove" and "close" calls. renames are a longer story: message delivery had two ways to deliver: with "consuming" the (temporary) message file (which would rename it to its final destination), and without consuming (by hardlinking the file, falling back to copying). the last delivery to a recipient of a message (and the only one in the common case of a single recipient) would consume the message, and the earlier recipients would not. during delivery, the already open message file was used, to parse the message. we still want to use that open message file, and the caller now stays responsible for closing it, but we no longer try to rename (consume) the file. we always hardlink (or copy) during delivery (this works on windows), and the caller is responsible for closing and removing (in that order) the original temporary file. this does cost one syscall more. but it makes the delivery code (responsibilities) a bit simpler. there is one more obvious issue: the file system path separator. mox already used the "filepath" package to join paths in many places, but not everywhere. and it still used strings with slashes for local file access. with this commit, the code now uses filepath.FromSlash for path strings with slashes, uses "filepath" in a few more places where it previously didn't. also switches from "filepath" to regular "path" package when handling mailbox names in a few places, because those always use forward slashes, regardless of local file system conventions. windows can handle forward slashes when opening files, so test code that passes path strings with forward slashes straight to go stdlib file i/o functions are left unchanged to reduce code churn. the regular non-test code, or test code that uses path strings in places other than standard i/o functions, does have the paths converted for consistent paths (otherwise we would end up with paths with mixed forward/backward slashes in log messages). windows cannot dup a listening socket. for "mox localserve", it isn't important, and we can work around the issue. the current approach for "mox serve" (forking a process and passing file descriptors of listening sockets on "privileged" ports) won't work on windows. perhaps it isn't needed on windows, and any user can listen on "privileged" ports? that would be welcome. on windows, os.Open cannot open a directory, so we cannot call Sync on it after message delivery. a cursory internet search indicates that directories cannot be synced on windows. the story is probably much more nuanced than that, with long deep technical details/discussions/disagreement/confusion, like on unix. for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
"path/filepath"
2023-01-30 16:27:06 +03:00
"sort"
"time"
"github.com/mjl-/mox/junk"
"github.com/mjl-/mox/message"
"github.com/mjl-/mox/mlog"
"github.com/mjl-/mox/mox-"
)
type junkArgs struct {
params junk.Params
spamThreshold float64
trainRatio float64
seed bool
sentDir string
databasePath, bloomfilterPath string
debug bool
}
func (a junkArgs) SetLogLevel() {
mox.Conf.Log[""] = mlog.LevelInfo
if a.debug {
mox.Conf.Log[""] = mlog.LevelDebug
}
mlog.SetConfig(mox.Conf.Log)
}
func junkFlags(fs *flag.FlagSet) (a junkArgs) {
fs.BoolVar(&a.params.Onegrams, "one-grams", false, "use 1-grams, i.e. single words, for scoring")
fs.BoolVar(&a.params.Twograms, "two-grams", true, "use 2-grams, i.e. word pairs, for scoring")
fs.BoolVar(&a.params.Threegrams, "three-grams", false, "use 3-grams, i.e. word triplets, for scoring")
fs.Float64Var(&a.params.MaxPower, "max-power", 0.05, "maximum word power, e.g. min 0.05/max 0.95")
fs.Float64Var(&a.params.IgnoreWords, "ignore-words", 0.1, "ignore words with ham/spaminess within this distance from 0.5")
fs.IntVar(&a.params.TopWords, "top-words", 10, "number of top spam and number of top ham words from email to use")
fs.IntVar(&a.params.RareWords, "rare-words", 1, "words are rare if encountered this number during training, and skipped for scoring")
fs.BoolVar(&a.debug, "debug", false, "print debug logging when calculating spam probability")
fs.Float64Var(&a.spamThreshold, "spam-threshold", 0.95, "probability where message is seen as spam")
fs.Float64Var(&a.trainRatio, "train-ratio", 0.5, "part of data to use for training versus analyzing (for analyze only)")
fs.StringVar(&a.sentDir, "sent-dir", "", "directory with sent mails, for training")
fs.BoolVar(&a.seed, "seed", false, "seed prng before analysis")
fs.StringVar(&a.databasePath, "dbpath", "filter.db", "database file for ham/spam words")
fs.StringVar(&a.bloomfilterPath, "bloompath", "filter.bloom", "bloom filter for ignoring unique strings")
return
}
func listDir(dir string) (l []string) {
files, err := os.ReadDir(dir)
xcheckf(err, "listing directory %q", dir)
for _, f := range files {
l = append(l, f.Name())
}
return l
}
func must(f *junk.Filter, err error) *junk.Filter {
xcheckf(err, "filter")
return f
}
func cmdJunkTrain(c *cmd) {
c.unlisted = true
c.params = "hamdir spamdir"
c.help = "Train a junk filter with messages from hamdir and spamdir."
a := junkFlags(c.flag)
args := c.Parse()
if len(args) != 2 {
c.Usage()
}
a.SetLogLevel()
f := must(junk.NewFilter(context.Background(), mlog.New("junktrain"), a.params, a.databasePath, a.bloomfilterPath))
defer func() {
if err := f.Close(); err != nil {
log.Printf("closing junk filter: %v", err)
}
}()
2023-01-30 16:27:06 +03:00
hamFiles := listDir(args[0])
spamFiles := listDir(args[1])
var sentFiles []string
if a.sentDir != "" {
sentFiles = listDir(a.sentDir)
}
err := f.TrainDirs(args[0], a.sentDir, args[1], hamFiles, sentFiles, spamFiles)
xcheckf(err, "train")
}
func cmdJunkCheck(c *cmd) {
c.unlisted = true
c.params = "mailfile"
c.help = "Check an email message against a junk filter, printing the probability of spam on a scale from 0 to 1."
a := junkFlags(c.flag)
args := c.Parse()
if len(args) != 1 {
c.Usage()
}
a.SetLogLevel()
f := must(junk.OpenFilter(context.Background(), mlog.New("junkcheck"), a.params, a.databasePath, a.bloomfilterPath, false))
defer func() {
if err := f.Close(); err != nil {
log.Printf("closing junk filter: %v", err)
}
}()
2023-01-30 16:27:06 +03:00
prob, _, _, _, err := f.ClassifyMessagePath(context.Background(), args[0])
2023-01-30 16:27:06 +03:00
xcheckf(err, "testing mail")
fmt.Printf("%.6f\n", prob)
}
func cmdJunkTest(c *cmd) {
c.unlisted = true
c.params = "hamdir spamdir"
c.help = "Check a directory with hams and one with spams against the junk filter, and report the success ratio."
a := junkFlags(c.flag)
args := c.Parse()
if len(args) != 2 {
c.Usage()
}
a.SetLogLevel()
f := must(junk.OpenFilter(context.Background(), mlog.New("junktest"), a.params, a.databasePath, a.bloomfilterPath, false))
defer func() {
if err := f.Close(); err != nil {
log.Printf("closing junk filter: %v", err)
}
}()
2023-01-30 16:27:06 +03:00
testDir := func(dir string, ham bool) (int, int) {
ok, bad := 0, 0
files, err := os.ReadDir(dir)
xcheckf(err, "readdir %q", dir)
for _, fi := range files {
make mox compile on windows, without "mox serve" but with working "mox localserve" getting mox to compile required changing code in only a few places where package "syscall" was used: for accessing file access times and for umask handling. an open problem is how to start a process as an unprivileged user on windows. that's why "mox serve" isn't implemented yet. and just finding a way to implement it now may not be good enough in the near future: we may want to starting using a more complete privilege separation approach, with a process handling sensitive tasks (handling private keys, authentication), where we may want to pass file descriptors between processes. how would that work on windows? anyway, getting mox to compile for windows doesn't mean it works properly on windows. the largest issue: mox would normally open a file, rename or remove it, and finally close it. this happens during message delivery. that doesn't work on windows, the rename/remove would fail because the file is still open. so this commit swaps many "remove" and "close" calls. renames are a longer story: message delivery had two ways to deliver: with "consuming" the (temporary) message file (which would rename it to its final destination), and without consuming (by hardlinking the file, falling back to copying). the last delivery to a recipient of a message (and the only one in the common case of a single recipient) would consume the message, and the earlier recipients would not. during delivery, the already open message file was used, to parse the message. we still want to use that open message file, and the caller now stays responsible for closing it, but we no longer try to rename (consume) the file. we always hardlink (or copy) during delivery (this works on windows), and the caller is responsible for closing and removing (in that order) the original temporary file. this does cost one syscall more. but it makes the delivery code (responsibilities) a bit simpler. there is one more obvious issue: the file system path separator. mox already used the "filepath" package to join paths in many places, but not everywhere. and it still used strings with slashes for local file access. with this commit, the code now uses filepath.FromSlash for path strings with slashes, uses "filepath" in a few more places where it previously didn't. also switches from "filepath" to regular "path" package when handling mailbox names in a few places, because those always use forward slashes, regardless of local file system conventions. windows can handle forward slashes when opening files, so test code that passes path strings with forward slashes straight to go stdlib file i/o functions are left unchanged to reduce code churn. the regular non-test code, or test code that uses path strings in places other than standard i/o functions, does have the paths converted for consistent paths (otherwise we would end up with paths with mixed forward/backward slashes in log messages). windows cannot dup a listening socket. for "mox localserve", it isn't important, and we can work around the issue. the current approach for "mox serve" (forking a process and passing file descriptors of listening sockets on "privileged" ports) won't work on windows. perhaps it isn't needed on windows, and any user can listen on "privileged" ports? that would be welcome. on windows, os.Open cannot open a directory, so we cannot call Sync on it after message delivery. a cursory internet search indicates that directories cannot be synced on windows. the story is probably much more nuanced than that, with long deep technical details/discussions/disagreement/confusion, like on unix. for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
path := filepath.Join(dir, fi.Name())
prob, _, _, _, err := f.ClassifyMessagePath(context.Background(), path)
2023-01-30 16:27:06 +03:00
if err != nil {
log.Printf("classify message %q: %s", path, err)
continue
}
if ham && prob < a.spamThreshold || !ham && prob > a.spamThreshold {
ok++
} else {
bad++
}
if ham && prob > a.spamThreshold {
fmt.Printf("ham %q: %.4f\n", path, prob)
}
if !ham && prob < a.spamThreshold {
fmt.Printf("spam %q: %.4f\n", path, prob)
}
}
return ok, bad
}
nhamok, nhambad := testDir(args[0], true)
nspamok, nspambad := testDir(args[1], false)
fmt.Printf("total ham, ok %d, bad %d\n", nhamok, nhambad)
fmt.Printf("total spam, ok %d, bad %d\n", nspamok, nspambad)
fmt.Printf("specifity (true negatives, hams identified): %.6f\n", float64(nhamok)/(float64(nhamok+nhambad)))
fmt.Printf("sensitivity (true positives, spams identified): %.6f\n", float64(nspamok)/(float64(nspamok+nspambad)))
fmt.Printf("accuracy: %.6f\n", float64(nhamok+nspamok)/float64(nhamok+nhambad+nspamok+nspambad))
}
func cmdJunkAnalyze(c *cmd) {
c.unlisted = true
c.params = "hamdir spamdir"
c.help = `Analyze a directory with ham messages and one with spam messages.
A part of the messages is used for training, and remaining for testing. The
messages are shuffled, with optional random seed.`
a := junkFlags(c.flag)
args := c.Parse()
if len(args) != 2 {
c.Usage()
}
a.SetLogLevel()
f := must(junk.NewFilter(context.Background(), mlog.New("junkanalyze"), a.params, a.databasePath, a.bloomfilterPath))
defer func() {
if err := f.Close(); err != nil {
log.Printf("closing junk filter: %v", err)
}
}()
2023-01-30 16:27:06 +03:00
hamDir := args[0]
spamDir := args[1]
hamFiles := listDir(hamDir)
spamFiles := listDir(spamDir)
var rand *mathrand.Rand
if a.seed {
rand = mathrand.New(mathrand.NewSource(time.Now().UnixMilli()))
} else {
rand = mathrand.New(mathrand.NewSource(0))
}
shuffle := func(l []string) {
count := len(l)
for i := range l {
n := rand.Intn(count)
l[i], l[n] = l[n], l[i]
}
}
shuffle(hamFiles)
shuffle(spamFiles)
ntrainham := int(a.trainRatio * float64(len(hamFiles)))
ntrainspam := int(a.trainRatio * float64(len(spamFiles)))
trainHam := hamFiles[:ntrainham]
trainSpam := spamFiles[:ntrainspam]
testHam := hamFiles[ntrainham:]
testSpam := spamFiles[ntrainspam:]
var trainSent []string
if a.sentDir != "" {
trainSent = listDir(a.sentDir)
}
err := f.TrainDirs(hamDir, a.sentDir, spamDir, trainHam, trainSent, trainSpam)
xcheckf(err, "train")
testDir := func(dir string, files []string, ham bool) (ok, bad, malformed int) {
for _, name := range files {
make mox compile on windows, without "mox serve" but with working "mox localserve" getting mox to compile required changing code in only a few places where package "syscall" was used: for accessing file access times and for umask handling. an open problem is how to start a process as an unprivileged user on windows. that's why "mox serve" isn't implemented yet. and just finding a way to implement it now may not be good enough in the near future: we may want to starting using a more complete privilege separation approach, with a process handling sensitive tasks (handling private keys, authentication), where we may want to pass file descriptors between processes. how would that work on windows? anyway, getting mox to compile for windows doesn't mean it works properly on windows. the largest issue: mox would normally open a file, rename or remove it, and finally close it. this happens during message delivery. that doesn't work on windows, the rename/remove would fail because the file is still open. so this commit swaps many "remove" and "close" calls. renames are a longer story: message delivery had two ways to deliver: with "consuming" the (temporary) message file (which would rename it to its final destination), and without consuming (by hardlinking the file, falling back to copying). the last delivery to a recipient of a message (and the only one in the common case of a single recipient) would consume the message, and the earlier recipients would not. during delivery, the already open message file was used, to parse the message. we still want to use that open message file, and the caller now stays responsible for closing it, but we no longer try to rename (consume) the file. we always hardlink (or copy) during delivery (this works on windows), and the caller is responsible for closing and removing (in that order) the original temporary file. this does cost one syscall more. but it makes the delivery code (responsibilities) a bit simpler. there is one more obvious issue: the file system path separator. mox already used the "filepath" package to join paths in many places, but not everywhere. and it still used strings with slashes for local file access. with this commit, the code now uses filepath.FromSlash for path strings with slashes, uses "filepath" in a few more places where it previously didn't. also switches from "filepath" to regular "path" package when handling mailbox names in a few places, because those always use forward slashes, regardless of local file system conventions. windows can handle forward slashes when opening files, so test code that passes path strings with forward slashes straight to go stdlib file i/o functions are left unchanged to reduce code churn. the regular non-test code, or test code that uses path strings in places other than standard i/o functions, does have the paths converted for consistent paths (otherwise we would end up with paths with mixed forward/backward slashes in log messages). windows cannot dup a listening socket. for "mox localserve", it isn't important, and we can work around the issue. the current approach for "mox serve" (forking a process and passing file descriptors of listening sockets on "privileged" ports) won't work on windows. perhaps it isn't needed on windows, and any user can listen on "privileged" ports? that would be welcome. on windows, os.Open cannot open a directory, so we cannot call Sync on it after message delivery. a cursory internet search indicates that directories cannot be synced on windows. the story is probably much more nuanced than that, with long deep technical details/discussions/disagreement/confusion, like on unix. for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
path := filepath.Join(dir, name)
prob, _, _, _, err := f.ClassifyMessagePath(context.Background(), path)
2023-01-30 16:27:06 +03:00
if err != nil {
// log.Infof("%s: %s", path, err)
malformed++
continue
}
if ham && prob < a.spamThreshold || !ham && prob > a.spamThreshold {
ok++
} else {
bad++
}
if ham && prob > a.spamThreshold {
fmt.Printf("ham %q: %.4f\n", path, prob)
}
if !ham && prob < a.spamThreshold {
fmt.Printf("spam %q: %.4f\n", path, prob)
}
}
return
}
nhamok, nhambad, nmalformedham := testDir(args[0], testHam, true)
nspamok, nspambad, nmalformedspam := testDir(args[1], testSpam, false)
fmt.Printf("training done, nham %d, nsent %d, nspam %d\n", ntrainham, len(trainSent), ntrainspam)
fmt.Printf("total ham, ok %d, bad %d, malformed %d\n", nhamok, nhambad, nmalformedham)
fmt.Printf("total spam, ok %d, bad %d, malformed %d\n", nspamok, nspambad, nmalformedspam)
fmt.Printf("specifity (true negatives, hams identified): %.6f\n", float64(nhamok)/(float64(nhamok+nhambad)))
fmt.Printf("sensitivity (true positives, spams identified): %.6f\n", float64(nspamok)/(float64(nspamok+nspambad)))
fmt.Printf("accuracy: %.6f\n", float64(nhamok+nspamok)/float64(nhamok+nhambad+nspamok+nspambad))
}
func cmdJunkPlay(c *cmd) {
c.unlisted = true
c.params = "hamdir spamdir"
c.help = "Play messages from ham and spam directory according to their time of arrival and report on junk filter performance."
a := junkFlags(c.flag)
args := c.Parse()
if len(args) != 2 {
c.Usage()
}
a.SetLogLevel()
f := must(junk.NewFilter(context.Background(), mlog.New("junkplay"), a.params, a.databasePath, a.bloomfilterPath))
defer func() {
if err := f.Close(); err != nil {
log.Printf("closing junk filter: %v", err)
}
}()
2023-01-30 16:27:06 +03:00
// We'll go through all emails to find their dates.
type msg struct {
dir, filename string
ham, sent bool
t time.Time
}
var msgs []msg
var nbad, nnodate, nham, nspam, nsent int
jlog := mlog.New("junkplay")
2023-01-30 16:27:06 +03:00
scanDir := func(dir string, ham, sent bool) {
for _, name := range listDir(dir) {
make mox compile on windows, without "mox serve" but with working "mox localserve" getting mox to compile required changing code in only a few places where package "syscall" was used: for accessing file access times and for umask handling. an open problem is how to start a process as an unprivileged user on windows. that's why "mox serve" isn't implemented yet. and just finding a way to implement it now may not be good enough in the near future: we may want to starting using a more complete privilege separation approach, with a process handling sensitive tasks (handling private keys, authentication), where we may want to pass file descriptors between processes. how would that work on windows? anyway, getting mox to compile for windows doesn't mean it works properly on windows. the largest issue: mox would normally open a file, rename or remove it, and finally close it. this happens during message delivery. that doesn't work on windows, the rename/remove would fail because the file is still open. so this commit swaps many "remove" and "close" calls. renames are a longer story: message delivery had two ways to deliver: with "consuming" the (temporary) message file (which would rename it to its final destination), and without consuming (by hardlinking the file, falling back to copying). the last delivery to a recipient of a message (and the only one in the common case of a single recipient) would consume the message, and the earlier recipients would not. during delivery, the already open message file was used, to parse the message. we still want to use that open message file, and the caller now stays responsible for closing it, but we no longer try to rename (consume) the file. we always hardlink (or copy) during delivery (this works on windows), and the caller is responsible for closing and removing (in that order) the original temporary file. this does cost one syscall more. but it makes the delivery code (responsibilities) a bit simpler. there is one more obvious issue: the file system path separator. mox already used the "filepath" package to join paths in many places, but not everywhere. and it still used strings with slashes for local file access. with this commit, the code now uses filepath.FromSlash for path strings with slashes, uses "filepath" in a few more places where it previously didn't. also switches from "filepath" to regular "path" package when handling mailbox names in a few places, because those always use forward slashes, regardless of local file system conventions. windows can handle forward slashes when opening files, so test code that passes path strings with forward slashes straight to go stdlib file i/o functions are left unchanged to reduce code churn. the regular non-test code, or test code that uses path strings in places other than standard i/o functions, does have the paths converted for consistent paths (otherwise we would end up with paths with mixed forward/backward slashes in log messages). windows cannot dup a listening socket. for "mox localserve", it isn't important, and we can work around the issue. the current approach for "mox serve" (forking a process and passing file descriptors of listening sockets on "privileged" ports) won't work on windows. perhaps it isn't needed on windows, and any user can listen on "privileged" ports? that would be welcome. on windows, os.Open cannot open a directory, so we cannot call Sync on it after message delivery. a cursory internet search indicates that directories cannot be synced on windows. the story is probably much more nuanced than that, with long deep technical details/discussions/disagreement/confusion, like on unix. for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
path := filepath.Join(dir, name)
2023-01-30 16:27:06 +03:00
mf, err := os.Open(path)
xcheckf(err, "open %q", path)
fi, err := mf.Stat()
xcheckf(err, "stat %q", path)
p, err := message.EnsurePart(jlog, false, mf, fi.Size())
2023-01-30 16:27:06 +03:00
if err != nil {
nbad++
if err := mf.Close(); err != nil {
log.Printf("closing message file: %v", err)
}
2023-01-30 16:27:06 +03:00
continue
}
if p.Envelope.Date.IsZero() {
nnodate++
if err := mf.Close(); err != nil {
log.Printf("closing message file: %v", err)
}
2023-01-30 16:27:06 +03:00
continue
}
if err := mf.Close(); err != nil {
log.Printf("closing message file: %v", err)
}
2023-01-30 16:27:06 +03:00
msgs = append(msgs, msg{dir, name, ham, sent, p.Envelope.Date})
if sent {
nsent++
} else if ham {
nham++
} else {
nspam++
}
}
}
hamDir := args[0]
spamDir := args[1]
scanDir(hamDir, true, false)
scanDir(spamDir, false, false)
if a.sentDir != "" {
scanDir(a.sentDir, true, true)
}
// Sort the messages, earliest first.
sort.Slice(msgs, func(i, j int) bool {
return msgs[i].t.Before(msgs[j].t)
})
// Play all messages as if they are coming in. We predict their spaminess, check if
// we are right. And we train the system with the result.
var nhamok, nhambad, nspamok, nspambad int
play := func(msg msg) {
var words map[string]struct{}
make mox compile on windows, without "mox serve" but with working "mox localserve" getting mox to compile required changing code in only a few places where package "syscall" was used: for accessing file access times and for umask handling. an open problem is how to start a process as an unprivileged user on windows. that's why "mox serve" isn't implemented yet. and just finding a way to implement it now may not be good enough in the near future: we may want to starting using a more complete privilege separation approach, with a process handling sensitive tasks (handling private keys, authentication), where we may want to pass file descriptors between processes. how would that work on windows? anyway, getting mox to compile for windows doesn't mean it works properly on windows. the largest issue: mox would normally open a file, rename or remove it, and finally close it. this happens during message delivery. that doesn't work on windows, the rename/remove would fail because the file is still open. so this commit swaps many "remove" and "close" calls. renames are a longer story: message delivery had two ways to deliver: with "consuming" the (temporary) message file (which would rename it to its final destination), and without consuming (by hardlinking the file, falling back to copying). the last delivery to a recipient of a message (and the only one in the common case of a single recipient) would consume the message, and the earlier recipients would not. during delivery, the already open message file was used, to parse the message. we still want to use that open message file, and the caller now stays responsible for closing it, but we no longer try to rename (consume) the file. we always hardlink (or copy) during delivery (this works on windows), and the caller is responsible for closing and removing (in that order) the original temporary file. this does cost one syscall more. but it makes the delivery code (responsibilities) a bit simpler. there is one more obvious issue: the file system path separator. mox already used the "filepath" package to join paths in many places, but not everywhere. and it still used strings with slashes for local file access. with this commit, the code now uses filepath.FromSlash for path strings with slashes, uses "filepath" in a few more places where it previously didn't. also switches from "filepath" to regular "path" package when handling mailbox names in a few places, because those always use forward slashes, regardless of local file system conventions. windows can handle forward slashes when opening files, so test code that passes path strings with forward slashes straight to go stdlib file i/o functions are left unchanged to reduce code churn. the regular non-test code, or test code that uses path strings in places other than standard i/o functions, does have the paths converted for consistent paths (otherwise we would end up with paths with mixed forward/backward slashes in log messages). windows cannot dup a listening socket. for "mox localserve", it isn't important, and we can work around the issue. the current approach for "mox serve" (forking a process and passing file descriptors of listening sockets on "privileged" ports) won't work on windows. perhaps it isn't needed on windows, and any user can listen on "privileged" ports? that would be welcome. on windows, os.Open cannot open a directory, so we cannot call Sync on it after message delivery. a cursory internet search indicates that directories cannot be synced on windows. the story is probably much more nuanced than that, with long deep technical details/discussions/disagreement/confusion, like on unix. for "mox localserve" we can get away with making syncdir a no-op.
2023-10-14 11:54:07 +03:00
path := filepath.Join(msg.dir, msg.filename)
2023-01-30 16:27:06 +03:00
if !msg.sent {
var prob float64
var err error
prob, words, _, _, err = f.ClassifyMessagePath(context.Background(), path)
2023-01-30 16:27:06 +03:00
if err != nil {
nbad++
return
}
if msg.ham {
if prob < a.spamThreshold {
nhamok++
} else {
nhambad++
}
} else {
if prob > a.spamThreshold {
nspamok++
} else {
nspambad++
}
}
} else {
mf, err := os.Open(path)
xcheckf(err, "open %q", path)
defer func() {
if err := mf.Close(); err != nil {
log.Printf("closing message file: %v", err)
}
}()
2023-01-30 16:27:06 +03:00
fi, err := mf.Stat()
xcheckf(err, "stat %q", path)
p, err := message.EnsurePart(jlog, false, mf, fi.Size())
2023-01-30 16:27:06 +03:00
if err != nil {
log.Printf("bad sent message %q: %s", path, err)
return
}
words, err = f.ParseMessage(p)
if err != nil {
log.Printf("bad sent message %q: %s", path, err)
return
}
}
if err := f.Train(context.Background(), msg.ham, words); err != nil {
2023-01-30 16:27:06 +03:00
log.Printf("train: %s", err)
}
}
for _, m := range msgs {
play(m)
}
err := f.Save()
xcheckf(err, "saving filter")
fmt.Printf("completed, nham %d, nsent %d, nspam %d, nbad %d, nwithoutdate %d\n", nham, nsent, nspam, nbad, nnodate)
fmt.Printf("total ham, ok %d, bad %d\n", nhamok, nhambad)
fmt.Printf("total spam, ok %d, bad %d\n", nspamok, nspambad)
fmt.Printf("specifity (true negatives, hams identified): %.6f\n", float64(nhamok)/(float64(nhamok+nhambad)))
fmt.Printf("sensitivity (true positives, spams identified): %.6f\n", float64(nspamok)/(float64(nspamok+nspambad)))
fmt.Printf("accuracy: %.6f\n", float64(nhamok+nspamok)/float64(nhamok+nhambad+nspamok+nspambad))
}