On 2004-07-02 10:16:57 -0400, Alan DeKok wrote: > "Peter J. Holzer" <hjp-asrg at hjp.at> wrote: > > I believe you misunderstood Markus: The Recipient's MTA should block > > (reject) the message instead of accepting it and then send it to > > /dev/null (or worse, bounce). If the recipient's MTA rejects the > > message, it is the sender's MTA who has the responsibility of informing > > the sender of the failure. > > It's difficult for the recipient to do this. Granted. But that doesn't mean that it shouldn't be tried. > The mail may be rejected or discarded by filters at the final > destination, and that information never makes it back to the sender. Which is why it should not be filtered at the final destination but at the earliest possibility. For example, we have two mail servers: One which is listed as MX for our domains, and one where the mailboxes of the users are and which users use to send mail (actually, there are more, but these are sufficient to illustrate the point). So there are three places where mail can be categorized into spam and ham: At the MX, at the mailbox-server, and at the MUA. Most of our users use Mozilla, which has a bayesian junk filter and can also filter according to various other criteria. That's simple for the user. But they still get all thoses spams and they may occassionally miss a legitimate mail because it has been erroneously classified as spam. If that happens, neither they nor the sender is notified about it (Mozilla cannot "reject" a message). On the mailbox server, we also run Spamassassin to mark messages as spam or non-spam. We could reject messages here, but we don't. All incoming messages are coming from out MX which would have to generate a DSN. So there is no feedback at this stage, either. Everything we can check at the MX we check there: Does the recipient exist? Does the sender's domain have an A or MX record? Is it in a black- or whitelist? Is the IP address in a black or whitelist? Is the HELO parameter in a blacklist? Greylisting, Virus-Checks, A spamassassin with custom rules to match common bogus virus warnings, ... By "pushing out" all checks as far as possible, we try to give feedback to the real sender and not to some poor sod who has been joe-jobbed. Spammer ratware may or may not record the 4xx and 5xx error codes. But a legitimate MTA will notice them and generate a bounce to the sender. This will usually be the real sender, because legitimate MTAs accept only mails from their own, authenticated (sometimes weakly) users. So a sender who's mail as erroneously caught by anti-spam measures on our MX will be notified, but a sender who's mail wasn't read by a user because it was moved to the "junk" mailbox by the MUA's filter, won't. And we don't send out bounces to random faked addresses. Tests for SPF, MTA-MARK etc. would be done on the MX, too. There are a few tests we can't do at the MX (yet): I haven't figured out a way to do bayesian filters: They require feedback from the user. My current idea is to replicate the training-files from the users (we can do this, because they are on an SMB-share, not the user's local hard disks), but if we reject mails based on the bayesian filters, the users will get only correct ham and false negatives, not correct spam or false positives. Thus the samples on which the training-files are based will be very lopsided. Even if I can solve that I don't know how to treat mails to aliases which expand to several users: Reject it if it had been rejected for more than half of the individual recipients? hp -- _ | Peter J. Holzer | I think we need two definitions: |_|_) | Sysadmin WSR | 1) The problem the *users* want us to solve | | | hjp at hjp.at | 2) The problem our solution addresses. __/ | http://www.hjp.at/ | -- Phillip Hallam-Baker on spam
Attachment:
pgpY6svziI13T.pgp
Description: PGP signature
_______________________________________________ Asrg mailing list Asrg at ietf.org https://www1.ietf.org/mailman/listinfo/asrg