A follow-up to a comment of Ned's:
On Oct 18, 2007, at 3:57 AM, Ned Freed wrote:
perhaps a better approach is to use a filtering mechanism that's
better at
catching blowback.
I believe available in JS MS 6.3p1 is a new feature whereby FROM_ACCESS
can
be used to cause a channel switch for incoming notification messages
(messages
with empty envelope From). This can be a useful start at dealing with
"blow-back" -- put the incoming notification messages on their own
incoming
channel and then look more "carefully" at those messages (that is,
inspect
them more carefully using some spam/virus filter package of your
choice, or
using a sourcespamfilter channel filter, or whatever) to try to detect
cases
of "blow back" vs. "normal" notification messages coming back to the
user.
You want to let the non-notification messages to your users in
normally, let in
"normal" notification messages to your users normally, but try to spot
(and
discard or reject or whatever) the "blow back" and handle them
specially.
Or, if what you're going to use to try to spot the "blow back" is the
equivalent of a channel Sieve filter, then you don't even have to bother
with the channel switch -- just have one of the recipient address
*_ACCESS
mapping tables (_not_ FROM_ACCESS, which doesn't support this flag)
apply a
"special, try-to-detect blow-back" Sieve filter to incoming messages
that have
an empty envelope From. This apply-a-Sieve-filter feature in those
*_ACCESS
mapping tables is available from back in JES MS 6.0.
In FROM_ACCESS:
$~<channel-name> does the source channel "switch". The <channel-name>
argument
comes after and $U debug level, before any other mapping flag arguments
(and
separated from any other such arguments using the usual vertical bar
character,
|).
In [ORIG_]SEND_ACCESS or [ORIG_]MAIL_ACCESS:
$S<url> applies the Sieve filter located via <url> (which may be a
file: URL,
an ldap: URL, or data: -- though you'd have to be awfully careful with
space
quoting, etc., for a data: URL in such a mapping entry). This is the
last
(right-most) argument, if using multiple mapping flag arguments -- as
always,
separated with |.
Regards,
Kristin
# ./sbin/imsimta version
Sun Java(tm) System Messaging Server 6.2-7.05 (built Sep 5 2006)
libimta.so 6.2-7.05 (built 12:18:44, Sep 5 2006)
SunOS dolly 5.10 Generic_118833-03 sun4v sparc SUNW,Sun-Fire-T200
short version:
what's the appropriate way to block mail to a specific email address
with a custom 55x error message? i know how to do it in sendmail, but
i'm not sure how to do it in MS.
That depends on what what you mean by "custeom 55x error message" and
whether
or not the email address is otherwise valid.
If you mean that you want to generate an error with some specific
descriptive
US-ASCII text that's easy enough to accomodate. If, OTOH, you want to
change
the extended error code that narrows the options a bit but it is still
doable.
If, however, you want to change the SMTP error status, that's not
doable due to
the hightly restrictive nature of such codes (and if sendmail allows
such
changes shame on it for providing you with the means to violate the
relevant
standards in this area).
In any case, the general mechanism for blocking specific email
addresses is the
*_ACCESS mapping set. It is simple enough to insert, say, an
ORIG_MAIL_ACCESS
mapping entry that checks for a specific address and returns a
specific error
string (and optionally an extended status code). Something like:
ORIG_MAIL_ACCESS
*|user@host $NCustom$ error$ message
However, for this to work the address must be otherwise legal - if the
account
associated with the address has been deleted an error will be produced
before
things ever get to the point of checking these mappings. The obvious
way to
deal with that is to make the address valid in some way so the mapping
can be
used.
The other variation would be blocking an entire account including all
the
addresses associated with it. That's most easily done by changing the
mailuserstatus of the account to something other than "active". For
example,
you could set the status to "disabled" and then change the error text
for
disabled errors using the ERROR_TEXT_DISABLED_USER. (Of course this
assumes
you're not using "disabled" for something else.)
and is this solution scalable,
should be need to do it for dozens or hundreds of addresses?
A direct list of addresses in a mapping should be good for dozens of
addresses
at least. Many hundreds would probably be excessive, but in that case
you can
call out to the general database. That would easily scale to handle
tens of
millions of addresses.
If user account statuses are used it is obvious that there's no
scaling issue
that isn't already present for the accounts themselves.
long version:
one of the more irritating things about the 'spam problem' occurs when
a spammer uses your email address to sign a spam run. historically,
though, this has largely been a transient issue -- life is bad for a
few days, then the problem goes away. in the last few months, however,
this has -- sometimes -- changed: the Bad Guy never stops using
your address, so the bounces never stop.
there are a pile of possible ways to proceed; none of them really
perfect. one way is to:
- change mailing list subscriptions, tell real people, etc etc etc.
- change the lucky user's email address (in most cases,
the spammer is using one of the mailEquivalentAddresses, so this
is _comparatively_ painless)
- refuse all mail to the old address at the gateway or MTA.
unfortunately for us, our gateway doesn't have the ability
to create a custom per-address error message, so by default
it has to be at the MTA.
the third step needs to have a custom error message so if it should
happen to be legitimate mail the sender will (hopefully) get an SMTP
error that's useful. we've done this with sendmail for many years
via the access database, but (a) we haven't tackled it with MS yet and
(b) we don't yet have a test environment to tinker with. so what would
the recommended way be to do this? our sendmail access database has
grown to several thousand for one reason or other, so i'd suspect
we want something that scales at least this well.
I have to say that I regqrd letting spammers chase users away from the
addresses they have always used as pretty much a losing proposition
and that
perhaps a better approach is to use a filtering mechanism that's
better at
catching blowback.
Ned
