karl@naitc.uucp (Karl Denninger) (07/28/90)
Hi Usenet... We are running Smail3, and need to have the functionality in "Return-Receipt-To:" that is present in sendmail and elsewhere. Anyone know how to do this using smail3? I know it doesn't guarantee that the message was READ, just delivered, but it is very important on our network. If it's not supported, any good ideas on where to insert support for this are appreciated. -- Karl Denninger AC Nielsen (708) 317-3285
kjones@talos.pm.com (Kyle Jones) (07/30/90)
Karl Denninger writes: > We are running Smail3, and need to have the functionality in > "Return-Receipt-To:" that is present in sendmail and elsewhere. > > Anyone know how to do this using smail3? [...] > > If it's not supported, any good ideas on where to insert support for this > are appreciated. Presumably smail3, like sendmail, calls another program to do final message delivery. Insert the Return-Receipt-To processing into that program, or substitute a program that calls the delivery program and then does the Return-Receipt-To processing after delivery is successful. The job seems simple enough that a shell script would suffice.
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (07/31/90)
kjones@talos.pm.com (Kyle Jones) writes: >Karl Denninger writes: > > We are running Smail3, and need to have the functionality in > > "Return-Receipt-To:" that is present in sendmail and elsewhere. > > Anyone know how to do this using smail3? [...] >Presumably smail3, like sendmail, calls another program to do >final message delivery. Insert the Return-Receipt-To processing >into that program, or substitute a program that calls the >delivery program and then does the Return-Receipt-To processing >after delivery is successful. [ Smail3 will let you call a program to do delivery, or perform the delivery itself, depending on how you configure things. ] I think the easiest way to get the behaviour Karl wants would be to set up a shadow transport for "local" that looks for the Return-Receipt-To: header, and acts appropriately on it. The nice thing about shadow transports (in this case) is they are only called if the primary transport delivers sucessfully. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University {alberta,cbmvax,mips}!atha!lyndon || lyndon@cs.athabascau.ca Practice Safe Government Use Kingdoms
karl@naitc.uucp (Karl Denninger) (07/31/90)
In article <10@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >kjones@talos.pm.com (Kyle Jones) writes: > >>Karl Denninger writes: >> > We are running Smail3, and need to have the functionality in >> > "Return-Receipt-To:" that is present in sendmail and elsewhere. >> > Anyone know how to do this using smail3? [...] > >[ Smail3 will let you call a program to do delivery, or perform the >delivery itself, depending on how you configure things. ] > >I think the easiest way to get the behaviour Karl wants would be to >set up a shadow transport for "local" that looks for the Return-Receipt-To: >header, and acts appropriately on it. The nice thing about shadow transports >(in this case) is they are only called if the primary transport delivers >sucessfully. Hmmm... how do I accomplish this? Anyone have a working example they can send me (config files, etc)? -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285
chip@tct.uucp (Chip Salzenberg) (07/31/90)
According to karl@naitc.naitc.com (Karl Denninger): >We are running Smail3, and need to have the functionality in >"Return-Receipt-To:" that is present in sendmail and elsewhere. You could do this with the "shadow transport" feature. NOTE: I have NOT tested the procedure given below. This is just a hint as to what might work. On the other hand, I have been spending some time lately hacking on Smail 3's innards, so I might be right. Define a transport that does nothing except send acknowledgements to the address(es) listed in a Return-Receipt-To header. I would recommend the use of my Deliver program or a Perl script, but a shell script might be good enough if your volume isn't too high. Call the new transport "local_receipt". Then add "shadow = local_receipt" to your "local" transport definition. Presto, all locally-delivered messages with Return-Receipt-To headers are automatically acknowledged. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
karl@naitc.uucp (Karl Denninger) (08/07/90)
In article <26B5AD05.218B@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >According to karl@naitc.naitc.com (Karl Denninger): >>We are running Smail3, and need to have the functionality in >>"Return-Receipt-To:" that is present in sendmail and elsewhere. > >NOTE: I have NOT tested the procedure given below. This is just a >hint as to what might work. On the other hand, I have been spending >some time lately hacking on Smail 3's innards, so I might be right. > >Define a transport that does nothing except send acknowledgements to >the address(es) listed in a Return-Receipt-To header. I would >recommend the use of my Deliver program or a Perl script, but a shell >script might be good enough if your volume isn't too high. Call the >new transport "local_receipt". > >Then add "shadow = local_receipt" to your "local" transport >definition. > >Presto, all locally-delivered messages with Return-Receipt-To headers >are automatically acknowledged. I wrote a small "C" program that parses the headers of an incoming message and if it believes that a receipt is to be generated, it does. Then added the shadow entry to the transports file, and used the other appropriate flags (hint: use the "pipe" transport driver, and set others as necessary). Works great. Thanks much; wish I could share the program but it is, as they say, a "work for hire". It shouldn't take much for someone to duplicate this functionality though.... it was only an hour's worth of hacking. I'd like to suggest that someone pick this up and include it in the next smail3 release or patch; it's quite useful. I am currently setting the return address for the receipts to "postmaster"; that seems appropriate since it's really the postmaster who's doing the notification. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285