CONFIRM: DELIVERY

[Jacob_Palme_QZ...@mit-multics.arpa]

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.

[Rob Austein]

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.

[Michael C. Berch]

Jacob_Palme_QZ%QZCOM....@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: m...@lll-tis-b.ARPA
UUCP: {ihnp4,dual,sun}!lll-lcc!styx!mcb

[The lost Bostonian]

In article <20...@styx.UUCP>, m...@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

[John Gilmore]

> 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 jgil...@lll-crg.arpa
May the Source be with you!

[Jeff Gilliam]

> 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

[Joseph S. D. Yao]

In article <40...@brl-smoke.ARPA> Jacob_Palme_QZ%QZCOM....@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}
js...@hadron.COM (not yet domainised)

[J.R. Stoner]

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?