return-receipt ?
Arioch
notice when the mail is deivered and/or read ?
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
Robin Zalek
wrote:
> no, in Opera 10.50, is there button to request of the recipient to send
> me notice when the mail is deivered and/or read ?
>
>
No, return receipts are useless. At best they can tell you that some SMTP
server than your own received the message.
They can't tell you if it wasn't received, as sometimes people just
disable sending them. And they can't tell you it was received/read even if
you do receive one, as sometimes they'll get sent by systems other than
that of the intended recipient.
If you receive a receipt, it proves nothing; if you don't, it also proves
nothing. As such Opera have never implemented either sending, or
requesting such receipts.
--
Do the obvious to get the email.
Arioch
<bte...@spammygoodness.gmail.com> сообщал:
> No, return receipts are useless. At best they can tell you that some
> SMTP server than your own received the message.
> They can't tell you if it wasn't received, as sometimes people just
> disable sending them. And they can't tell you it was received/read even
> if you do receive one, as sometimes they'll get sent by systems other
> than that of the intended recipient.
it surely is not 100% warranty, but somtimes better than nothing
> If you receive a receipt, it proves nothing; if you don't, it also
> proves nothing. As such Opera have never implemented either sending, or
> requesting such receipts.
in earlier Opera i remember i saw requesting receipt, and AFAIR i also saw
request to send receipt...
John H Meyers
> return receipts are useless. At best they can tell you that some
> SMTP server than your own received the message.
> They can't tell you if it wasn't received, as sometimes people just
> disable sending them. And they can't tell you it was received/read even
> if you do receive one, as sometimes they'll get sent by systems other
> than that of the intended recipient.
>
> If you receive a receipt, it proves nothing; if you don't, it also
> proves nothing. As such Opera have never implemented either sending, or
> requesting such receipts.
Sounds similar to politicians' logic for not doing anything about anything.
Between people who agree to accept and return "Message Delivery Notifications,"
the use of an automatically mailed request and acknowledgment
is a great saving of effort over having to manually ask and then manually reply
to every message, just to confirm "I got your message."
The point of this is just like the "roger" of old radio communications,
and it is not to "prove" anything, but to generally confirm when the other person
has "heard you" (as opposed to your message being "deferred" by a busy or
"greylisting" server, for example, or falsely quarantined as spam,
or garbled, or even accidentally mis-filtered or deleted), and to _save_effort_
by automating this, so as not to have to manually ask and remember to reply every time.
It is also improper for any SMTP server to return an MDN by itself,
so that's another specious argument (I'm talking about MDN, not DSN,
since the former is what's nearly universally meant by "return receipt" nowadays).
It takes a lot of long-winded effort to try to justify not having this,
whereas it's as plain as the light of day to see why it would be a boon
to have it, except when a vendor doesn't want to bother with the little extra
to make it better and easier for the user, or else there aren't enough users
who realize why they are worse off having to use a more primitive client.
On the requesting side, it's merely a matter of inserting a single header line:
Disposition-Notification-To: <SameAs@ReturnPath>
For details of the response, see
http://tools.ietf.org/html/rfc3798
MDN vs. DSN
http://en.wikipedia.org/wiki/Return_receipt
--
Naruki Bigglesworth
If you have two people who agree to toss their privacy out the window, fine. People do strange
things all the time. But that is generally not something individuals would wish to do if they
understood how it can be used against them.
I always turn it off, because it's plain as the light of day that it can be used against you.
Indeed, in some companies that's the only reason it's imposed.
John H Meyers
every time I replied with a "thanks for your message/info/file/photo/etc."
and vice-versa for everyone who acknowledges receiving things from me.
Come to think of it, I shouldn't even have phoned to thank Aunt Mary
for her birthday card -- you never know when these things
might be used against us.
Come to think of it, even the "beep" on my answering machine,
which confirms that it recorded an incoming message,
might again put me in jeopardy, as I now realize.
--
David W. Hodgins
> Thanks -- I never realized that I was "tossing my privacy out the window"
> every time I replied with a "thanks for your message/info/file/photo/etc."
While I understand where you are coming from in your sarcasm,
the options of return receipt has been frowned upon, due to
abuse by spammers, using it to validate email addresses that
they can then sell to other spammers.
Like many other options on the internet, such as open relays,
the abuse of a few have made it a requirement of all isps to
block those options.
Returning a receipt message on opening an email message is
normally now limited to messages within one email system.
Allowing the sending of such receipts over the internet is
just asking for more spam.
While I agree with you, that the option should be available,
I know from prior experience, that it should default to being
off, if available at all. This particular option has never
been of any real use, over the internet, as very few email
clients have it implemented.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
Andrew Rybenkov
> for her birthday card -- you never know when these things
> might be used against us.
Excellent. LOL!
--
Andrew Rybenkov
John H Meyers
> The options of return receipt has been frowned upon, due to
> abuse by spammers, using it to validate email addresses that
> they can then sell to other spammers.
The mere lack of a negative response "validates" most addresses anyway,
except for lack of validation of the foolishness
of anyone who actually replies to a spammer.
It is, meanwhile, impossible to abuse an MDN,
if the recipient has to respond by clicking some "OK" button,
other than by that same foolishness.
It is also impossible for even an _automatic_ "yes"
to send an MDN if the mail isn't even opened,
and if the logic of the user's agent is to only
offer to send the MDN upon closing an already opened message
(this is Eudora's sensible logic, for example).
It is likewise impossible for quarantined or user-deleted spam
to generate an MDN, since it never reaches that point.
A spammer, meanwhile, would have to furnish a valid address
to be able to receive back any MDNs, and it surely would be as easy
to limit floods of incoming MDNs to web-based accounts (e.g. Hotmail)
or ISP accounts as it is to limit floods of outgoing mail from
these very same accounts.
Surely, intelligent spammers can get much better returns
out of having an HTML message fetch anything via a URL,
for which they do not even need to receive return email,
or get victims to visit some web URL to address some dire threat,
or to view some tempting content, or whatever.
The spammer who can "social engineer" people to respond to an MDN
can surely also trick all these various other responses out of naive people,
so denying implementation of MDNs is IMO as useful to reducing spam
as taxing the homeless is to reducing the national debt.
Meanwhile, non-voluntary and _non-disclosing_ methods such as
http://www.didtheyreadit.com/ are _surreptitiously_ returning
"read receipts" anyway, which IMO makes it quite a hypocrisy
to speak of voluntary MDNs as an "invasion of privacy,"
when they are actually the fully transparent opposite.
Any private, corporate system is already capable of internally tracking
all fetching of messages, so forget about privacy there,
if the company wants to keep tabs on every such action.
In short, every "reason" offered for not handling standard MDNs
is IMO a faulty rationalization, if not a mere excuse.
Now let's all go watch our senators and congressmen do the same :)
--
Naruki Bigglesworth
> On 3/10/2010 2:11 AM, David W. Hodgins offered:
>
>> The options of return receipt has been frowned upon, due to
>> abuse by spammers, using it to validate email addresses that
>> they can then sell to other spammers.
>
> The mere lack of a negative response "validates" most addresses anyway,
This right here is why we can't have nice things. People like you make absurdly ridiculous
statements like that, secure in the righteous knowledge that reality has it the wrong way
around.
Oh, and your Aunt Mary won't leave me alone, which is why I never return receipts to her. Never
should have given her that pity shag.
Arioch
<jhme...@nomail.invalid> сообщал:
> offer to send the MDN upon closing an already opened message
> (this is Eudora's sensible logic, for example).
this fails if preview panel is shown and mail is short enough to fit that
panel w/o scrolling
though the effort is good, really
Arioch
<dwho...@nomail.afraid.org> сообщал:
> This particular option has never
> been of any real use, over the internet, as very few email
> clients have it implemented.
Windows-defaut Outlook Express had this option
WWW-mail services usualy have this, at least the recepient's side.
That usualy seems to be very large share.
I suspect, Web-mail is client no.1 today and OE/WM/LM is no.2
Arioch
<Nar...@nothankyou.com> сообщал:
>> The mere lack of a negative response "validates" most addresses anyway,
>
> This right here is why we can't have nice things. People like you make
> absurdly ridiculous
> statements like that, secure in the righteous knowledge that reality has
> it the wrong way
> around.
it would be interesting to know why spammers can not validate address by
presence or lack of "no such user" error.
i do not talk about usual spam with no back-address, i speak about
specially crafted spam exactly to test address for existense
Naruki Bigglesworth
> В письме от Thu, 11 Mar 2010 03:12:32 +0300, Naruki Bigglesworth
> <Nar...@nothankyou.com> сообщал:
>
>>> The mere lack of a negative response "validates" most addresses anyway,
>>
>> This right here is why we can't have nice things. People like you make
>> absurdly ridiculous
>> statements like that, secure in the righteous knowledge that reality has
>> it the wrong way
>> around.
>
> it would be interesting to know why spammers can not validate address by
> presence or lack of "no such user" error.
>
> i do not talk about usual spam with no back-address, i speak about
> specially crafted spam exactly to test address for existense
No response at all (i.e., lack of negative response) means nothing to the spammer. His spam may
have gotten lost, it may have been discarded (the usual case), or it may have been forwarded to
the user. He has no way of knowing.
A negative response, on the other hand, tells him the address is invalid. If he can count on
this sort of information, he can test for valid addresses by seeing which ones don't report
invalid. This is the main reason those negative responses are discouraged.
John H Meyers
JHM:
>> The mere lack of a negative response "validates" most addresses anyway
NB:
> This right here is why we can't have nice things.
> People like you make absurdly ridiculous statements like that.
It is the basis of "Directory Harvest Attacks,"
which obtain valid addresses by simply seeing what isn't rejected:
http://www.pcmag.com/article2/0,2817,1543581,00.asp
--
John H Meyers
Arioch:
>> it would be interesting to know why spammers can not validate address by
>> presence or lack of "no such user" error.
>>
>> i do not talk about usual spam with no back-address, i speak about
>> specially crafted spam exactly to test address for existense
NB:
> No response at all (i.e., lack of negative response)
> means nothing to the spammer. His spam may have gotten lost,
> it may have been discarded (the usual case),
> or it may have been forwarded to the user. He has no way of knowing.
What meaning of "response" is meant here?
SMTP servers either reject or accept each individual address presented;
there is no such thing as a "no response," in this sense.
By sending an initial RCPT TO: an utterly random "address,"
e.g. <iuhdda987...@realdomain.com>
one may determine at once whether it is configured
to return a "250 OK" for every possible address or not;
if it rejects even this one, with a "no such user" code,
then a "Directory Harvest Attack" may proceed,
so far as other defenses may allow.
> A negative response, on the other hand, tells him the address is invalid.
> If he can count on this sort of information, he can test for valid addresses
> by seeing which ones don't report invalid.
> This is the main reason those negative responses are discouraged.
Any idea what percentage of all domains don't report invalid RCPT TO
during SMTP?
Those that don't are unfortunately incurring other penalties,
such as that senders who have typed and misspelled addresses
can not find out, correct, and re-send, causing completely lost communications.
Imagine if this were done with all telephone systems,
causing all "wrong numbers" to receive fake "leave a message" offers,
accepting but then discarding everything. How nice.
There is one thing that DHAs and other means of discovering valid addresses
do not provide, which is to find live users who will also personally
take the bait and manually respond -- no doubt these are the most valuable prizes,
as opposed to potentially unattended mailboxes.
As to the significance to the topic of Return Receipt (MDN in particular),
the MDN is normally voluntary and approved manually,
only after the recipient has had the actual incoming message on-screen,
which is about as far as one can go ("you can lead a person
to his message, but you can't make him read" :)
Recipients can also elect to suppress them all,
or to automatically approve all -- the latter would not be entirely wise,
but one can not enforce wisdom, the lack of which
exposes one to many other forms of more subtle exploitation anyway.
With Opera, however, no user can either request or respond to an MDN;
this does simplify life, even if by reducing its useful greater potential.
Various clients provided by Microsoft for Windows
do provide this, however, as does Thunderbird, Eudora, ...
so there is no shortage of better alternatives.
--
John H Meyers
>> offer to send the MDN upon closing an already opened message
>> (this is Eudora's sensible logic, for example).
> this fails if preview panel is shown and mail is short enough to fit
> that panel w/o scrolling, though the effort is good, really
I haven't tried testing to see, but it seems sensible,
since many use only the "split pane" to read everything,
so all that we can reasonably assure, before asking
whether the user wants to acknowledge a confirmation request,
is that the message has been on-screen, enough to see,
which is about as far as one can go ("you can lead a person
to his message, but you can't make him read" :)
--
John H Meyers
> Any idea what percentage of all domains don't report invalid RCPT TO
> during SMTP?
>
> Those that don't are unfortunately incurring other penalties,
> such as that senders who have typed and misspelled addresses
> can not find out, correct, and re-send, causing completely lost
> communications.
Well, there is another configuration which can avoid this,
yet does initially accept all SMTP addresses presented,
where a "public-facing" MX server for a domain
accepts everything, then an "internal" server
rejects invalid forwarded addresses,
then the first server sends separate "bounces"
Other arrangements are possible to get the same end result,
which de-couples the domain's initial SMTP reception from a response,
and makes it harder to match up later -- it also requires
a working "Return-Path" address to collect the bounces.
However, most all "bounces" that I ever see
are reported by our own outgoing domain's SMTP server,
having been immediately rejected upon presentation
to the remote domain's incoming (MX) server,
including some of the world's largest domains
(e.g. Gmail, Hotmail, and Yahoo)
--
Arioch
<Nar...@nothankyou.com> сообщал:
> No response at all (i.e., lack of negative response) means nothing to
> the spammer. His spam may
> have gotten lost, it may have been discarded (the usual case), or it may
> have been forwarded to
> the user. He has no way of knowing.
if it was discarded that means there was an address to discard from
no time for 1nd task, craft spam to this verified address so disguised
that it bypass filters
> A negative response, on the other hand, tells him the address is
> invalid. If he can count on
> this sort of information, he can test for valid addresses by seeing
> which ones don't report
> invalid. This is the main reason those negative responses are
> discouraged.
you cannot discourage it too far
that woud add to e-mail unreliability for human usersm that no more would
te if they mailed right or wrong pace
Jeez, there are simplier methods like auto-whiteisting with autogenerated
"confirm" ticket sent few hours ago, like differen SMTP ports for cients
and for other mail servers.... and sti providers don't make it
all-together-now
They would not be able to discurage error processing all-at-once :-)
John H Meyers
> Returning a receipt message on opening an email message is
> normally now limited to messages within one email system.
What limits it? and how?
No one blocks mine -- I know of one special circumstance, however:
In section 3 of
http://www.faqs.org/rfcs/rfc2298.html
"The envelope sender address (i.e., SMTP MAIL FROM) of the MDN
MUST be null (<>), specifying that no Delivery Status Notification messages
or other messages indicating successful or unsuccessful delivery
are to be sent in response to an MDN."
If this is obeyed, then certain SMTP servers, such as ATT/Yahoo's,
are programmed (mistakenly) to look only at the MAIL FROM address,
rather than waiting for the actual "From:" header, to see whether it is
either the authenticating user's address or a pre-confirmed alternate,
hence this (mistaken) logic leads to rejecting the returned receipt,
as the immediate response to the initial MAIL FROM
(the very first command of a transaction,
before anything else whatsoever is known about the message,
not even _to_ whom it will be sent).
No problem for intelligent Eudora, however,
which has an internal option MDNSendAddress=1
telling Eudora to technically violate the RFC,
by sending the normal address in MAIL FROM
(the very first SMTP command to start sending a message),
thus overcoming Yahoo's uninformed programming,
which rejects such messages before having the slightest clue
about the actual content to follow.
> Allowing the sending of such receipts over the internet
> is just asking for more spam.
I don't think it's any more "asking for more spam"
than is letting people walk across a road
"just asking for them to be run over,"
unless they are small children
(who shouldn't have email accounts :)
In particular, that same RFC emphasizes:
"While Internet standards normally do not specify
the behavior of user interfaces, it is strongly recommended
that the user agent obtain the user's consent before sending an MDN.
This consent could be obtained for each message
through some sort of prompt or dialog box..."
This, and other fine points in the entire spec,
are designed for the recipient's safety and security,
making everything obvious and optional,
and I can see no more reason to try to deny access to this feature
than to try to deny clicking directly on "reply,"
or on anything which "links" anywhere,
or denying viewing any images (with no option to show them) etc.
I'd like to see a "pie chart," if only the statistics were available,
of how much spam originates by getting the user's address in various ways,
in which I'd expect the requesting of confirmations of receipt via a voluntary
response to a pop-up request to be of low significance.
> While I agree with you, that the option should be available,
> I know from prior experience, that it should default to being
> off, if available at all.
Fine.
> This particular option has never
> been of any real use, over the internet, as very few email
> clients have it implemented.
The most-used clients in the world (by Microsoft and Mozilla) implement it;
how about another pie chart on this?
But notable exceptions are popular web-based (free) systems,
and....... Opera.
--