[comp.mail.sendmail] Bouncing mail for expired users

msir@uhura.cc.rochester.edu (Mark Sirota) (03/07/90)

What I think I want to do is create an alias in sendmail's alias file which
will cause a message to bounce, but with a particular message.

Let me give you the whole story.  For a variety of reasons I don't wish to
go into on this forum, there is a lag between the time that users here get
expired (they can no longer log in) and the time their account gets
completely deleted.

Unfortunately, during this period, mail can still be delivered to them, but
can never be read.

What I would like to do is to bounce mail for such users back to the sender,
with a useful message, like "Account expired."  I use sendmail for mailing,
and would be inclined to use a sendmail alias to do this.  I don't want to
write over the users' .forward file, since I consider that to be the
property of the user.

Sendmail normally returns mail to unknown users with messages like
	   ----- Transcript of session follows -----
	550 foo... User unknown
	
	   ----- Unsent message follows -----
I'd love to somehow get this to say something like
	550 foo... User expired
without modifying sendmail.  If I could create an alias like
	foo: "user expired"
That might bounce as
	550 "user expired"... User unknown
which would be acceptable.  (I don't know if that's what actually happens; I
haven't tried it yet.)

Without further ado, my question to you is:
In this situation, how would you handle it?  Should I be bouncing this mail
at all?  (I think the sender should know that the mail can never be read.  I
also want to bounce the original, not just send a message back with
vacation(1) or something.)  If so, how should I make it bounce?

Please feel free to brainstorm.  Thanks in advance.
-- 
Mark Sirota - University of Rochester, Rochester, NY
 Internet: msir@cc.rochester.edu
 Bitnet:   msir@uordbv.bitnet
 UUCP:     {decvax,harvard,ames,rutgers}!rochester!ur-cc!msir

karl@giza.cis.ohio-state.edu (Karl Kleinpaste) (03/07/90)

msir@uhura.cc.rochester.edu writes:
   What I think I want to do is create an alias in sendmail's alias file which
   will cause a message to bounce, but with a particular message.

With apologies for a certain tendency to grotesque hacks, try this:
	some-expired-user:	"|/usr/local/lib/expire-bounce"
where /usr/local/lib/expire-bounce consists of
	#!/bin/sh
	echo 500 User no longer on system.
	exit 1
which results in bounces of the form:
	   ----- Transcript of session follows -----
	500 User no longer on system.
	554 "|/usr/local/lib/expire-bounce"... unknown mailer error 1

--karl

chip@tct.uucp (Chip Salzenberg) (03/07/90)

According to Mark Sirota <msir@cc.rochester.edu>:
>What I think I want to do is create an alias in sendmail's alias file which
>will cause a message to bounce, but with a particular message.

(You knew this was coming...)

Deliver 2.0, patchlevel 9 (which should be out today) supports bounces
with user-specified error messages.

Delivery files can output a string of the form "user?error message",
and the resulting error report will include the given error message.
So to do what you request:

>What I would like to do is to bounce mail for such users back to the sender,
>with a useful message, like "Account expired."

Create a post-user delivery file that looks like this:

	for u
	do
	    if grep "^${u}$" /usr/lib/mail/expired >/dev/null
	    then
		echo "$u?Account expired."
	    else
		echo "$u"
	    fi
	done

Then create the file "/usr/lib/mail/expired" with a list of expired
accounts, one per line.
-- 
Chip Salzenberg at ComDev/TCT   <chip%tct@ateng.com>, <uunet!ateng!tct!chip>
          "The Usenet, in a very real sense, does not exist."

cowan@marob.masa.com (John Cowan) (03/07/90)

In article <5637@ur-cc.UUCP> Mark Sirota <msir@cc.rochester.edu> writes:
>What I think I want to do is create an alias in sendmail's alias file which
>will cause a message to bounce, but with a particular message.

An easy hack would be to alias those users to a user with a name like
account_expired.  This alias would be resolved and then bounced with the
error "account_expired: user unknown".  This is not perfect but would tell
the tale.

Makey@Logicon.COM (Jeff Makey) (03/08/90)

I added the following line to ruleset zero in my sendmail.cf file:

    R$*<@NoMail>    $#error$@67$:user cannot receive mail    "67" == EX_NOUSER

(be sure to double-check the value of EX_NOUSER in /usr/include/sysexits.h)
and lines similar to the following in my aliases file:

    olduser:olduser@NoMail

This results in SMTP exchanges such as:

    220 Logicon.COM Sendmail 5.61/6.03 ready at Wed, 7 Mar 90 10:26:05 -0800
    HELO Red-Baron.Logicon.COM
    250 Logicon.COM Hello Red-Baron.Logicon.COM, pleased to meet you
    MAIL FROM:<JEFF@Red-Baron.Logicon.COM>
    250 <JEFF@Red-Baron.Logicon.COM>... Sender ok
    RCPT TO:<tony@Logicon.COM>
    554 tony@NoMail... user cannot receive mail
    QUIT
    221 Logicon.COM closing connection

This is better than Karl's shell script because the body of the
message is not transmitted.  Note that the error code is 554 instead
of 550 as it really ought to be according to RFC 821; I'm not sure how
sendmail might be changed to correct this.

                           :: Jeff Makey

Department of Tautological Pleonasms and Superfluous Redundancies Department
    Disclaimer: Logicon doesn't even know we're running news.
    Internet: Makey@Logicon.COM    UUCP: {nosc,ucsd}!logicon.com!Makey

7thSon@SLCS.SLB.COM (Chris Garrigues) (03/08/90)

    From: cowan@marob.masa.com
    Date: Wed, 7 Mar 90 09:55 CST
    
    In article <5637@ur-cc.UUCP> Mark Sirota <msir@cc.rochester.edu> writes:
    >What I think I want to do is create an alias in sendmail's alias file which
    >will cause a message to bounce, but with a particular message.
     
    An easy hack would be to alias those users to a user with a name like
    account_expired.  This alias would be resolved and then bounced with the
    error "account_expired: user unknown".  This is not perfect but would tell
    the tale.
    

My quick solution would be to put these lines in my .cf file:

# This goes near the beginning of the file somewhere
FE/somewhere/expired-users

# This goes just before sending local mail.
R$=E	$#error $: The user %1 is no longer at this host.

and the referenced file contains a list of expired users.

The more involved solution would be to pass the username into a script
which would generate a more informative error message which could even
look up where the user can now be reached.

What we actually do here is to keep forwarding addresses "forever".


Chris Garrigues,
Postmaster@SLCS.SLB.COM

watson@shinobu.sgi.com (David M. Watson, Jr.) (03/08/90)

In article <25F514B1.5E18@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:

>  >What I would like to do is to bounce mail for such users back to the sender
>  >with a useful message, like "Account expired."
>
>   Create a post-user delivery file that looks like this:
>
>	   for u
>	   do
>	       if grep "^${u}$" /usr/lib/mail/expired >/dev/null
>	       then
>		   echo "$u?Account expired."
>	       else
>		   echo "$u"
>	       fi
>	   done
>
>   Then create the file "/usr/lib/mail/expired" with a list of expired
>   accounts, one per line.

This and the other automatic response schemes create a distressing
possibility.  In this particular case, the pathological situation arises
when a user who has just sent mail to an expired user becomes expired
herself.  Then the two mailboxes exchange mail, never generating errors,
possibly forever, or at least for a very long time, until the message
body exceeds some size limit or fills a disk drive.

So, does anyone currently try to prevent this?  The capability to
automatically bounce mail would be nice, but without safeguards it's
dangerous.

		-David Watson
		 Silicon Graphics, Inc.

mrm@sceard.Sceard.COM (M.R.Murphy) (03/08/90)

In article <5637@ur-cc.UUCP> Mark Sirota <msir@cc.rochester.edu> writes:
>What I think I want to do is create an alias in sendmail's alias file which
>will cause a message to bounce, but with a particular message.

You could always integrate sendmail with smail and deliver. When local
delivery is attempted through deliver, you are limited only by imagination
and proficency with shell scripts in your processing of the message.

The bouncing of mail for expired users is really simple. You might have
to keep the user information around in the password file with a "*xpired"
password entry (or the equivalent), or in another file with forwarding
information, or ...

Limited only by imagination (and CPU time :-), deliver is really slick.
--
Mike Murphy  Sceard Systems, Inc.  544 South Pacific St. San Marcos, CA  92069
mrm@Sceard.COM        {hp-sdd,nosc,ucsd,uunet}!sceard!mrm      +1 619 471 0655

lear@turbo.bio.net (Eliot) (03/10/90)

Somehow, I don't think it would be a good idea to have an error
message reading, ``User has expired.''  Someone just might...

;-)
-- 
Eliot Lear
[lear@TURBO.BIO.NET]

