Re: /dev/null analog for email messages?
John H Meyers
> Is there any standard or conventional "black hole" dummy email address,
> analogous to /dev/null for writing to files?
>
> (i.e., if you send an email message to this address, it will be accepted
> by the email system, but immediately dumped, with no reply or "bounce"
> of any kind.)
Some domains may set up a specific email address, e.g. nob...@my.domain
which is configured to append all arriving new messages to (guess what?
that's right: /dev/null :)
Even though we have configured some such addresses in our domain,
we do not welcome having our bandwidth used up by receiving
tons of mail to be disposed of in this way (and your own ISP might
also not welcome having such mail sent to its SMTP servers by your client).
Also, under a former (klutzy) administrator, someone once actually
_deleted_ the "special file" /dev/null from our Unix file system,
resulting in... guess what? That's right: all data directed to /dev/null
being actually indefinitely appended to a real file on disk, as well as any
"read" operations upon /dev/null actually reading back all the accumulated data,
rather than immediately returning the expected immediate "end of file" !!!
There do exist internet "DNS" registrations for "dummy" domains,
e.g. http://www.example.com and http://www.example.org
and you can safely publish email addresses like any...@example.com
in illustrative documentation, but AFAIIA the email RFCs (standards)
do not define any email addresses to simply be ignored,
by either email clients or SMTP servers,
so any normal attempt to send email to such addresses
eventually results in a DNS "MX lookup" for a real mail server
to accept mail for that domain, which will always fail, e.g.:
<http://mxtoolbox.com/SuperTool.aspx?action=mx%3aexample.com>
In other words, this domain exists, and even has a DNS "A" record
for a (real) web server, but accepts no mail.
Curiously enough (actually it's probably common),
our own SMTP server initially accepts such mail addresses anyway
(perhaps I should adjust our config to change that :)
After starting a "telnet" client to contact smtp.my.domain
(lines beginning with numbers are server responses,
and other lines are typed by me, acting like an email client):
220 smtp.my.domain ESMTP
MAIL FROM: <m...@my.domain>
250 2.1.0 <m...@my.domain>... Sender ok
RCPT TO: <any...@example.com>
[after a long pause]
250 2.1.5 <any...@example.com>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
[message can now be transmitted]
After the message is queued by our SMTP server, however,
that server spends some time on it,
until it finally gives up and mails back a "bounce,"
which also is a non-productive waste of time.
If I leave my email address _empty_ or invalid in my client setup
(which some clients will permit, and most clients can be fooled
into doing anyway), "bounce" messages will not even come back to me,
but this is of course also an irresponsible approach to the issue.
Follow-up set to: comp.mail.eudora.mac
--
John H Meyers
> I'm asking about _sending_ email, to a list containing some known faulty
> addresses, without having to go through and cull out all the names that
> have faulty addresses.
If you had more clearly expressed your goal to begin with,
e.g. "I want to keep every spelled out name in my list,
but change each bad email address to one which will be accepted,
so that I can update the list later with the corrected addresses,
without having to remove and forget each entire address book entry as well,"
this could have been a much shorter thread!
What was your "solution" -- to replace each such address
with "nob...@my.domain" ? (a non-universal solution,
also inviting everyone else to dump their similar mailing list messages
into your own domain for disposal)
You noted that you could substitute your own local address instead,
and you can -- try this on some sample message, repeating your own address
several times in a dummy mailing list -- it's likely that you will receive
only _one_ delivered message, if the SMTP server is properly doing its job,
and this alternate method is more universally applicable than the "nobody" approach,
or almost all the other alternatives that I've now read (when I first responded,
not all of the thread had been reflected in my news client).
You can also include parenthesized comments in names or addresses,
e.g. "(was invalid)" because of an RFC spec allowing such comments in any headers.
John H Meyers
> As far back as I can remember, sending a message to multiple
> recipients with one or more invalid addresses causes the mail server to
> reply with a message indicating that delivery to *only the invalid*
> addresses failed, while other recipients received the message normally.
Only if the SMTP server _used by your client program_
_initially_ accepts _every recipient address_, in which case
the subsequent discovery of undeliverable messages
occurs asynchronously to the original mailing from your client,
in which case you get "bounces" queued and mailed back to the claimed sender,
rather than a client abort of trying to first send the message out at all,
when the client encounters even a single "bad address" response
from the SMTP server to which it "interactively" connects
while trying to initially send the message for you.
I now see that AES was, in effect,
following up a week later with a new question,
still not originally explaining his actual goal,
after having first posed a different original question,
to which I responded with this detailed explanation
of the fundamental difference between "client sending time" errors
and "errors discovered later by the postal system":
http://groups.google.com/group/comp.mail.eudora.mac/msg/9dd2995240b545b0
Followup-to: comp.mail.eudora.mac
--
John H Meyers
> Preventing the send to legitimate addresses because
> another address is incorrect is a silly practice, IMO.
There are often very valid (and even necessary) reasons
for why certain things are done in certain ways;
these reasons often become clear to us only after we have
more deeply investigated into the full details of how things work,
whereas our first, less than fully informed reaction
may be to regard them as silly, or to attribute them
to the wrong cause or agent, or to entirely misunderstand them.
I attempted to provide some further insights
(and to distinguish how two fundamentally different cases behave)
in a posting already referred to in my previous message:
"Transfer error? -- what happens when initial sending aborts"
http://groups.google.com/group/comp.mail.eudora.mac/msg/9dd2995240b545b0
--
John H Meyers
> Let's say i send a message to 50 people. Let's say
> I'm a bit of a n00b and I put all the addresses in the Cc: line.
>
> Three of the addresses are malformed, so I get an error.
>
> What do i do? Probably find the mistakes and RESEND THE ENTIRE MESSAGE TO
> ALL 50 PEOPLE. Of course I do, this makes sense to me. So, 47 people get
> the message twice
Not so -- if your "personal email client"
aborts the initial sending of a multiple-recipient single message,
when the SMTP server to which it connects immediately rejects any "malformed" address,
regardless of how you distribute those addresses between To/Cc/Bcc,
your message, as of that time, has NOT BEEN SENT TO ANYONE,
and that's why you always simply CORRECT OR DELETE THE IDENTIFIED BAD ADDRESS,
and then re-try to complete the INITIAL sending out of your message,
to try to get it as far as being even stored by the initial SMTP server!
Once you have finally managed to get that message to be stored
by your initial SMTP server, subsequent notifications of undeliverable
messages, to particular individuals or groups of recipients at each
separate domain, will be mailed back to the claimed original sender,
with specific lists of all the undeliverable addresses for each separate domain,
and a specific reason for each rejected address (this function is far too
complex -- nay, even actually impossible for non-local recipients -- to be conducted
by common _personal_ email clients, whereas it is exactly the sort of thing
which SMTP servers are specialized to do, so it's customary
to let each "actor" in the entire process do what it's specialized for,
and at the appropriate points in the entire internet email architecture).
In this case, you need send a NEW message (even if just a COPY of the original)
to ONLY those people who were listed in each bounce message,
certainly NOT not to your entire original list.
It's often the case (e.g. "Account closed") that we can never even
find a corrected address for people who have moved elsewhere,
and we have to remove them permanently from our list,
whereas in the case of things like "account temporarily over quota,"
it may be worth trying again, unless the reason that they are "over quota"
is that they have actually moved away and will never download and delete
any more old mail to make room for new mail, in which case
you will certainly have to give up trying, after some while.
Obviously this involves making many personal "judgment calls,"
upon detailed reading and interpretation of each "bounce" message,
and is quite challenging to fully automate.
For AES (remember him? -- he's who we started this discussion for :)
one other way to skirt the possibility of the initial SMTP server
not being willing to store a message at all, perhaps having
immediately detected that some of his colleagues' addresses
at his own university no longer exist or are "over quota,"
could be to use an outgoing (SMTP) server that isn't even in his own domain,
and which is lenient about pre-validating all domain names,
in which case only gross errors (e.g. address syntax)
are likely cause an abort during initial sending,
where immediate, interactive original list modification is required,
rather than permitting a leisurely response to subsequent "bounce" messages.
Like many other issues in life, there's both a "science" and an "art"
to devising a best strategy, which often require the gradual accumulation
of both knowledge and experience to refine and fully master.
I again repeat a previous link, to a posting which delves into
the complete internet email architecture, and contains links
to further images and a "wikipedia" article about how it works as a whole:
"Transfer error? -- what happens when initial sending aborts"
(as well as discussing the topic of subsequent "bounces")
John H Meyers
[Jolly Roger had said]
>> Preventing the send to legitimate addresses because another address
>> is incorrect is a silly practice, IMO.
And another response within this thread has further (incorrectly) assumed:
>> I'm greatly surprised that AES would have a server that would
>> act like that. If so, it is just a broken server.
Whereas all the SMTP servers,
both the one your personal client uses when sending to _all_ domains
and the ones which receive messages from that one,
to handle only each _specific recipient's domain_,
are all speaking the same common language
and responding in essentially the same way:
Barry Margolin's astute reply:
> The server isn't preventing the send, the client is.
> [The server's] responding to a RCPT command with an error
> doesn't prohibit the client from continuing to send additional RCPT commands
> and the message data. However, none of the common mail clients do this.
> They all treat an error from the server for a RCPT command as a fatal error,
> and abort the transmission.
Precisely.
The initial sending by your personal client to its outgoing SMTP server,
for initial "message submission" into the internet email system,
usually upon manually clicking a "send" button in the personal client,
is treated as an _interactive_ session, expecting you to be present
to correct some obvious (or even not so obvious) mistake and re-try.
Once that "interactive" session is successfully completed,
you no are no longer directly interacting with your original
"message submission" server, having successfully
dropped off your accepted message at your Post Office,
which then attempts to forward the message
to each specific recipient's domain,
and _mails_ "undeliverable, return to sender" notices back
to the claimed original sender of the message.
Note that you may have claimed someone other than yourself
as the "sender address," or specified some account of yours
that is maintained somewhere else, perhaps even at some
web-based service, so if your client attempted to duplicate
the _mailing_ of address rejections ("bounces") in a batch,
to that address, you might not hear until long afterward
about a fatal syntax error in sending a message to even just one addressee,
and in this case you would probably prefer to have "interacted"
directly and immediately with your original "submission" server, would you not?
A _personal_ email client has to be designed with a wide perspective
on every potential scenario for every potential user,
and it's hardly surprising
that so many completely independently designed personal clients
have uniformly decided to work in essentially the same way,
their designers having thought the matter through much more deeply
than the first reactions of users just beginning to think about these things.
_Personal_ email clients are not the ideal vehicle
for sending out large mailings and maintaining large mailing lists,
any more than a personal automobile is suited
to delivering truckloads of goods to multiple destinations,
for which one should think of using commercial CRM/contact_management systems,
specialized complete in-house mailing list systems, or outsourcing the job
to specialized commercial vendors like "constant contact" etc.,
the same way as the USA has outsourced almost everything
except major weaponry and fast food serving
to the rest of the world that's now better educated
to do brain-powered tasks both cheaply and properly ;)
Would that we could also "outsource" our current national lawmakers;
then we might have a chance to regain what once we had.
--
John H Meyers
to bring in the wisdom of an authority
whose vision and common sense,
encapsulated in timeless humor and relevance,
expressed more than 100 years ago,
surpasses that of almost anyone alive today:
> On 5/03/2011 2:10 AM, someone wrote:
>> Let's say i send a message to 50 people. Let's say
>> I'm a bit of a n00b and I put all the addresses in the Cc: line.
>>
>> Three of the addresses are malformed, so I get an error.
>>
>> What do i do? Probably find the mistakes and RESEND THE ENTIRE MESSAGE
>> TO ALL 50 PEOPLE. Of course I do, this makes sense to me. So, 47 people
>> get the message twice [no they don't, as earlier explained]
[all of the following is a quoted excerpt from its source,
of which I was happily reminded by the above]
"How fast have we been going?"
"Because if we was going so fast we ought to be past Illinois,
oughtn't we?"
"Certainly."
"Well, we ain't."
"What's the reason we ain't?"
"I know by the color. We're right over Illinois yet.
And you can see for yourself that Indiana ain't in sight."
"I wonder what's the matter with you. You know by the COLOR?"
"Yes, of course I do."
"What's the color got to do with it?"
"It's got everything to do with it. Illinois is green, Indiana is pink.
You show me any pink down here, if you can. No, sir; it's green."
"Indiana PINK? Why, what a lie!"
"It ain't no lie; I've seen it on the map, and it's pink."
[...]
"Suppose there's a brown calf and a big brown dog, and an artist is
making a picture of them. What is the MAIN thing that that artist has got
to do? He has got to paint them so you can tell them apart the minute you
look at them, hain't he? Of course. Well, then, do you want him to go and
paint BOTH of them brown? Certainly you don't. He paints one of them
blue, and then you can't make no mistake. It's just the same with the
maps. That's why they make every State a different color."
http://www.online-literature.com/twain/tom-sawyer-abroad/3/
This same passage has also been cited by creatively inspired writers
who can make even "dull" mathematical subjects riveting and fascinating,
such as these:
http://www.amazon.com/Introduction-Geometry-Wiley-Classics-Library/dp/0471504580
http://www.scribd.com/doc/18433275/Explorations-in-Topology-Map-Coloring-Surfaces-and-Knots-D-Gay
:-)
John H Meyers
> You noted that you could substitute your own local address instead,
> and you can -- try this on some sample message, repeating your own address
> several times in a dummy mailing list -- it's likely that you will receive
> only _one_ delivered message, if the SMTP server is properly doing its job,
> and this alternate method is more universally applicable than the "nobody" approach,
> or almost all the other alternatives that I've now read (when I first responded,
> not all of the thread had been reflected in my news client).
I have just tried the following on Windows Eudora --
does it also work on Mac Eudora? Any other email applications?
I defined a "nickname" called "NobodyAtAll"
and for its address(es), I entered NOTHING
Then I sent a message to both that nickname and some real address.
Result -- no problem, the "nickname" having NO ADDRESS
"expands" to no address, and the message is sent only to the real address(es);
thus [NO ADDRESS AT ALL] could be the Grail which AES seeks, at least in Eudora.
This might be considered almost as Earth-shattering as the "invention"
of "zero" in the superior "Hindu-Arabic" number system,
and I was pretty self-satisfied until I was arrested for indecent exposure,
which had never originally happened to Archimedes :)
"Eureka! Eureka!" (Greek for "I have found it!")
http://www.visionlearning.com/library/module_viewer.php?mid=37
Apparently Tungsten was not yet known to the ancient Greeks:
http://www.chemicalelements.com/elements/au.html Density @ 293 K: 19.32 g/cm^3
http://www.chemicalelements.com/elements/w.html Density @ 293 K: 19.3 g/cm^3
Museum-grade Tungsten sample:
http://www.theodoregray.com/PeriodicTable/Elements/074/index.s7.html#sample36
http://gold-quote.net/en/articles/fake-tungsten-gold-bars.php
(may be pure fiction, other than that pure Tungsten
is indeed almost the exact same density as pure Gold)
http://www.amazon.com/Gold-Plated-Dome-Tungsten-Wedding/dp/B0041H91NU
(even this is slightly misrepresented -- it's Gold-plated Tungsten _Carbide_
with the words "tugsten carbide" also engraved on the inside,
lest you try to pawn it off as "solid Gold" to an unsuspecting buyer :)
Better numbers:
http://en.wikipedia.org/wiki/Hindu–Arabic_numeral_system
http://en.wikipedia.org/wiki/History_of_the_Hindu–Arabic_numeral_system
http://en.wikipedia.org/wiki/Arabic_numerals
However, the Tea Party has demanded that the USA adopt the preferred calculator
of the original Christians, threatening a filibuster if opposed:
http://imageshack.us/m/20/647/calc98.jpg
You can download that actual calculator
for any OS with "Windows" in its name, including Windows CE/Mobile (Pocket PC),
or even for the Casio BE-300 Pocket Manager family
http://calculator.org/download.aspx
(don't tell anyone that I told you,
but it can be easily switched to "Democratic Decimal" mode :)
And while "Rosetta" is still available
(throw the Lions to the Christians if not :)
http://www.macupdate.com/app/mac/6260/moosecalc-x/
--