Re: custom 55x error message for specific email addresses

Ned Freed writes:
> 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.


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

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.


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

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

rp

rick pim                                           
rick-POYOzcKcYG0txLPZ/1ia6w@xxxxxxxxxxxxxxxx
information technology services                          (613) 533-2242
queen's university, kingston   
-----------------------------------------------------------------------
"UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things."
                    -- Doug Gwyn