chip@tct.uucp (Chip Salzenberg) (03/10/90)

According to watson@shinobu.sgi.com (David M. Watson, Jr.):
>This and the other automatic response schemes create a distressing
>possibility.  In this particular case, the pathological situation arises
>when a user who has just sent mail to an expired user becomes expired
>herself.  Then the two mailboxes exchange mail, never generating errors,
>possibly forever, or at least for a very long time, until the message
>body exceeds some size limit or fills a disk drive.

To answer this objection, I offer this (rather safer) version:

	for u
	do
	    if grep "^${u}$" /usr/lib/mail/expired >/dev/null
	    then
		case "$SENDER" in
		*DAEMON|*daemon|*uucp)
			echo root ;;   # Bouncy bouncy
		*)
			echo "$u?Account expired." ;;
		esac
	    else
		echo "$u"
	    fi
	done

As you can see, a little testing goes a long way...
-- 
Chip Salzenberg at ComDev/TCT   <chip%tct@ateng.com>, <uunet!ateng!tct!chip>
          "The Usenet, in a very real sense, does not exist."

C.R.Ritson@newcastle.ac.uk (Chris Ritson) (03/15/90)

In article <25F83AB4.290E@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>According to watson@shinobu.sgi.com (David M. Watson, Jr.):
>>This and the other automatic response schemes create a distressing
>>possibility.  In this particular case, the pathological situation arises
>>when a user who has just sent mail to an expired user becomes expired
>>herself.

