Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA (09/24/86)
I am considering implementing in COM a facility that if an incoming message has "CONFIRM: DELIVERY" in the RFC822 header, then when the message has been delivered to the recipient mailbox, a message is sent back to the SMTP-sender saying that this has been done. One could also envisage "CONFIRM: RECEIVED". This is not fully compatible with X.400, since in X.400 one can request confirmation separately for each recipient. But that is not so easy to fit into the RFC822 syntax, so I suggest just one command for all the recipients. Any comments? Has anyone already implemented something similar? In that case, I should use their syntax and not reinvent something different.
SRA@mit-xx.ARPA (Rob Austein) (09/24/86)
You might want to use something like CONFIRM: <address-to-confirm-to> rather than using the SMTP-sender. Or you could do Confirm-Delivery: <address-to-confirm-to> and Confirm-Receipt: <address-to-confirm-to> Using the SMTP sender for anything but the limited purpose defined in the spec is probably a bad idea.
mcb@styx.UUCP (Michael C. Berch) (09/25/86)
Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA writes: > I am considering implementing in COM a facility that if an incoming > message has "CONFIRM: DELIVERY" in the RFC822 header, then > when the message has been delivered to the recipient mailbox, > a message is sent back to the SMTP-sender saying that this > has been done. > . . . > Any comments? Has anyone already implemented something similar? > In that case, I should use their syntax and not reinvent something > different. A large percentage of Internet mailers (and at least one user agent) respond to the header field Return-Receipt-To: <addr-spec> confirming delivery of a message to a mailbox (in the case of a delivery agent) or reading of the message (in the case of a user agent). It isn't in RFC822, but I'd call it a de facto standard among 822-style mailers. Michael C. Berch ARPA: mcb@lll-tis-b.ARPA UUCP: {ihnp4,dual,sun}!lll-lcc!styx!mcb
gds@sri-spam.ARPA (The lost Bostonian) (09/25/86)
In article <20884@styx.UUCP>, mcb@styx.UUCP (Michael C. Berch) writes: > A large percentage of Internet mailers (and at least one user agent) > respond to the header field > > Return-Receipt-To: <addr-spec> > > confirming delivery of a message to a mailbox (in the case of a > delivery agent) or reading of the message (in the case of a user > agent). It isn't in RFC822, but I'd call it a de facto standard among > 822-style mailers. Doesn't Return-Receipt-To: cause a mail loop with sendmail? I seem to recall having that problem the one time I tried using this feature. --gregbo
gnu@hoptoad.uucp (John Gilmore) (09/29/86)
> Doesn't Return-Receipt-To: cause a mail loop with sendmail? I seem to > recall having that problem the one time I tried using this feature. No mail loop is caused, but there appears to be a sendmail bug which causes a return receipt to be returned to you whether or not the sendmail is doing final delivery of the message. In other words, you may get a receipt from each sendmail that your message passes through on its way. I've reported this bug to Sun but I don't know if they have a fix. Also, you have to very carefully craft the address to which you request the receipts to be sent. On networks like uucp, you have to figure out a "return address" that will work from the recipient site(s). I think this could be a problem on the Internet too, since some hosts use one naming scheme and some hosts use another. -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore@lll-crg.arpa May the Source be with you!
jeff@voder.UUCP (Jeff Gilliam) (10/01/86)
> No mail loop is caused, but there appears to be a sendmail bug > which causes a return receipt to be returned to you whether or not > the sendmail is doing final delivery of the message. This is at odds with my experience. I regularly use the Return-Receipt-To: feature and have never seen this happen. > Also, you have to very carefully craft the address to which you > request the receipts to be sent. Again I beg to differ. I've always just used "Return-Receipt-To: jeff" and each sendmail along the way plays with the address appropriately. (Of course, this depends on every link on the route running sendmail.) -- Jeff Gilliam {ucbvax,pyramid,nsc}!voder!jeff
jsdy@hadron.UUCP (Joseph S. D. Yao) (10/02/86)
In article <4070@brl-smoke.ARPA> Jacob_Palme_QZ%QZCOM.MAILNET@MIT-MULTICS.ARPA writes: >message has "CONFIRM: DELIVERY" in the RFC822 header, then >when the message has been delivered to the recipient mailbox, >a message is sent back to the SMTP-sender saying that this One hopes you mean the original sender, rather than the last SMTP link in the route? You've already had mentioned sendmail's Return-Receipt-To:. This is supposed to send a receipt when it (sendmail) recieves the mail at what it thinks is the local delivery machine. (Sendmail has very definite ideas about "local" -- as someone pointed out, they MIGHT be right.) This has seemed to work in the past. A certain mail system (user agent) wanted to have instantaneous receipt on to OR cc OR both, when mail was read. The attribute used was Send-Receipt:, which was changed to Sent-Receipt: after the receipt went back (so that the mail file didn't have to be re-built, and the header file could be re-built correctly). The mail had to be sent out in two calls to sendmail, in case one wanted receipts from To but not Cc, or vice versa. It all ... works ... -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)
asgard@cpro.UUCP (J.R. Stoner) (10/04/86)
Since there is no such thing as a net.mail.request I must apologise for posting here. My copies of the RFC documents and commentaries were "misplaced" when the VAX was reorganized. Could some kind person please EMAIL me copies of the various RFC documents (esp. RFC822) so that I can convince the person who is writing the mailer for Concurrent CDOS on the CompuPro's to conform to what passes for a standard around here?