EMAIL QUESTION ...CCMAIL
tre...@sirius.com
For_Email_@ddress_see.below.plea.se (Philip J. Koenig) wrote:
>tre...@sirius.com wrote:
>>Internet mail standards, afaik, do not support return receipts, but
>>cc:Mail does (cc:Mail stinks, but that's a different post, I suppose).
>
>Sendmail has supported return receipts for a number of years. I'll show
>you one:
Really?! Hey, learn something new every day.
>I don't think the RFC for SMTP stipulates that you must support this
>functionality, although it is either an optional extension or a de-facto
>one at this point.
I don't think I like the idea of return receipts because it potentially
doubles the traffic (or at least, the number of messages). It irritates me
that, at work, they installed cc:Mail on ~1,500 workstations, and left the
receipt option turned on. Few people at work have had the bright idea of
turning it off, and only using it when they really need it.
For people downloading mail off a server via POP, is the return receipt
generated when the server receives the email, or when the user downloads
the mail from the server?
Philip J. Koenig
tre...@sirius.com wrote:
>"Wei Kang Chen" <wc...@adam.cc.sunysb.edu> wrote:
>>HOW COME SOMETIMES WHEN I SEND A MESSAGE OVER THE INTERNET, VIA CCMAIL, I
>>GET A RETURN RECEIPT, AND OTHER TIMES I DO NOT ? I ALWAYS REQUEST ONE. IS
>>IT SOMETHING ON THE RECEIVING SIDE THAT DETERMINES WHETHER A RETURN
>>RECEIPT CAN OCCUR ?
>Internet mail standards, afaik, do not support return receipts, but cc:Mail
>does (cc:Mail stinks, but that's a different post, I suppose).
>I'll bet what's happening is that you get return receipts when your
>recipients use cc:Mail, or some other program that supports return
>receipts. When your recipients use real Internet mail program, you don't
>get a return receipt.
Ah me..
Sendmail has supported return receipts for a number of years. I'll show
you one:
----------
Date sent: Tue, 13 Feb 1996 03:06:09 -0800
From: Mailer...@netcom.com (Mail Delivery Subsystem)
Subject: Returned mail: Return receipt
To: pjk
The original message was received at Tue, 13 Feb 1996 03:06:08 -0800
from mailhub1.aimnet.com [204.247.0.104]
----- Transcript of session follows -----
<som...@netcom.com>... Successfully delivered
----- Message header follows -----
Return-Path: <p...@aimnet.com>
Received: from aimnet.com by mail5 (8.6.12/Netcom) id DAA15934; Tue, 13 Feb 1996
03:06:08 -0800
Received: from iway.aimnet.com (dial-sf2-26.iway.aimnet.com [204.247.145.26]) by
aimnet.com (8.7.1/8.7.1) with SMTP id DAA09683 for <som...@netcom.com>; Tue, 13
Feb 1996 03:06:27 -0800 (PST)
Message-Id: <1996021311...@aimnet.com>
Comments: Authenticated sender is <p...@mailhub.aimnet.com>
From: "Philip J. Koenig" <p...@aimnet.com>
Organization: Computers & Communications
To: som...@netcom.com
Date: Tue, 13 Feb 1996 03:08:42 -0800
Subject: <Some Subject>
Reply-to: p...@aimnet.com
Return-receipt-to: p...@aimnet.com
Priority: normal
X-mailer: Pegasus Mail for Windows (v2.23)
----- Message body suppressed -----
------------------
Only the name and subject strings have been changed to protect the innocent. :-)
The header that triggers the destination mailer to send out the return receipt
is the "Return-receipt-to:" header. I have found that only something like 50%
of the SMTP servers you run into return these, but I think it's usually just a
configuration issue. I have gotten return-receipts from NeXTmail, NT mail, OS/2
Sendmail, various varieties of *nix sendmail, etc. The above variation is in
traditional format, although you are increasingly seeing them with MIME
formatting nowadays.
So the answer to Wei Kang Chen's (shouting) question is yes, it IS something
on the receiving end that determines whether you get a return receipt or not.
I don't think the RFC for SMTP stipulates that you must support this
functionality, although it is either an optional extension or a de-facto one
at this point.
Phil
--
Philip J. Koenig Computers & Communications [see below]
I have anti-spammed my email address. Please direct email to the following
"expanded" address: "p j k @ aimnet . com" (remove spaces and quotes)
Philip J. Koenig
tre...@sirius.com wrote:
>I don't think I like the idea of return receipts because it potentially
>doubles the traffic (or at least, the number of messages). It irritates me
>that, at work, they installed cc:Mail on ~1,500 workstations, and left the
>receipt option turned on. Few people at work have had the bright idea of
>turning it off, and only using it when they really need it.
Undoubtedly it was stupid for whoever installed CCmail to set it to request
return receipts by default, but I don't think that makes it a "bad feature".
In a LAN environment, there is another extension to that functionality which
can be even more useful, which is to notify the sender when the sent mail is
READ (or at least opened) by the recipient. Some companies, admins, or users
don't like that feature because they feel it is an invasion of privacy, but
for others it is really handy. There is no reliable method of doing the same
thing on the Internet because of the wide variation in email clients used, and
the lack of a "company policy" that covers the whole world. :-) (some SMTP/POP3
email clients can do it, but of course you can't dictate which email client the
recipients of all your email use)
>For people downloading mail off a server via POP, is the return receipt
>generated when the server receives the email, or when the user downloads
>the mail from the server?
The receipt is generated when the destination SMTP server receives the incoming
message and deposits it in the spool directory for the user in question. If for
example the user does not exist, no return-receipt will be generated and you
will usually get a bounceback message instead.
Whether the user ever reads the incoming message, or if their email client
corrupts or otherwise loses the message is not addressed by the return-receipt
since it is generated before the user reads or retrieves the message.
Personally, I value this functionality because it is an excellent method of
verifying that your message was received by the destination site. Reliability
of ISP's being what they are, and variability of the sundry Internet transport
mechanisms being what THEY are, it is nice to get some assurance that your
message "made it". OTOH, if I engage in regular correspondence with certain
individuals and I trust the connection to be reliable, I usually turn it off
because it becomes more of an annoyance than a help.
Phil
--
Philip J. Koenig Computers & Communications [see below]
I have anti-spammed my email address. Please direct email to the following
"expanded" address: "p j k @ aimnet . com" (remove spaces and quotes)
Your pilot has turned on the "Put on your flameproof armor" sign...
John Navas
[POSTED TO ba.internet]
tre...@sirius.com wrote:
>I don't think I like the idea of return receipts because it potentially
>doubles the traffic (or at least, the number of messages). ...
Without receipts, you have no way of knowing when your important message
disappeared into the bit bucket.
--
Best regards,
John mailto:JNa...@NavasGrp.Dublin.CA.US http://www.aimnet.com/~jnavas/
FIGHT EXCESSIVE DOMAIN NAME FEES: <http://www.aimnet.com/~jnavas/namefee.html>
Philip J. Koenig
gr...@calvin.oriole.sbay.org (George Bonser) wrote:
>Your mseeage can STILL go into the bit bucket even with a return receipt.
>All the return receipt says is that the destination machine accepted the
>message, there is no guarantee that the message actually made it to the
>user's mailbox where it could be read. It might travers a few mail filters
>where it might "hit the screen" and be "spooled" to /dev/null!
>What we need are mail USER agents that return a receipt when the message is
>read.
Continuing along your same vein, there is nothing that can prove a message
is READ, only that it is OPENED. Etc. etc.
There are many who feel that an involuntary "message read" notification is
an invasion of privacy. LAN-based email has had this capability for quite
a while (as I pointed out in an earlier response to Trebor's comment), but
many do not implement it for this reason. Do you want spammers to know
when you read their garbage.. or that you read a stalker's threat before
you have a chance to report it to the authorities?
There are POP3 email clients (i.e. Pegasus) that support the message-has-
been-read return receipt, but it requires the same email client on both
ends of the mail communication, and the user has to turn it on.
I'll settle for knowing the message got to the destination domain, personally.
Phil
>In article <32b2ebef...@news.aimnet.com>,
> JNa...@NavasGrp.Dublin.CA.US (John Navas) writes:
>> [POSTED TO ba.internet]
>> tre...@sirius.com wrote:
>>
>>>I don't think I like the idea of return receipts because it potentially
>>>doubles the traffic (or at least, the number of messages). ...
>>
>> Without receipts, you have no way of knowing when your important message
>> disappeared into the bit bucket.
--
dh...@spams.r.us.com
In <32b2ebef...@news.aimnet.com> JNa...@NavasGrp.Dublin.CA.US
(John Navas) writes:
>Without receipts, you have no way of knowing when your important message
>disappeared into the bit bucket.
It depends on the location of the bit bucket, no?
--
Rahul Dhesi <dh...@ether.rahul.net>
a2i communications network operations
Philip J. Koenig
dh...@spams.r.us.com wrote:
>In <32b4f72c...@news.aimnet.com> JNa...@NavasGrp.Dublin.CA.US
>(John Navas) writes:
>>>What we need are mail USER agents that return a receipt when the message is
>>>read.
>>Pegasus Mail. The option can be turned on or off.
>Does it require implanting a probe in the brain of the user? Or is it
>able to simply reflect a beam of the light off the users' pupils and
>detect their motion?
Some kind of neural network I hear. ;-)
Phil