RE: [Asrg] Some data on the validity of MAIL FROM addresses

["Clayton, Nik [IT]" <[e-mail]>]

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg