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!msirkarl@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
--karlchip@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!Makey7thSon@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.COMwatson@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
Craig_Everhart@TRANSARC.COM (03/09/90)
It should be simple: all you'd have to do is make sure that your bounce message comes from a known-deliverable address, such as Postmaster or MAILER-DAEMON (you *do* make sure that that's a deliverable address on your system, don't you?). So if a bounce message is undeliverable, it bounces not to the guy whose account is expired but rather to some postmaster somewhere. This trick is already in widespread use for most bounce messages, or otherwise our networks would be dogmeat. Craig
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."
towfiq@interlan.Interlan.COM (Mark Towfigh) (03/11/90)
[how to bounce mail, informing the sender that the user's account has expired.] In article <KARL.90Mar7082150@giza.cis.ohio-state.edu> karl@giza.cis.ohio-state.edu (Karl Kleinpaste) writes: 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 Building on Karl's suggestion, how about returning some sensible error, like 67 -- EX_NOUSER (addressee unknown) 69 -- EX_UNAVAILABLE (service unavailable) 73 -- EX_CANTCREAT (can't create (user) output file) 77 -- EX_NOPERM (permission denied) (taken from sysexits.h) Mark -- Mark Towfigh, Racal Interlan, Inc. towfiq@interlan.Interlan.COM W: (508) 263-9929 H: (617) 488-2818 uunet!interlan!towfiq "The Earth is but One Country, and Mankind its Citizens" -- Baha'u'llah
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."