I don't know but assume that the SpamAssassin milter interfaces (I
think there are two) use the same information for per-user rules and
scoring; it certainly could. I don't know but suspect the milter
mechanism does not handle .forward files, but I don't think that's a
significant problem. The milter mechanism handles alias files and at
least some other things that cause sendmail to forward the message
elsewhere in the sense of telling the milter filter program as much.
The Milter interface allows third party applications to hook in to the
SMTP conversation between Sendmail and the remote MTA, and:
a) Override Sendmail's choice of SMTP status codes to return at each
stage of the process. So the milter can selectively refuse
messages with finer-grained control than is possible with the
sendmail.cf rules and external maps.
b) Change everything about the message (envelope information, header,
body (including attachments) before Sendmail queues the message for
onward delivery (or hands it off to a local delivery agent).
So all this happens *before* Sendmail consults .forward files, and other
paraphenalia.
SpamAssassin doesn't have a "native" milter interface (i.e., one supplied
by the SpamAssassin project). At least two projects run as milters, and
(may) call out to the SpamAssassin libraries as part of their filtering,
spamass-milter, and MIMEDefang.
Out of the box, it's tricky, but not impossible, to support per-user
filtering using this mechanism. At first glance this isn't possible at
all, because SMTP doesn't allow the response to the DATA portion of the
transaction to say "We accept this message for recipients 1 and 3, but
it's been rejected for recipient 2".
At least two workarounds exist for this. One is to configure Sendmail to
only allow one recipient per SMTP transaction. I.e., return 250 to the
first RCPT, and 550 to the others.
This increases the load on your mail servers, and we've seen a
significant number of connections from MTAs that fail to handle this
properly (i.e., they temp. or perm. fail the message for *all*
recipients, not just the ones that were 550'd).
The other (which is employed by MIMEDefang if you turn on the necessary
option, it may also be used by others) is to accept the message with a
rewritten envelope. The remote server receives a 2xx response to the
DATA command. MIMEDefang then resends the message, once per recipient,
so the filter can make per-recipient filtering decisions.
This is not pretty:
a) Rejections at this point will generate full bounce messages at
the local MTA, which, if it's spam, may have invalid return
addresses, and/or be to servers with poor connectivity, so your
outbound mail queue gets quite large. Rejecting during the initial
SMTP conversation is preferred, because then the remote system has
to generate the bounce message.
b) The amount of horse power needed to process mail increases. Our
stats show that roughly 40% of our inbound SMTP connections refer
to multiple recipients.
N
--
1 1 2 3 4 5 6 7 7
0 0 0 0 0 0 0 5
-- The 75 column-ometer
Global Messaging, A: Top posting
120 Cheapside, x83331 Q: What's the most annoying e-mail habit?
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg