Re: custom 55x error message for specific email addresses

> > That depends on what what you mean by "custeom 55x error message"
> > and whether or not the email address is otherwise valid.

> mostly it's the text, although the first half of your sentence
> raises an issue that, well, i didn't know was an issue.

> what we've found useful over the years is the ability to tell our
> mail gateway MTA something like, well:

>    if presented with email addressed to the address
>    smithj-SPXQTMr/SIMalnyRIsVktCwD8/FfD2ys@xxxxxxxxxxxxxxxx, don't bother 
> worrying about whether
>    or not it exists, just reject it with your normal 550
>    but with the custom text, say:
>      "this address has changed; please consult...."

> the difference between this and the _ACCESS tables seems to
> be the requirement that the address be valid.

Well, once again I'm not entirely sure what it is you're driving at. If the
condition for rejecting is that these addresses contain the somehost part, then
that's trivially implemented with a rewrite rule that does a $? error reject.

If it is something else then you need to be more specified before I can
respond.

> > 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).

> (if i'm reading the sections with the big "Warning" notices correctly,
> i think it *might* but i'm unsure. since i know i'm a dimwit, though,
> i don't go there; if there's something that looks like dragon poo-poos
> then dragons can't be far away. but i don't want to do this in any
> case.)

Good. The problem with messing around with the primary SMTP status is that
there are plenty of agents out there that read the RFCs rather literally and
missed the whole "theory of error codes" section. They think any error code
that isn't exactly consistent with what's in RFC 821/822 is a protocol error.
The result is usually that they treat your new 5xy code as a temporary error
and keep trying to deliver the message, evually returning it days too late with
an entirely incorrect explanation of why it couldn't get through.

We have gone to a lot of trouble to make sure the statuses we return are as
widely interoperable as possible, and even then we still occasionally have a
problem that calls for a change to make some system out there interoperate with
us properly. (There are even cases where there's no single answser that works
with everything, so this can become a judgement call as to which choice serves
the community best.)

> i'm not trying to hold this up as The Way Anything Should Be Done,
> just that this broad feature is something that's been very useful to
> us in the past and i'm stuggling with how i would do the analogous
> things using Messaging Server/MTA.

Well, I've consider adding an access mapping that is checked before any other
validity checks are done, but to the best of my knowledge nobody has come up
with a real use case for it. More specifically, using rewrite rule rejects to
prohibit entire classes of addresses has always been sufficient. (For that
matter, it would not be hard to have a rewrite that calls out to a database or
mapping and that would give you this capability.)

> > 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:

> i've been looking at the manual and i'm a little confused.  is there
> a reason to go to ORIG_MAIL_ACCESS when the ORIG_SEND_ACCESS table appears to
> be adequate? something like

> *|*|*|user@host               $NThis$ address$ no$ longer$ exists

> looks like it should be enough; the extra features in ORIG_MAIL_ACCESS
> don't seem to be necessary. what am i missing?

You're not missing anything. I picked the ORIG_MAIL_ACCESS mapping for
simplicity - there's already a ORIG_SEND_ACCES mapping in the default
configuration and didn't want to deal with adding to the existing entries in
it.

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

> that's a bit of a downside, but not an issue in the current
> case.

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

> in general, i would definitely agree. some of the things that Kristin
> mentions are things that are definitely worth looking at sometime
> after we have a test environent to play with: filtering bounces is, i
> think, going to be Very Hard so it's not something we want to tinker
> with in our production environment.

> in the meantime, most everyone in our environment has several
> addresses that point to the same mailbox. most folks 'mostly' only use
> one of those; if it's one of the other ones that's a spam bounce
> victim, it's not a big issue to disable it.

Since the addresses at issue are in mailEquivalentAddress attribute perhaps
the right way to do it is to move the attribute value from the user account
where it currently resides to a different account that is configured to
reject everything with an appropriate error.

                                Ned