Re: custom 55x error message for specific email addresses

> # ./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