(A mail loop is described), and the writer suggests detecting cirtain common
Unix keywords to break this loop.

Surely  the  right thing to do is to ensure that when YOU bounce mail,
YOU fill in the headers in the message going  out,  so  that  if  this
message  is  bounced  by  a  less  intelligent mailer, then it ends up
(depending on  your  preferences)  in  the  waste  bin,  or  with  the
postmaster.  The important thing is that it must NOT bounce if it does
come back to you.

I  beleive this is described in RFC822, but do not have a copy to hand
now.  Please don't go down the same route  that  seems  to  have  been
taken  by  many  implementations  of  the  "listserv" software.  It is
broken, and is the cause of many mail loops.

Chris Ritson.
--
ARPA : C.R.Ritson@newcastle.ac.uk             JANET: C.R.Ritson@uk.ac.newcastle
UUCP : ...!ukc!newcastle.ac.uk!C.R.Ritson     PHONE: +44 91 222 8175
FAX  : +44 91 222 8232                        TELEX: uk+53654-UNINEW_G
SNAIL: Computing Laboratory, University of Newcastle upon Tyne, UK, NE1 7RU

ARPA : C.R.Ritson@newcastle.ac.uk             JANET: C.R.Ritson@uk.ac.newcastle
UUCP : ...!ukc!newcastle.ac.uk!C.R.Ritson     PHONE: +44 91 222 8175
FAX  : +44 91 222 8232                        TELEX: uk+53654-UNINEW_G
SNAIL: Computing Laboratory, University of Newcastle upon Tyne, UK, NE1 7RU

chip@tct.uucp (Chip Salzenberg) (03/21/90)

According to C.R.Ritson@newcastle.ac.uk (Chris Ritson):
>Surely  the  right thing to do is to ensure that when YOU bounce mail,
>YOU fill in the headers in the message going  out,  so  that  if  this
>message  is  bounced  by  a  less  intelligent mailer, then it ends up
>(depending on  your  preferences)  in  the  waste  bin,  or  with  the
>postmaster.  The important thing is that it must NOT bounce if it does
>come back to you.

I quite agree that good E-Mail neighbors generate bounce messages that
can be easily recognized as such.  However, in the context of a
Deliver 2.0 delivery file like the one I posted a few days ago, it is
assumed that there is some Smart Mailer out there who will recognize a
non-zero exit status from Deliver and generate the bounce message.

Smail 2.5 typically fulfills the Smart Mailer role, and its bounce
messages always look like they came from the user MAILER-DAEMON@host.

My partial bounce-loop solution posted in a previous article was
*intended* as a partial solution for use in concert with Smail 2.5 or
some equivalently "smart" mailer.

"Life *is* pain, highness.  Anyone who says otherwise is selling something."
-- 
Chip Salzenberg at ComDev/TCT   <chip%tct@ateng.com>, <uunet!ateng!tct!chip>
          "The Usenet, in a very real sense, does not exist."