/dev/null analog for email messages?
AES
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.)
Patty Winter
In article <siegman-4CBF36...@sciid-srv02.med.tufts.edu>,
I assume you mean within Eudora? Doesn't the "junk" function do
exactly that at the mail reader level?
The only way I'm familiar with using /dev/null is at the mail
server level, before it ever gets to either of my email programs.
I have procmail recipes set up to do just that with certain messages.
Does your mail service provider let you set up procmail recipes?
Patty
Jolly Roger
Assuming you are the server administrator, you can configure a mail
server any way you want, including special mail boxes for that sort of
thing.
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.
JR
Wes Groleau
You can simulate with sneakemail.com
--
Wes Groleau
There are two types of people in the world …
http://Ideas.Lang-Learn.us/barrett?itemid=1157
AES
Patty Winter <pat...@wintertime.com> wrote:
> >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.)
>
> I assume you mean within Eudora? Doesn't the "junk" function do
> exactly that at the mail reader level?
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 I don't cull these faulty addresses, each of them causes the entire
Send to bounce from the server -- and this only happens one faulty
address at a time.
I'd like to:
--Be able to keep every faulty-address _name_ in my list, even though I
know that these names have temporarily faulty (or unknown) addresses.
--Continue Sending to the _entire_ list, even though some of the names
on the list have temporarily faulty or unknown addresses.
--Do this by (temporarily) replacing all the unknown or faulty addresses
with a "/dev/null" address of the form
"Name of a faulty address person" <name...@address.null>
And when I learn (thru other channels) the correct address for any of
these faulty cases, I'll of course open up my list and correct that
instance.
I could of course use my own address as the /dev/null address -- but
that will bring a lot of messages into my inbox.
bi...@mix.com
> --Do this by (temporarily) replacing all the unknown or faulty addresses
> with a "/dev/null" address of the form
>
> "Name of a faulty address person" <name...@address.null>
"nobody" is a null account on most Unix systems, including OS X.
Mail to this account will be silently discarded.
So, you can use nob...@stanford.edu if you'd like, and Stanford doesn't
object to eating a few letters for you (I'm assuming not, since you have
an email account there already).
> I could of course use my own address as the /dev/null address -- but
> that will bring a lot of messages into my inbox.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
Jeffrey Goldberg
nob...@some-domain.example
This is a convention and not a standard. Not all domains handle these.
Cheers,
-j
--
Jeffrey Goldberg http://goldmark.org/jeff/
I rarely read HTML or poorly quoting posts
Reply-To address is valid
AES
Jeffrey Goldberg <nob...@goldmark.org> wrote:
>
> nob...@some-domain.example
>
> This is a convention and not a standard. Not all domains handle these.
>
> Cheers,
>
Seems to work like a charm with Stanford server -- thanks to all who
suggested this!
Daniel Cohen
> 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 I don't cull these faulty addresses, each of them causes the entire
> Send to bounce from the server -- and this only happens one faulty
> address at a time.
>
> I'd like to:
>
> --Be able to keep every faulty-address _name_ in my list, even though I
> know that these names have temporarily faulty (or unknown) addresses.
>
> --Continue Sending to the _entire_ list, even though some of the names
> on the list have temporarily faulty or unknown addresses.
>
> --Do this by (temporarily) replacing all the unknown or faulty addresses
> with a "/dev/null" address of the form
>
> "Name of a faulty address person" <name...@address.null>
>
> And when I learn (thru other channels) the correct address for any of
> these faulty cases, I'll of course open up my list and correct that
> instance.
You could try replacing
name@wrongaddress
by
na...@wrongaddress.invalid
I'm no expert, but I seem to remember discovering that addresses ending
in "invalid" are accepted by mailers but then thrown away.
--
<http://www.decohen.com>
The Labyrinth of the Heart: Changed Myths for Changing Lives
e-book <http://www.smashwords.com/books/view/29317>
Send e-mail to the Reply-To address, not the From address.
Jolly Roger
<siegman-03A303...@bmedcfsc-srv02.tufts.ad.tufts.edu>,
AES <sie...@stanford.edu> wrote:
> In article <4dbc9600$0$10577$742e...@news.sonic.net>,
> Patty Winter <pat...@wintertime.com> wrote:
>
> > >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.)
> >
> > I assume you mean within Eudora? Doesn't the "junk" function do
> > exactly that at the mail reader level?
>
> 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 I don't cull these faulty addresses, each of them causes the entire
> Send to bounce from the server
Not here. 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.
Richard Kettlewell
> AES <sie...@stanford.edu> wrote:
>> I'd like to:
>>
>> --Be able to keep every faulty-address _name_ in my list, even though I
>> know that these names have temporarily faulty (or unknown) addresses.
>>
>> --Continue Sending to the _entire_ list, even though some of the names
>> on the list have temporarily faulty or unknown addresses.
>>
>> --Do this by (temporarily) replacing all the unknown or faulty addresses
>> with a "/dev/null" address of the form
>>
>> "Name of a faulty address person" <name...@address.null>
>>
>> And when I learn (thru other channels) the correct address for any of
>> these faulty cases, I'll of course open up my list and correct that
>> instance.
>
> You could try replacing
>
> name@wrongaddress
>
> by
> na...@wrongaddress.invalid
>
> I'm no expert, but I seem to remember discovering that addresses ending
> in "invalid" are accepted by mailers but then thrown away.
There is no such general rule built into MTAs; the best you can say is
that no valid domain ends ".invalid", leading to such addresses bouncing
early.
The OP is going about this the wrong way. The right approach is to
separate the bad entries from the good, send only to the latter, and put
the former back in when new, valid, addresses become available.
Richard Maine
> In article
> <siegman-03A303...@bmedcfsc-srv02.tufts.ad.tufts.edu>,
> AES <sie...@stanford.edu> wrote:
> > 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 I don't cull these faulty addresses, each of them causes the entire
> > Send to bounce from the server
>
> Not here. 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.
Yes, I'm greatly surprised that AES would have a server that would act
like that. If so, it is just a broken server. I'd think it better to
find a more reliable mail server than to try to hack around the problems
in a broken one.
It does occur to me that he might just be misinterpreting the bounce
message, though. I just now did a test, addressing an email message to
both myself and ju...@nosuch.place.com. I suppose I can see how someone
might misread what the bounce message is saying. It said, in part,
"A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
The copy addressed to myself did go through fine.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Barry Margolin
Jolly Roger <jolly...@pobox.com> wrote:
> In article
> <siegman-03A303...@bmedcfsc-srv02.tufts.ad.tufts.edu>,
> AES <sie...@stanford.edu> wrote:
>
> > In article <4dbc9600$0$10577$742e...@news.sonic.net>,
> > Patty Winter <pat...@wintertime.com> wrote:
> >
> > > >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.)
> > >
> > > I assume you mean within Eudora? Doesn't the "junk" function do
> > > exactly that at the mail reader level?
> >
> > 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 I don't cull these faulty addresses, each of them causes the entire
> > Send to bounce from the server
>
> Not here. 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.
It depends on the type of bad address, and when the SMTP server does its
checks.
If the problem is the account name, the server will usually accept the
message when you submit it, but send back a bounce message later when it
tries to deliver it.
If the problem is with the domain name, many servers check that during
submission. They send back an error immediately, and most mail clients
abort uploading the message.
If you're sending to an address in the domain of the server, it may also
check account names immediately. If you're a Comcast customer, try
sending to nonexiste...@comcast.net and you'll get an error ("Not
a customer") during the send, not a bounce message later.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Barry Margolin
nos...@see.signature (Richard Maine) wrote:
That's because the domain nosuch.place.com exists, which is good enough
to pass the check during sunmission. Try again with ju...@xxxxplace.com,
which is a nonexistent domain.
Richard Maine
Ok. Tried that. Pretty much the same. Different in the details of the
message (the part after where I stopped quoting above), but same result
in that the copy to myself came through fine, while the bad one bounced.
"A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:
ju...@xxxxplace.com
The mail server could not deliver mail to ju...@xxxxplace.com. The
account or domain may not exist, they may be blacklisted, or missing the
proper dns entries."
David Empson
> In article
> <siegman-03A303...@bmedcfsc-srv02.tufts.ad.tufts.edu>,
> AES <sie...@stanford.edu> wrote:
>
> > In article <4dbc9600$0$10577$742e...@news.sonic.net>,
> > Patty Winter <pat...@wintertime.com> wrote:
> >
> > > >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.)
> > >
> > > I assume you mean within Eudora? Doesn't the "junk" function do
> > > exactly that at the mail reader level?
> >
> > 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 I don't cull these faulty addresses, each of them causes the entire
> > Send to bounce from the server
>
> Not here. 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.
That depends on the outgoing mail server.
I've encountered at least one which checked addresses on the same site
immediately. If any of the local addresses had an immediately detectable
error, the entire send failed, but if all the local addresses were
valid, it would send to every local and remote address (some of which
might bounce).
--
David Empson
dem...@actrix.gen.nz
Jolly Roger
dem...@actrix.gen.nz (David Empson) wrote:
I figured as much. I think if I encountered that behavior, though, I'd
start looking for a better mail service provider!
Barry Margolin
Jolly Roger <jolly...@pobox.com> wrote:
As I mentioned in my earlier post, the Comcast mail servers work that
way.
And they check the domain part of all addresses, to make sure it
resolves.
The only thing they don't check immediately is the account part of
remote addresses, as that would be too slow.
Jolly Roger
<barmar-07F2E5....@reserved-multicast-range-not-delegated.exa
mple.com>,
Barry Margolin <bar...@alum.mit.edu> wrote:
Preventing the send to legitimate addresses because another address is
incorrect is a silly practice, IMO.
Jeffrey Goldberg
> In article
> <barmar-07F2E5....@reserved-multicast-range-not-delegated.exa
> mple.com>,
>> As I mentioned in my earlier post, the Comcast mail servers work that
>> way.
>>
>> And they check the domain part of all addresses, to make sure it
>> resolves.
>>
>> The only thing they don't check immediately is the account part of
>> remote addresses, as that would be too slow.
>
> Preventing the send to legitimate addresses because another address is
> incorrect is a silly practice, IMO.
This is an age old debate among mail system administrators. Some of this
is historical and has to do with when most people just mailed others on
the local server.
Suppose you wish to send a message to f...@gmail.com but address it to
f...@gmail.comm. Would you rather be notified immediately in your mail
client that that your out-going SMTP server couldn't resolve gmail.comm,
or would you rather have the SMTP server accept it and then generate a
bounce to email back to you. Most people would prefer the former.
No suppose you compose that same message to f...@gmail.comm but also cc
it to b...@gmail.com. What should happen then? What if there are three
addresses? What if there are four, two of which are immediately
rejectable and the other two not?
Also from the server administration point of view the policy of "reject
early, reject often" is important. It is better to reject a message
during SMTP time then to accept the message and then generate a bounce.
So I do not find Comcast's configuration "wrong", although it is not how
I would configure things for an ISP's mail submission server. Even
though this process is less likely to result in undelivered mail that
the sender doesn't know about and is more efficient in other ways, it
confuses users.
Barry Margolin
Jolly Roger <jolly...@pobox.com> wrote:
The server isn't preventing the send, the client is.
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.
Wes Groleau
> I could of course use my own address as the /dev/null address -- but
> that will bring a lot of messages into my inbox.
Define a rule to delete them
Jolly Roger
Lewis <g.k...@gmail.com.dontsendmecopies> wrote:
> In message <jollyroger-49F3C...@news.individual.net>
> Jolly Roger <jolly...@pobox.com> wrote:
> > Preventing the send to legitimate addresses because another address is
> > incorrect is a silly practice, IMO.
>
> There are two sides. 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, but if THEY reply to the 50 Cc in the first message,
> they only reply to the 47 people in that Cc: and miss the other three
> users.
>
> If you know the message will fail for some reason, then fail at that
> point and give the user a chance to fix it. Seems reasonable.
Not to me, it doesn't. If I send a message to a person's correct
address, I expect it to be delivered to that person. The rejection
message you receive from the server tells you which addresses were
incorrect. From that point, you get to *choose* whether you want to
resend to all or send only to the people whose addresses were incorrect.
I'd rather have that choice.
John H Meyers
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/
--
Anne Wrigley
Your Name
sites (Gmail, Yandex, GMX, ...), and then don't bother logging into it.