Well, this is sad:
V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian
<http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html>
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
>Well, this is sad: > V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian ><http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html> It's more just strange. Looking at the article and the pictures that go with it, can anyone figure out what it was he was doing? R's, John
--On Saturday, February 18, 2012 23:50 +0000 John Levine <johnl <at> taugh.com> wrote: > >> Well, this is sad: >> V.A. Shiva Ayyadurai: Inventor of e-mail honored by >> Smithsonian >> <http://www.washingtonpost.com/national/on-innovations/va-shi >> vaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02 >> /17/gIQA8gQhKR_story.html> > > It's more just strange. Looking at the article and the > pictures that go with it, can anyone figure out what it was he > was doing? Not a clue, especially since email was in very active use at MIT over a decade earlier than his supposed invention (on CTSS) and there was ARPANET FTP-based email in active use on ITS and Multics in the first half of the 70s. john
For reference, I just sent this message: Date: Sat, 18 Feb 2012 17:14:29 -0800 From: Dave CROCKER <dhc <at> dcrocker.net> Reply-To: dcrocker <at> bbiw.net Organization: Brandenburg InternetWorking To: Peggy Kidwell <kidwellp <at> si.edu> CC: Emi Kolawole <emi.kolawole <at> washtingtonpost.com> Subject: V.A. Shiva Ayyadurai's purported invention of email Ms. Kidwell, Hello. I just saw the Washington Post article about V.A. Shiva Ayyadurai's work being acknowledged by the Smithsonian as the invention of email. In the video associated with the article, he cites contact with you. So I thought you might be appropriate to contact for possible followup through the Smithsonian. I'm trying to copy Post article's author, but am guessing at her email address. Unfortunately, Ayyadurai's work was not even close to the earliest email. Email dates back to the 1960's with the earliest computer timesharing systems, such as at MIT. Networked email was invented by Ray Tomlinson at Bolt, Beranek & Newman (BBN) in 1971; the email object from then looks remarkably similar to the basic message that Internet Mail; the service has actually been in continuous operation since then.(Continue reading)
Dave, I hope you continue following up on this. Even in his wikipedia (I presumed self created), he doesn't claim to be the inventor and pointed out there was existing systems. But he registered the copyright the term "EMAIL" and I guess from there, any layman may assume he invented email: http://en.wikipedia.org/wiki/Shiva_Ayyadurai#EMAIL_management Prior to becoming a student at the Massachusetts Institute of Technology, while a high school student at Livingston High School, New Jersey, he implemented an email system at the medical school of University of Medicine and Dentistry of New Jersey (UMDNJ). Email had been previously sent on other networks such as AUTODIN, PLATO and ARPANet. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ But he is claiming as the first to tie a database: This was the first database-driven system that translated all elements of an inter-office memorandum/mail, then in paper form, along with features of Inbox, Outbox and Folders, to an electronic mail format. In 1981, this system was recognized by the Westinghouse Science Talent Search receiving an Honors Award. Later, in 1982,(Continue reading)
Hector Santos <hsantos <at> santronics.com> writes: > This was the first database-driven system that translated all > elements of an inter-office memorandum/mail, then in paper form, > along with features of Inbox, Outbox and Folders, to an electronic > mail format. In 1981, this system was recognized by the Westinghouse > Science Talent Search receiving an Honors Award. Later, in 1982, the > US Copyright Office issued him the first copyright of his system > called “EMAIL”. [11][12] [...] > But he went ahead and copyrighted the term "EMAIL" and some how was > awarded the copyright. Note that it says "copyright," not "trademark," so this isn't about the term. The US Copyright Office doesn't care what you call things. Presumably he registered a copyright on the source code of his system, which happened to be called EMAIL. You can pay the US Copyright Office for a registered copyright on any creative work you want provided you fill out the right forms. It doesn't imply any approval or legal recognition; it's just helpful if you ever have to sue someone later over the copyright, since it means that there's an independent legal record of the date and the original creative material on file. (This doesn't keep various scammers from selling you information on how to register your copyrights and how that will make you rich and cure baldness, of course. It's a common scam in the publishing business.)(Continue reading)
Russ Allbery wrote: > Hector Santos <hsantos <at> santronics.com> writes: > >> This was the first database-driven system that translated all >> elements of an inter-office memorandum/mail, then in paper form, >> along with features of Inbox, Outbox and Folders, to an electronic >> mail format. In 1981, this system was recognized by the Westinghouse >> Science Talent Search receiving an Honors Award. Later, in 1982, the >> US Copyright Office issued him the first copyright of his system >> called “EMAILâ€. [11][12] > > [...] > >> But he went ahead and copyrighted the term "EMAIL" and some how was >> awarded the copyright. > > Note that it says "copyright," not "trademark," so this isn't about the > term. The US Copyright Office doesn't care what you call things. Good point, and at the time, the cheapest non-patented method (which was a high hurdle with just software) was to do a official copyright registration which requires the first and last 100 lines of code of your software to be filed at the copyright office. But it it seems to be a confusion that the registered term "EMAIL" which erroneously implies an all encompassing "electronic mail" which clearly he has no rights too. > Presumably he registered a copyright on the source code of his system,(Continue reading)
On 2/18/12 7:51 PM, Dave CROCKER wrote: > For reference, I just sent this message... Apparently this is not the first time this guy has made up stuff and told the press. This surfaced in Time magazine last year as well: http://techland.time.com/2011/11/15/the-man-who-invented-email/ It appears he is just a self aggrandizing liar. You might also want to send to ombudsman <at> washpost.com or call 202.334.7582. http://www.washingtonpost.com/patrick-b-pexton/2011/02/24/ABkLhYN_page.html Incredibly poor fact checking and editing. pr -- -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
+1, that is what is so surprising. Seems to me this guy, clearly was intelligent (a Westinghouse Science Award participant is not something to sneer at) and was smart enough to exploit the system. Registering the copyright of this first and last 100 code lines under the term "EMAIL" well, I have to give him credit for some brilliance if the USPTO was too incompetent to question it. I was very privy to many IP related issues of software at Westinghouse with many of the early conflicts and many early court precedence of what instituted software IP issues. Just consider that when I send an article to PC MAG to get that $50 illustrating how to do a TREE DIAGRAM of your directory, I was quickly called to the Pittsburgh HQ chief counsel and told, "You can't to that." So consider that this KID, even if he should be recognized as the inventor of something, in that ERA, he would not be owner of the IP - but rather the company that he did it for. This is strongly based on court precedence which in summary says, if a company is paying 80% or more of your compensation, they are the owner of any invention of your work. This was very important for the era dealing with Consultants. If the consultant "LIFE" was dependent on the company he was doing work for, the company own ALL the work. He had to prove that the work compensation was not a life dependency. He was a KID, clearly he was not funding any of his work on his own. He used some centralized system and simply wrote a nice UI. So push comes to solve, if there are any claims of ownership would be the company he did the work for.(Continue reading)
On 2/18/2012 9:22 PM, Pete Resnick wrote: > It appears he is just a self aggrandizing liar. I missed the Time article. I thought that perhaps he was just clueless, but the Time article makes clear that he knows he's not telling the truth. Here's one paragraph of the note I sent to the Post's Ombudsman: > "Then later, I think it was ’81 or ’82, the RFC protocol was changed to add > the “from:”, the “cc:”—those things." > > His statement displays very specialized knowledge, but the claimed facts are > wrong. (RFCs are technical documents, including many Internet standards.) To > point away from the proper "RFC" documents that would make his error clear, > he points to the wrong one. (POP is a secondary transfer protocol. The one > that is interesting in the 1982 timeframe was one I wrote -- RFC 822 -- but > it was merely a revision of one I co-authored in 1977 and THAT was merely > codifying practice going back to the early 70s.) -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
On Feb 19, 2012, at 6:46 AM, Dave CROCKER wrote: > I thought that perhaps he was just clueless, but the Time article makes clear > that he knows he's not telling the truth. This just shows that email has been subject to trivial spoofing attacks much longer than we have acknowledged.
For reference, I just sent this message:
Clarification: A number of readers have accurately pointed out that electronic messaging predates V. A. Shiva Ayyadurai's work in 1978. However, Ayyadurai holds the copyright to the computer program called"email," establishing him as the creator of the "computer program for [an] electronic mail system" with that name, according to the U.S. Copyright Office.
The Smithsonian has acquired the tapes, documentation, copyrights, and over 50,000 lines of code that chronicle the invention of e-mail. The lines of code that produced the first "bcc," "cc," "to" and "from" fields were the brainchild of then-14-year0old inventor V.A. Shiva Ayyadurai.
Re: V.A. Shiva Ayyadurai: Inventor of e-mail honored by SmThe Smithsonian has acquired the tapes, documentation, copyrights, and over 50,000 lines of code that chronicle the invention of e-mail. The lines of code that produced the first "bcc," "cc," "to" and "from" fields were the brainchild of then-14-year0old inventor V.A. Shiva Ayyadurai.
Which seems to miss several points (such as the difference between a copyright and a trademark or patent, the difference between email in general and one specific program called EMAIL, and when to/cc/bcc/from came into use).
> (Not to mention that bcc "fields" should not exist anyway - that's the > whole point) Strongy disagree. The problem with implementations that cheat and implement Bcc: by generating a single message copy with the Bcc: addresses only appearing in the envelope is that those recipients do not get any sort of indication that that were Bcc:'ed. If they don't realize that and do a reply-all, the cat's out of the bad and the sender may be in big trouble. And since users are careless, it really makes a lot of sense for MUAs to check and see if they are doing a reply-all to a message that was Bcc:'ed to them. That's only possible if a Bcc: field is present in their copy of the message. In short, this is an implementation quality issue. The MUA I'm using to enter this messages handles all of this correctly. Ned
On 28/02/2012 16:21, Ned Freed wrote: >> (Not to mention that bcc "fields" should not exist anyway - that's the >> whole point) > Strongy disagree. The problem with implementations that cheat and implement > Bcc: by generating a single message copy with the Bcc: addresses only > appearing in the envelope is that those recipients do not get any sort > of indication that that were Bcc:'ed. If they don't realize that and > do a reply-all, the cat's out of the bad and the sender may be in big > trouble. > > And since users are careless, it really makes a lot of sense for MUAs > to check and see if they are doing a reply-all to a message that was Bcc:'ed > to them. That's only possible if a Bcc: field is present in their copy > of the message. > > In short, this is an implementation quality issue. The MUA I'm using to > enter this messages handles all of this correctly. > OK, I was wrong - but I've never seen a BCC handled in that way before... I've sometimes received messages with a 'BCC' field containing addresses who were NOT me (ie I shouldn't have known they existed), and most MUAs I've seen (in fact, all those I've investigated fully) just list those recipients in the envelope for a single copy of the message. So, I've never seen a BCC field in a message header, used 'correctly'.
On 2/28/2012 9:11 AM, Paul Smith wrote: >> > OK, I was wrong - but I've never seen a BCC handled in that way before... I've > sometimes received messages with a 'BCC' field containing addresses who were NOT > me (ie I shouldn't have known they existed), and most MUAs I've seen (in fact, > all those I've investigated fully) just list those recipients in the envelope > for a single copy of the message. So, I've never seen a BCC field in a message > header, used 'correctly'. We have never really standardized BCC as an end-to-end construct, at the MUA-MUA level. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
I actually started writing such a doc about a year ago, but never
finished it.
Is it worth dusting off?
Tony Hansen
On 2/28/2012 12:24 PM, Dave Crocker wrote:
>
>
>
> On 2/28/2012 9:11 AM, Paul Smith wrote:
>>>
>> OK, I was wrong - but I've never seen a BCC handled in that way
>> before... I've
>> sometimes received messages with a 'BCC' field containing addresses
>> who were NOT
>> me (ie I shouldn't have known they existed), and most MUAs I've seen
>> (in fact,
>> all those I've investigated fully) just list those recipients in the
>> envelope
>> for a single copy of the message. So, I've never seen a BCC field in
>> a message
>> header, used 'correctly'.
>
> We have never really standardized BCC as an end-to-end construct, at
> the MUA-MUA level.
>
> d/
At 13:17 -0500 on 02/28/2012, Tony Hansen wrote about Re: "proper" handling of BCC: >I actually started writing such a doc about a year ago, but never finished it. > >Is it worth dusting off? > > Tony Hansen > >On 2/28/2012 12:24 PM, Dave Crocker wrote: >> >>On 2/28/2012 9:11 AM, Paul Smith wrote: >>>> >>>OK, I was wrong - but I've never seen a BCC handled in that way >>>before... I've sometimes received messages with a 'BCC' field >>>containing addresses who were NOT me (ie I shouldn't have known >>>they existed), and most MUAs I've seen (in fact, all those I've >>>investigated fully) just list those recipients in the envelope for >>>a single copy of the message. So, I've never seen a BCC field in a >>>message header, used 'correctly'. >> >>We have never really standardized BCC as an end-to-end construct, >>at the MUA-MUA level. >> >>d/ Ways it can be handled is for the MUA to submit the BCC header to the MSA and have it remove the header while cloning the message to create one master and one copy for each BCC listing only the Address, have the MSA scan the To and CC assuming that any RCPT-TOs not there are BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do the cloning. Not that the first 2 alter the MSA while the last alters both the MSA and MUA. In any case there needs to be some way of indicating the BCC contents. Note that there needs to be a way of triggering the insertion/display of the BCC listing only the recipient in the recipient's copy of the message that WILL NOT get triggered by a normal Mailing List message. Options 1 and 3 above qualify since there is a indication to the MSA to clone the message with a BCC. Option 2 since it triggers via a mismatch between the To/CC contents and that of the RECPT-TO will be the problem since there would be no difference to the MSA between a BCC and a Mailing List generated message. Note that I am just winging it and may be missing something and I am just doing some design spec thoughts above.
> Ways it can be handled is for the MUA to submit the BCC header to the > MSA and have it remove the header while cloning the message to create > one master and one copy for each BCC listing only the Address, have > the MSA scan the To and CC assuming that any RCPT-TOs not there are > BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do > the cloning. Not that the first 2 alter the MSA while the last alters > both the MSA and MUA. It's certainly possible to have the MSA make the message copy, but we'd need to define an extension for that. No such extension exists AFAIK. Given the lack of such an extension at present, it's up to the MUA to do it. With the understanding that the primary goal is to prevent other recipients from being aware of the bcc, this inevitably leads to not mentioning the bcc recipient in the header the other recipients see. The simple way that most (but by no means all) user agents employ is to send a single copy and only have the bcc recipient in the envelope. This can be improved on by sending (n+1) copies, where n is the number of bcc recipients, one for all the other recipient and one for each bcc with their address in a bcc field. As I said previouly, the choice between the two is primarily an implementation quality issue. The additional bandwidth consumption involved is rarely if ever worth worrying about, even for mobile devices. (And in the mobile case, if the message is large it's likely being forwarded at least in part, and we have other ways to address that.) > In any case there needs to be some way of indicating the BCC > contents. Note that there needs to be a way of triggering the > insertion/display of the BCC listing only the recipient in the > recipient's copy of the message that WILL NOT get triggered by a > normal Mailing List message. Options 1 and 3 above qualify since > there is a indication to the MSA to clone the message with a BCC. > Option 2 since it triggers via a mismatch between the To/CC contents > and that of the RECPT-TO will be the problem since there would be no > difference to the MSA between a BCC and a Mailing List generated > message. There are all sorts of ways of doing it. The real question is whether or not it's worth the bother at this late date, especially since clients cannot count on the extension being present and therefore have to have a fallback option. It won't do to expose bcc recipients when the extension isn't available. Ned
At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper" handling of BCC: > > Ways it can be handled is for the MUA to submit the BCC header to the >> MSA and have it remove the header while cloning the message to create >> one master and one copy for each BCC listing only the Address, have >> the MSA scan the To and CC assuming that any RCPT-TOs not there are >> BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do >> the cloning. Not that the first 2 alter the MSA while the last alters >> both the MSA and MUA. > >It's certainly possible to have the MSA make the message copy, but we'd >need to define an extension for that. No such extension exists AFAIK. No extension needed. So long as the MSA has the code to clone (and inject the BCC into) a submitted message that has more RECPT-TOs than the sum of the addresses in TO and CC (ie: So long as it is not being submitted by a Mailing List and thus had one or more BCC'ed addresses that only the MUA knew of) you just need to make this the default via a parm setting (This functioning is method 2 of 3 above). This is similar to having a MSA or MTA clone multi-addressed messages that would normally be sent a one message with multiple RECPT-TOs going to the same MTA by having a "DO NOT BATCH" parm. Since this is a setting in the MSA/MTA code it just defines a default action not one that only occurs when requested by the submitter. I acknowledge that an extension would be better so it only occurs when the users asks. OTOH: One way to handle this is to define two MSA addresses - One that works as now and one with this default action code. If you want this to occur then just use a sending persona that points at the 2nd MSA address.
> At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper" > handling of BCC: > > > Ways it can be handled is for the MUA to submit the BCC header to the > >> MSA and have it remove the header while cloning the message to create > >> one master and one copy for each BCC listing only the Address, have > >> the MSA scan the To and CC assuming that any RCPT-TOs not there are > >> BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do > >> the cloning. Not that the first 2 alter the MSA while the last alters > >> both the MSA and MUA. > > > >It's certainly possible to have the MSA make the message copy, but we'd > >need to define an extension for that. No such extension exists AFAIK. > No extension needed. Sorry, that incorrect. Without an extension how is an MUA supposed to know that the MSA supports the extension? If an MUA assumes such an extension is present, it actually isn't, and sends a message expecting the MSA to perform some sort of Bcc: processing and selectively remove any Bcc: field(s) that are present, you have just exposed the Bcc: recipient(s) to everyone. And since no MSA out there currently does any of this stuff, this behavior will be the rule, not the exception, until the extension actually deploys, assuming it ever does. No MUA implementor in their right mind would implement this behavior. > So long as the MSA has the code to clone (and > inject the BCC into) a submitted message that has more RECPT-TOs than > the sum of the addresses in TO and CC (ie: So long as it is not being > submitted by a Mailing List and thus had one or more BCC'ed addresses > that only the MUA knew of) you just need to make this the default via > a parm setting (This functioning is method 2 of 3 above). Absent an extension, the MUA has no way of knowing if this parameter even exists in the MSA, let alone how it is set. > This is > similar to having a MSA or MTA clone multi-addressed messages that > would normally be sent a one message with multiple RECPT-TOs going to > the same MTA by having a "DO NOT BATCH" parm. Since this is a setting > in the MSA/MTA code it just defines a default action not one that > only occurs when requested by the submitter. I acknowledge that an > extension would be better so it only occurs when the users asks. That's another reason why you need an extension - you absolutely do need a parameter so that the MSA only does this stuff if the MSA requests it. I also think this is the wrong way for it to work. The problem with this approach is that it forces the MSA to parse and modify headers, and compare the addresses extract from those headers with the various envelope addresses. That's inherently risky. It's much safer to have the MUA send a message without any of these headers in it and to have the MSA simply add the Bcc: field to message copies as needed. This can be done with a BCC parameter on the RCPT TO:. The value of that parameter can be the personal name phase to add to the address. This way the only thing the MSA has to do is decode the parameter value, concatentate some strings and add a header field containing the result. Alternately, the value of the BCC parameter could be the entire Bcc: field value. This would provide support for stuff like group constructs, assuming we want to allow that. (I can argue it either way.) This is even simpler because now all the MSA has to do is decode the parameter and stuff it into a new header field. Of course the bigger part of all this from the MSA's perspective is the messge splitting. But most MSA's always have code for that to handle other cases; this extension can simply leverage that support. > OTOH: One way to handle this is to define two MSA addresses - One > that works as now and one with this default action code. If you want > this to occur then just use a sending persona that points at the 2nd > MSA address. That's far too complex for users to deal with - even now service providers spend far too much time dealing with support calls from users who cannot set up even one persona in their client properly. And besides, no service provider is ever going to deploy multiple MSA just to support such functionality. The benefits don't come even close to outweighing the costs. Remember, the target audience here has to be more than just a bunch of geeks or this doesn't stand a chance of deploying. Ned
At 9:18 AM -0800 2/29/12, <ned+ietf-smtp <at> mrochek.com> wrote: > Absent an extension, the MUA has no way of knowing if this parameter even > exists in the MSA, let alone how it is set. Yes, exactly. > That's another reason why you need an extension - you absolutely do need a > parameter so that the MSA only does this stuff if the MSA requests it. Yes, exactly. > I also think this is the wrong way for it to work. The problem with > this approach is that it forces the MSA to parse and modify headers, > and compare the addresses extract from those headers with the > various envelope addresses. That's inherently risky. Yes, exactly. > It's much safer to have the MUA send a message without any of these > headers in > it and to have the MSA simply add the Bcc: field to message copies as needed. > This can be done with a BCC parameter on the RCPT TO:. The value of that > parameter can be the personal name phase to add to the address. This > way the only thing the MSA has to do is decode the parameter value, > concatentate some strings and add a header field containing the result. > > Alternately, the value of the BCC parameter could be the entire Bcc: field > value. This would provide support for stuff like group constructs, > assuming we > want to allow that. (I can argue it either way.) This is even simpler because > now all the MSA has to do is decode the parameter and stuff it into a new > header field. Two good approaches. > Remember, the target audience here has to be more than just a bunch of > geeks or this doesn't stand a chance of deploying. Right. The most useful thing, in my view, is a BCP on how MUAs should generate messages with BCC recipients, and how MUAs should recognize when a received message is a result of a BCC, and how to handle replies etc. in such cases. I'm intrigued by the behavior mentioned earlier of the originating MUA mucking with the To and Cc header fields when sending a BCC version, as an indication of this and to avoid unthinking reply-to-all actions. I'm not sure I'm a huge fan of the "[To:]" business, but enclosing the contents in parens to form a comment might work. -- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Q: How many surrealists does it take to screw in a light bulb? A: A Fish.
> The most useful thing, in my view, is a BCP on how MUAs should > generate messages with BCC recipients, and how MUAs should recognize > when a received message is a result of a BCC, and how to handle > replies etc. in such cases. I agree that this is more important than having an extension to offload Bcc: processing to the MSA. > I'm intrigued by the behavior mentioned earlier of the originating > MUA mucking with the To and Cc header fields when sending a BCC > version, as an indication of this and to avoid unthinking > reply-to-all actions. I'm not sure I'm a huge fan of the "[To:]" > business, but enclosing the contents in parens to form a comment > might work. I don't think that just having a comment is valid by RFC 5322 rules. That could be an issue. Ned
At 10:58 PM -0800 2/29/12, Ned Freed wrote: >> The most useful thing, in my view, is a BCP on how MUAs should >> generate messages with BCC recipients, and how MUAs should recognize >> when a received message is a result of a BCC, and how to handle >> replies etc. in such cases. > > I agree that this is more important than having an extension to offload > Bcc: processing to the MSA. > >> I'm intrigued by the behavior mentioned earlier of the originating >> MUA mucking with the To and Cc header fields when sending a BCC >> version, as an indication of this and to avoid unthinking >> reply-to-all actions. I'm not sure I'm a huge fan of the "[To:]" >> business, but enclosing the contents in parens to form a comment >> might work. > > I don't think that just having a comment is valid by RFC 5322 rules. That > could be an issue. Good point; list notation might be a better choice. -- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Everything is controlled by a small evil group to which, unfortunately, no one we know belongs.
At 1:44 AM -0500 2/29/12, Robert A. Rosenberg wrote: > At 15:11 -0800 on 02/28/2012, Ned Freed wrote about Re: "proper" > handling of BCC: > >> > Ways it can be handled is for the MUA to submit the BCC header to the >>> MSA and have it remove the header while cloning the message to create >>> one master and one copy for each BCC listing only the Address, have >>> the MSA scan the To and CC assuming that any RCPT-TOs not there are >>> BCCs and do the cloning, OR add a BCC indicator to the RCPT-TO and do >>> the cloning. Not that the first 2 alter the MSA while the last alters >>> both the MSA and MUA. >> >> It's certainly possible to have the MSA make the message copy, but we'd >> need to define an extension for that. No such extension exists AFAIK. > > No extension needed. An extension would be useful but is not needed. It would be useful in the same way that the future-delivery extension is useful: it offloads work to the MSA. The extension isn't needed because the MUA can implement best practice on its own (by sending n+1 copies). > So long as the MSA has the code to clone (and inject the BCC into) > a submitted message that has more RECPT-TOs than the sum of the > addresses in TO and CC (ie: So long as it is not being submitted by > a Mailing List and thus had one or more BCC'ed addresses that only > the MUA knew of) you just need to make this the default via a parm > setting (This functioning is method 2 of 3 above). This is similar > to having a MSA or MTA clone multi-addressed messages that would > normally be sent a one message with multiple RECPT-TOs going to the > same MTA by having a "DO NOT BATCH" parm. Since this is a setting > in the MSA/MTA code it just defines a default action not one that > only occurs when requested by the submitter. Its ugly to tie default MSA action to the To/Cc headers. At a minimum, the MSA needs to match the To/Cc addresses to the envelope addresses, not the count of how many addresses are in each. Still, the MSA shouldn't do things differently by default -- the MUA may be sending multiple copies. Any change in MSA behavior needs to be tied to an extension. > I acknowledge that an extension would be better so it only occurs > when the users asks. OTOH: One way to handle this is to define two > MSA addresses - One that works as now and one with this default > action code. If you want this to occur then just use a sending > persona that points at the 2nd MSA address. Ooh, no, please. One address per combination of behavioral differences? Yikes! -- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Teacher Strikes Idle Kids --Newspaper headline
ned+ietf-smtp <at> mrochek.com <ned+ietf-smtp <at> mrochek.com> wrote: > > It's certainly possible to have the MSA make the message copy, but we'd > need to define an extension for that. No such extension exists AFAIK. http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html Tony. -- -- f.anthony.n.finch <dot <at> dotat.at> http://dotat.at/ Dogger, Fisher, German Bight: West or southwest 4 or 5. Slight or moderate. Fog banks. Moderate or very poor.
> ned+ietf-smtp <at> mrochek.com <ned+ietf-smtp <at> mrochek.com> wrote: > > > > It's certainly possible to have the MSA make the message copy, but we'd > > need to define an extension for that. No such extension exists AFAIK. > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html As you might expect, I have a *lot* of problems with this approach. For one thing, it mandates what I regard to be the suboptimal way to handle BCC by completely deleting the field; as I have previously stated, not having a clear indication that you got the message as a Bcc: risks exposure when someone mistakenly does a reply-all. It also requires parsing headers and extracting addresses from them, something I'd prefer to avoid and which other approaches do not require. The draft doesn't specify how to handle errors resulting from invalid recipient addresses nearly well enough, but this is a correctable problem, not a fundamental issue with the approach. (The batch SMTP specification already covers most of this so I know it's possible to do.) But the biggest problem is the approach to consuming Resent-* fields, in particular its dependency on header ordering as well as requiring the presence of Received: field separators. This is an incredibly fragile way to do it. I'd actually rather have an extension that worked the opposite way: Construct the headers from an appropriately decorated envelope and add them to the message, and if handling error results from RCPT TO is an issue for clients have a means to require that only outright syntax errors be reported as a command result and report all other errors later with a DSN. Ned
Ned Freed <ned.freed <at> mrochek.com> wrote: > > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html > > As you might expect, I have a *lot* of problems with this approach. I should probably say that this isn't a very serious proposal, since it doesn't actually solve any real-world problems, and it prevents the MUA from using SMTP extensions that require RCPT parameters. It's more of a what-if about where the boundaries might be drawn between MUA / MSA / MTA. > It also requires parsing headers and extracting addresses from them, something > I'd prefer to avoid and which other approaches do not require. MSAs should probably be doing this anyway, to avoid propagating malformed messages. > But the biggest problem is the approach to consuming Resent-* fields, in > particular its dependency on header ordering as well as requiring the presence > of Received: field separators. This is an incredibly fragile way to do it. In that part I was essentially trying to be explicit about what is already implied by the existing specifications (822 and 2822) and running code. This logic has to exist to support things like the `sendmail -t` command, and in the MUA so that it can display messages correctly (though it can probably avoid the complexity when sending). Tony. -- -- f.anthony.n.finch <dot <at> dotat.at> http://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Southwest, but cyclonic at first in Cromarty, veering north or northeast, veering east or southeast later, 4 or 5, increasing 6 at times in Forties and Cromarty. Slight, occasionally moderate in Forties and Cromarty. Occasional rain. Moderate or good, occasionally poor.
> > ned+ietf-smtp <at> mrochek.com <ned+ietf-smtp <at> mrochek.com> wrote: > > > > > > It's certainly possible to have the MSA make the message copy, but we'd > > > need to define an extension for that. No such extension exists AFAIK. > > http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rcpthdr.html > As you might expect, I have a *lot* of problems with this approach. For one > thing, it mandates what I regard to be the suboptimal way to handle BCC by > completely deleting the field; as I have previously stated, not having a clear > indication that you got the message as a Bcc: risks exposure when someone > mistakenly does a reply-all. > It also requires parsing headers and extracting addresses from them, something > I'd prefer to avoid and which other approaches do not require. > The draft doesn't specify how to handle errors resulting from invalid > recipient addresses nearly well enough, but this is a correctable problem, > not a fundamental issue with the approach. (The batch SMTP specification > already covers most of this so I know it's possible to do.) > But the biggest problem is the approach to consuming Resent-* fields, in > particular its dependency on header ordering as well as requiring the presence > of Received: field separators. This is an incredibly fragile way to do it. > I'd actually rather have an extension that worked the opposite way: Construct > the headers from an appropriately decorated envelope and add them to the > message, and if handling error results from RCPT TO is an issue for clients > have a means to require that only outright syntax errors be reported as a > command result and report all other errors later with a DSN. I would add to this discussion a possible (new?) need about the BCC handling (that come out in some scenario, see below) that is to forbid at MSA level the use of a BCC. In this case I agree with the Ned approach (based on a SMTP extension) versus the one that currently we are using in the Italian Certified email system, where we are parsing the TO and CC headers and comparing the result with the list of RCPT-TOs (many platforms have been adapted to be compliant with such MSA requirement). We will have a slot at the next IETF meeting (APP area WG) to bring attention on the CEM systems scenario where there could be quite strange (or interesting?) requirements (such as to forbid the BCC) that I think should be addressed and discussed by the IETF community. References: http://datatracker.ietf.org/doc/draft-gennai-appsawg-cem/ http://datatracker.ietf.org/doc/rfc6109/ Francesco > Ned
Francesco Gennai wrote:
>
>> I'd actually rather have an extension that worked the opposite way: Construct
>> the headers from an appropriately decorated envelope and add them to the
>> message, and if handling error results from RCPT TO is an issue for clients
>> have a means to require that only outright syntax errors be reported as a
>> command result and report all other errors later with a DSN.
>
> I would add to this discussion a possible (new?) need about the BCC handling
> (that come out in some scenario, see below) that is to forbid at MSA level
> the use of a BCC.
My Opinion:
After rethinking this, at first I would agree but I don't quite see
how this would fall under SMTP (as an extension) due to the wide agree
of how the integrated systems are done, i.e. the presumption as I
read SMTP would be processing the headers once it is accepted. Maybe
a internal (local vs remote) router will, perhaps even a gateway or a
mail importer who may be already doing final clean up (i.e. stripping
Return-Path or old uucp/slip "From " headers are no longer necessary).
> In this case I agree with the Ned approach (based on a SMTP extension)
> versus the one that currently we are using in the Italian Certified email
> system, where we are parsing the TO and CC headers and comparing the result
> with the list of RCPT-TOs (many platforms have been adapted to be compliant
> with such MSA requirement).
Interesting and curious for the genesis of that logic. The two don't
need to match. The offline MUA used did not do the separation?
It always helped me to view this in three parts (perhaps four, trace
lines) regarding the format or network:
Network Control Headers
Display Headers
Context
The network control lines basically that deals with ensuring routing
and replies are possible and correct. Display headers are basically
those no longer important for networking.
In our system, the operator decides how he mail is stored in preserved
mode (RFC5322) or converted to the backend default format, which
includes extraction and storage of attachments prepare it for online
viewing, keeping only the network control lines as hidden meta fields.
(Some user are allowed only online access, some have POP access, and
for them he MAY preserves the RFC5322 storage to make sure there is no
degrading of end to end originality. For some users, he operator may
have a policy to protect the less savy user so he may get just plain
text).
Perhaps what I can see here is agree that am existing BCC header
should be forbidden from the standpoint that who ever massages the
mail either for final delivery or for further routing that it simply
strips the BCC from the headers on the presumption there is already a
separate independent message/transport to the target BCC address done.
There is also the consideration regarding displaying. The MUA may
want to inform the BCC recipient to the privacy nature of the message:
NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN
THE
TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE.
As you probably see, this will help avoid a possible mistake the BCC
recipient is unaware of the BCC nature the the message and he jump
into the conversion to the surprise of others the "boss" was listening.
IMV, only the offline MUA can do this when it separates BCC
distribution from the rest for its SMTP client. The RFC-based offlne
MUST always be aware of this responsibility because there is no
current expectation the SMTP/MSA will. If that isn't already written
somewhere, perhaps it needs to be done.
But I do agree the backend should do a "Double Check" to remove the
BCC from public set of messages. Not sure if that is a SMTP issue.
Maybe RFC 4409?
--
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector <at> jabber.isdg.net
At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re: "proper" handling of BCC: >There is also the consideration regarding displaying. The MUA may >want to inform the BCC recipient to the privacy nature of the >message: > > NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN THE > TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE. Query - For issuing this message, how do you determine that the recipient is getting a copy of the message without being listed in a To or Cc header due to being BCC'ed or being subscribed to a mailing list (or do you treat a mailing list received copy as a BCC'ed copy)? I ignore the case of being listed in a To or Cc as a suppressed address (ie: Group-Name:add1, add2, etc. ;) since the existence of a group-name:; comment implies a hidden BCC list.
--On Sunday, April 15, 2012 16:14 -0400 "Robert A. Rosenberg"
<hal9001 <at> panix.com> wrote:
>
> At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re:
> "proper" handling of BCC:
>
>> There is also the consideration regarding displaying. The
>> MUA may want to inform the BCC recipient to the privacy
>> nature of the message:
>>
>> NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS
>> LISTED IN THE TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR
>> RECEPTION OF THIS MESSAGE.
>
> Query - For issuing this message, how do you determine that
> the recipient is getting a copy of the message without being
> listed in a To or Cc header due to being BCC'ed or being
> subscribed to a mailing list (or do you treat a mailing list
> received copy as a BCC'ed copy)?
>
> I ignore the case of being listed in a To or Cc as a
> suppressed address (ie: Group-Name:add1, add2, etc. ;) since
> the existence of a group-name:; comment implies a hidden BCC
> list.
If I correctly understand the question, I simply put a "bcc"
field in the message as I submit it to the MUA. It removes that
field. constructs the "blind copy" warning text, and constructs
the envelope(s) appropriately (typically one envelope for the
set of To and Cc recipients and one for each Bcc one) for
handoff to the Submission server. Of course, if one had a
submission server that was smart about these things, the MUA
could hand the message, including the Bcc field, to it and let
it sort out envelopes (which it needs to do anyway) and the
warning message.
In case it wasn't clear from Hector's message, this is not
theory. There are several MUAs, including the one I'm using,
that are able to behave exactly as outlined above.
john
If I correctly understand the question, I simply put a "bcc"
field in the message as I submit it to the MUA. It removes that
field. constructs the "blind copy" warning text, and constructs
the envelope(s) appropriately (typically one envelope for the
set of To and Cc recipients and one for each Bcc one) for
handoff to the Submission server. Of course, if one had a
submission server that was smart about these things, the MUA
could hand the message, including the Bcc field, to it and let
it sort out envelopes (which it needs to do anyway) and the
warning message.
--On Sunday, April 15, 2012 16:05 -0700 Steve Atkins
<steve <at> blighty.com> wrote:
>>>
>>
>> If I correctly understand the question, I simply put a "bcc"
>> field in the message as I submit it to the MUA. It removes
>> that field. constructs the "blind copy" warning text, and
>> constructs the envelope(s) appropriately (typically one
>> envelope for the set of To and Cc recipients and one for each
>> Bcc one) for handoff to the Submission server. Of course,
>> if one had a submission server that was smart about these
>> things, the MUA could hand the message, including the Bcc
>> field, to it and let it sort out envelopes (which it needs to
>> do anyway) and the warning message.
>
> A submission server will have some difficulty adding a
> warning message that'll be visible to a typical recipient
> (multipart/mime, non plain-text, DKIM, PGP, S/MIME…).
Having the MUA add such comments assumes that there is a
convenient body part (probably the first one) that is text/plain
or, worst case, that it has to add the text to both/all pieces
of a multipart/alternative. Such plain-text or nearly
plain-text messages remain the typical case today. In the
absence of signatures or other integrity checks added by the MUA
or earlier, a submission server should have no more trouble
doing that than the MUA itself (although I confess to not having
a submission server do that for years). DKIM is even easier
since, at least in the cases I've seen the typical behavior is
for that signature to be added by the Submission server.
Now, clearly, if one had any of a large family of less-typical
messages (complex multipart structures; first (or maybe only)
body part not text/plain, text/html, or
text/something-else-fairly-simple-and-well-known, signatures
applied to the body part before the message can be added, etc.,
then the trick of adding a warning doesn't work. MUAs and
submission servers typically cope with those situations the way
alert MUAs that don't try to add a warning do, which is, as you
suggest below, to delete the Bcc header field (or its contents
-- that used to be extensively debated) and then construct and
appropriate envelope.
> Handling Bcc by copying the Bcc header to the envelope,
> then deleting the header is fine, though I wouldn't trust any
> MUA that relied on that functionality.
Yes. The difficulty with this --and what caused the "add the
comment/warning" behavior-- is that the recipients cannot easily
tell "received a blind copy" from "received from a mailing
list". If they then reply, copying the explicit distribution,
the result is a privacy compromise relative to the intentions of
the original sender. If the original sender were really worried
about that, the only safe action I know of is to avoid use of
bcc entirely, instead, for example, forwarding a copy of the
message with the explicit recipient listed to the bcc recipient
only. That message could well be structured with the warning as
a first body part followed by the original as message/rfc822 or
message/global. But it is a little hard to automate.
john
John C Klensin wrote: > >> Handling Bcc by copying the Bcc header to the envelope, >> then deleting the header is fine, though I wouldn't trust any >> MUA that relied on that functionality. > > Yes. The difficulty with this --and what caused the "add the > comment/warning" behavior-- is that the recipients cannot easily > tell "received a blind copy" from "received from a mailing > list". If they then reply, copying the explicit distribution, > the result is a privacy compromise relative to the intentions of > the original sender. If the original sender were really worried > about that, the only safe action I know of is to avoid use of > bcc entirely, instead, for example, forwarding a copy of the > message with the explicit recipient listed to the bcc recipient > only. That message could well be structured with the warning as > a first body part followed by the original as message/rfc822 or > message/global. But it is a little hard to automate. When I don't use our MUA which have the special BCC feature to split the streams and add the special top posted notification, and instead I'm using an MUA like Thunderbird, whenever I need to do this, I will either CC or BCC myself, and with my copy, just forward it the the special private address with a top posted FYI "Keeping you in the loop" note. I am also very careful of not BCCing someone that is know to reply/response and will just BCC a person will never get involve - they just wants to be keep in the loop. I do this almost daily with technical support communications to keep the sales team in the loop of whats going on. So IMV, we should also take into the account that people who generally need to use a BCC, most likely don't do so blindly themselves. The way I look at it, due to what is today, the MUA is responsible and if the MUA author is going to offer a BCC feature, it needs to do so responsibly knowing full well how the backend works which never came with an backend expectation to do BCC processing, stream splitting, privacy cleanup. If it exist, its a proprietary MUA/MSA concept. IMV, if we are looking to move this MUA duty to the backend with a standard methodology, then we need a IETF I-D/RFC proposal and SMTP extension that defines rules for the router to do this BCC splitting. But I wonder if its worth it because on the original mail creation side with the OFFLINE MUA, they are all already doing it. The MSA router does not need to currently worry about it. So it seems the issue is only for the receiver MUA to consider and off hand only because of the modern expectation of MIME based mail. If the BCC is passthru, then it should be more aware from the display rendering standpoint the special meaning it has to convey to the blind recipient. -- -- Sincerely Hector Santos http://www.santronics.com jabber: hector <at> jabber.isdg.net
> Of course, if one had a submission server that was smart about these > things, the MUA could hand the message, including the Bcc field, to > it and let it sort out envelopes (which it needs to do anyway) and > the warning message. That strikes me as a really unfortunate idea. Submission servers know all about envelopes and message headers. In most cases, they don't know anything about the body of the message beyond what they can intuit from the MIME headers. If your submission server adds text to a body saying something like "you are a blind copy recipient", in what language is that message expressed? If you'd rather it use another language, how can you tell it to do so? This all belongs in the MUA. While there is plenty of historical precedent for submission servers fixing up headers, adding missing ones that can be constructed mechanically, and creating an envelope based on recipient addresses in the headers, I can't think of fixups they do to message bodies other than perhaps wrapping the whole unmodified body in a crypto signature. I'd rather move toward MUAs creating correct messages, and having submission server fixups as a backup. R's, John
On Tue 17/Apr/2012 16:26:49 +0200 John Levine wrote: > > I'd rather move toward MUAs creating correct messages, and having > submission server fixups as a backup. +1, and if a MUA is so smart as to add such functionality, why does it have to hijack a "Bcc" field which is already used for different purposes?
On 4/16/2012 8:38 AM, John Levine wrote: > >> Of course, if one had a submission server that was smart about these >> things, the MUA could hand the message, including the Bcc field, to it and >> let it sort out envelopes (which it needs to do anyway) and the warning >> message. > > That strikes me as a really unfortunate idea. Submission servers know all > about envelopes and message headers. In most cases, they don't know anything > about the body of the message beyond what they can intuit from the MIME > headers. As noted, this is a scenario that has been supported by some posting MSAs, like sendmail and mmdf, going back a very long time. My own view is that this is, nonetheless, an MUA function. That is, for this feature, sendmail and mmdf were/are acting as MUAs to prepare the message for formal posting, and then they turn into MSAs. Note that the function is really the same as most/all MUA's do, when processing a message themselves for regular SMTP/Submission postings: parse a number of header-fields as sources for addresses to be used in the RCPT-TO list. This is a nice demonstration of the difference between network architecture and software architecture, in which different software implementation choices can lead to placement of network architecture functions in different modules. For the scenario being discussed, the "MSA" is actually part MSA and part MUA. > If your submission server adds text to a body saying something like "you are > a blind copy recipient", in what language is that message expressed? That's a nice example of the basic reason to keep network architectures as far from user interface design as we can. (chorus: ) Presentation and interaction design are specialties that are not well represented in protocol development groups... d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
>> That strikes me as a really unfortunate idea. Submission servers know all >> about envelopes and message headers. In most cases, they don't know anything >> about the body of the message beyond what they can intuit from the MIME >> headers. > >As noted, this is a scenario that has been supported by some posting MSAs, like >sendmail and mmdf, going back a very long time. My own view is that this is, >nonetheless, an MUA function. That is, for this feature, sendmail and mmdf >were/are acting as MUAs to prepare the message for formal posting, and then they >turn into MSAs. In case it wasn't clear, the MSA making the envelope from the headers is reasonable, since you can write down a fairly simple rule for how it works. The MUA is still a better place to do it since it's more likely to know what the user wanted, and the simple rule becomes much more complex in corner cases like multiple From: addresses and Resent-x headers. Having the MSA add comments into the body is much less so. R's, John
On 4/17/2012 8:35 AM, John Levine wrote: > In case it wasn't clear, the MSA making the envelope from the headers > is reasonable, since you can write down a fairly simple rule for how > it works. I think we have a nomenclature challenge here. It is natural to refer to this as something the "MSA" is doing. But it isn't an MSA function. It's an MUA function, as part of preparation for formal posting into the MHS. The best I can suggest is something more implementation oriented, such as "server". The meta-model this implies is to have "agent" mean networking architecture, per the email architecture spec. And "client" or "server" as references to physical implementations which might have interaction boundaries that are different from the networking architecture boundaries. If we don't develop a discipline in how we talk about this kind of distinction, we will never develop a community understanding of the difference. The term that was developed a long time ago, for having a server do 'user' functions is "split UA". d/ -- Dave Crocker bbiw.net -- -- d/ -- Dave Crocker bbiw.net
Dave Crocker wrote: > > On 4/17/2012 8:35 AM, John Levine wrote: >> In case it wasn't clear, the MSA making the envelope from the headers >> is reasonable, since you can write down a fairly simple rule for how >> it works. > > I think we have a nomenclature challenge here. It is natural to refer > to this as something the "MSA" is doing. But it isn't an MSA function. > It's an MUA function, as part of preparation for formal posting into the > MHS. The best I can suggest is something more implementation oriented, > such as "server". > > The meta-model this implies is to have "agent" mean networking > architecture, per the email architecture spec. And "client" or "server" > as references to physical implementations which might have interaction > boundaries that are different from the networking architecture boundaries. > > If we don't develop a discipline in how we talk about this kind of > distinction, we will never develop a community understanding of the > difference. > > The term that was developed a long time ago, for having a server do > 'user' functions is "split UA". +1. Dave, I always felt that the idea of Online vs Offline MUA was often not considered when in came to an discussed expected behavior which mostly applied to RFC-based offline MUAs but didn't to Online MUAs. For example, with the many discussions regarding what an offline MUA may display in RFC5322 headers, it was not an issue with the Online MUA where the UI display rendering is 100% controlled by the backend. We may even defined with a new acronym MAS - "Mail Access Server." The real distinction is based on how much intelligence the MUA had with the capability and advancement of how much can be offloaded to the user's device. And FYI, the concept of offloading data was patented by IBM long ago, long expired of course, which allowed for rapid growth of offline/offloading software to be developed. -- -- Sincerely Hector Santos http://www.santronics.com jabber: hector <at> jabber.isdg.net
--On Tuesday, April 17, 2012 15:35 -0400 Hector Santos
<hsantos <at> santronics.com> wrote:
> For example, with the many discussions regarding what an
> offline MUA may display in RFC5322 headers, it was not an
> issue with the Online MUA where the UI display rendering is
> 100% controlled by the backend. We may even defined with a new
> acronym MAS - "Mail Access Server."
>
> The real distinction is based on how much intelligence the MUA
> had with the capability and advancement of how much can be
> offloaded to the user's device. And FYI, the concept of
> offloading data was patented by IBM long ago, long expired of
> course, which allowed for rapid growth of offline/offloading
> software to be developed.
Hector,
I'm not completely certain I agree. In the beginning, MUAs were
entirely on host machines and we communicated with them via
terminals or equivalent. IIR, tools like the original U**x mail
command, its predecessors, and better tools like MH were
developed in/for that kind of environment. Certainly they were
online, but the concept was a little different from the way we
use the term today. You, Dave, or others might have different
data, but I first remember the term "split-UA" used for
arrangements in which the work of getting mail to the user was
divided between something happening on the mail store machine
(usually the delivery MTA, but not always) using protocols like
POP, PCMAIL, IMAP, and some arrangements that have passed into
obscurity. Each of those three originally supported a different
model: "download everything to the client side of the split and
work offline" for POP, "synchronize to the client side of the
split but mostly work offline" for PCMAIL, and "client is online
to the server, often in what we call kiosk mode today" for IMAP.
The issue is less about "how much can be offloaded" than about
styles of working with different situations involving different
mixes of advantages and disadvantages. (IMAP4 moved beyond that
early split to support all three models -- how well differs by
implementation, but the "split-UA" part of the concept remains.
On the submission side, we had both MTAs that expected to get at
least nearly-adequate SMTP and, among other options,
intermediate MUAs and MTAs that effectively accepted an 822-ish
message body along with an envelope via some API as well as MTAs
that accepted a non-envelope 822-ish message body and tried to
construct an envelope from it. The latter, IMO, led to lots of
woes, but it was certainly common. I remember hearing and
talking about those (both originating MUAs/MTAs and gateways)
more in "fix the message before it is injected into the Internet
environment" than in "split-UA" terms although the latter is
certainly a reasonable model for the situation. Remember that
most "smart" mailing list exploders perform some MUA functions
too.
>From that perspective, our explicitly describing submission
servers and giving them equally explicit permission to do
MUA-ish things simply symmetrically recreates the split-UA
situation we have on the receiving side with POP and IMAP: some
MUA-ish work gets done on the client machine, some gets done on
the server machine, and the server machine also has interfaces
to the network and/or mail store. In both sets of cases, if the
server side of the UA function starts doing things that the
client side doesn't anticipate, seriously bad things can happen.
john
FWIW and in case the clarification is needed, I am in complete agreement with Dave's analysis and comments. Interestingly, before we formalized the role of MSAs with RFC 2476, I was using almost exactly the same terminology and distinction about MTAs performing MUA functions that appear in Dave's note (I believe he has been using it at least equally long). Since we started talking about MSAs, I've gotten a bit more sloppy because both the SMTP and MSA docs assume that they can perform MUA functions. This discussion probably illustrates that original distinction is worth retaining. john --On Tuesday, April 17, 2012 07:40 -0700 Dave Crocker <dhc <at> dcrocker.net> wrote: > > > On 4/16/2012 8:38 AM, John Levine wrote: >> >>> Of course, if one had a submission server that was smart >>> about these things, the MUA could hand the message, >>> including the Bcc field, to it and let it sort out envelopes >>> (which it needs to do anyway) and the warning message. >> >> That strikes me as a really unfortunate idea. Submission >> servers know all about envelopes and message headers. In >> most cases, they don't know anything about the body of the >> message beyond what they can intuit from the MIME headers. > > As noted, this is a scenario that has been supported by some > posting MSAs, like > sendmail and mmdf, going back a very long time. My own view > is that this is, > nonetheless, an MUA function. That is, for this feature, > sendmail and mmdf > were/are acting as MUAs to prepare the message for formal > posting, and then they > turn into MSAs. > > Note that the function is really the same as most/all MUA's > do, when processing > a message themselves for regular SMTP/Submission postings: > parse a number of > header-fields as sources for addresses to be used in the > RCPT-TO list. > > This is a nice demonstration of the difference between network > architecture and > software architecture, in which different software > implementation choices can > lead to placement of network architecture functions in > different modules. > > For the scenario being discussed, the "MSA" is actually part > MSA and part MUA. > > >> If your submission server adds text to a body saying >> something like "you are a blind copy recipient", in what >> language is that message expressed? > > That's a nice example of the basic reason to keep network > architectures as far > from user interface design as we can. (chorus: ) Presentation > and interaction > design are specialties that are not well represented in > protocol development > groups... > > > d/
Dave Crocker wrote: > For the scenario being discussed, the "MSA" is actually part MSA and > part MUA. Isn't the MSA also part MDA which the key different is that later does not require authentication? But I guess I also read some people believe the MUA can also be a MDA. But for me, an MUA is already on online agent or offline RFC based agent. To me, the MSA presumed an authenticated transaction and one that also authorized the server to do more with this USER's submitted data than it can do with a MDA receiving unsolicited passthru mail. My view. -- -- Sincerely Hector Santos http://www.santronics.com jabber: hector <at> jabber.isdg.net
Robert A. Rosenberg wrote:
>
> At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re: "proper"
> handling of BCC:
>
>> There is also the consideration regarding displaying. The MUA may
>> want to inform the BCC recipient to the privacy nature of the message:
>>
>> NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN THE
>> TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE.
>
> Query - For issuing this message, how do you determine that the
> recipient is getting a copy of the message without being listed in a To
> or Cc header due to being BCC'ed or being subscribed to a mailing list
> (or do you treat a mailing list received copy as a BCC'ed copy)?
Hi Robert,
As John K. alluded to, this would be done at the source - author's MUA
where the message is first created. Perhaps the primary point is that
the sender's distribution list and receiver's reception list is not
based on the RFC5322 headers but rather the SMTP envelope RCPT TO
addresses and these do not need to match what the RFC5322 headers say.
Is the question about how the MUA will do this based on it using
RFC5322 as UI meta when the user is creating the message?
If so, the MUA does not to use RFC5322 for storage data, it could, but
when the SEND button it clicked, it needs to begin to split the blind
recipient streams from the others because its not expected for the MSA
router to do this. It might be possible if we had an SMTP BCC service
extension.
Just winging it, using the following MUA headers:
From:<author-address>
To: <user1-address>
To: <user2-address>
Bcc: <user3-address>
The MUA session might be:
C: EHLO client.domain
S: 250-server.example, Hello client.domain
S: 250-.......
S: 250-BCC
S: 250 HELP
C: MAIL FROM:<author-address>
S: 250 ok
C: RCPT TO:<user1-address>
S: 250 ok
C: RCPT TO:<user2-address>
S: 250 ok
C: RCPT TO:<user3-address> BLIND=NOTE|BCC
S: 250 ok
....
and this basically tells the MSA router to SPLIT this distribution of
the payload into different MTA mail queues.
The BLIND[=options]
NOTE - MSA router MAY add the "This is blind copy" body text
BCC - MSA router MAY add the 5322.BCC for the blind recipient only.
none - MSA router decides.
- For MIME mail, assume BLIND=BCC
- For text/plain simple mail, assume BLIND=NOTE
So if the question is about rendering, displaying, then the BLIND=NOTE
or BLIND=BCC can help. Having 5322.BCC in the blind copy can allow for
supported advanced MUAs to highlight this special private blind copy
to the blind recipient. This may help alleviate concerns that top
posted warning text would interfere with the more complex MIME messages.
--
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector <at> jabber.isdg.net
At 16:14 -0400 on 04/15/2012, Robert A. Rosenberg wrote about Re: "proper" handling of BCC: >At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re: "proper" >handling of BCC: > >>There is also the consideration regarding displaying. The MUA may >>want to inform the BCC recipient to the privacy nature of the >>message: >> >> NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN THE >> TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE. > >Query - For issuing this message, how do you determine that the >recipient is getting a copy of the message without being listed in a >To or Cc header due to being BCC'ed or being subscribed to a mailing >list (or do you treat a mailing list received copy as a BCC'ed copy)? > >I ignore the case of being listed in a To or Cc as a suppressed >address (ie: Group-Name:add1, add2, etc. ;) since the existence of a >group-name:; comment implies a hidden BCC list. I asked this question over a month ago and there were a number of replies which branched off from my query but did not answer it (due to misunderstanding my question or shoving the support onto the MSA). Thus I will ask it and try to be more explicit in what I want to understand. The situation is that I have just received a normal message with NO explicit indication that I was BCC'ed in the message body or via a header. IOW: I am not listed in the supplied TO or CC header (although I may be listed in a Received For clause if I am the only recipient in my domain). This BCC delivery would be due to being listed in the BCC header by the sender, being listed in a Group-name:address-1, address-2,etc.; address in the To or Cc header (shown in the received message as Group-name:;), or being sent the message by a mailing list. As I state, I will ignore the mailing list delivery as non-BCC (assuming that there is a List-ID header to flag this) and ask ONLY about the other two which are true cases of being BCC'ed. With that out of the way, I am reading a received message and want my MUA to warn me that replying will expose to whoever I reply to via Reply-To-All (ie: The To,Cc,From/Sender addresses) that I received a copy (even though not listed as To or Cc). Note that this is a warning that the MUA sends me when I try to queue/send the reply. My question is how would it decide that I should be warned in lieu of the message actually getting queued/sent. I will assume a sanity-check that the warning should NOT be raised if the message being replied to has a List-ID header (ie: It is OK to reply to mailing list messages since if you only want to lurk/monitor you should be cognizant of the fact the message came from a mailing list and it is your fault for responding if you do not want to indicate you are subscribed). Thus we are talking about only true BCC'ed messages. The only way I can see for the MUA to detect this is to look for me in the To and Cc headers and not finding me there (and not finding a List-ID) to issue the warning.
--On Tuesday, May 22, 2012 23:45 -0400 "Robert A. Rosenberg"
<hal9001 <at> panix.com> wrote:
>...
> The situation is that I have just received a normal message
> with NO explicit indication that I was BCC'ed in the message
> body or via a header. IOW: I am not listed in the supplied TO
> or CC header (although I may be listed in a Received For
> clause if I am the only recipient in my domain).
>
> This BCC delivery would be due to being listed in the BCC
> header by the sender, being listed in a Group-name:address-1,
> address-2,etc.; address in the To or Cc header (shown in the
> received message as Group-name:;), or being sent the message
> by a mailing list. As I state, I will ignore the mailing list
> delivery as non-BCC (assuming that there is a List-ID header
> to flag this) and ask ONLY about the other two which are true
> cases of being BCC'ed.
There is another case, which is that of a non-enumerated group,
i.e., something like "Group-name:;" rather than
"Groupd-name:address...;". This could lead to a long
philosophical discussion, but I'd argue that your receiving a
message in which your Group syntax is used but your address does
not appear explicitly is a lot more like a mailing list
situation than list a Bcc, except that "List-*" headers would
not be generated unless there is a mailing list involved too.
If you have headers of, e.g.,
To: joe-blow <at> example.com, Somegroup:;
cc: some-list <at> example.net
then presence of a set of List-& header fields would normally
indicate that you got the message from the list (warning, there
are a few edge cases that aren't hard to construct as well as
list expanders that don't put in List-* header fields) that make
that test less than 100% reliable). Assuming that
joe-blow <at> example.com is not an alias pointing to you, the
absence of List-* headers would indicate either that your are a
member of "Somegroup" or that the message was a bcc to you.
Note also that
To: joe-blow <at> example.com, Somegroup:;
cc: Big-list: some-list <at> example.net;
is also permitted. Some would claim that its semantics are
exactly the same as the example above, others might try to
attribute meaning to the explicit use of group syntax. I have
no idea whether systems that generate "List-* header fields
would consider them different or not.
> With that out of the way, I am reading a received message and
> want my MUA to warn me that replying will expose to whoever I
> reply to via Reply-To-All (ie: The To,Cc,From/Sender
> addresses) that I received a copy (even though not listed as
> To or Cc). Note that this is a warning that the MUA sends me
> when I try to queue/send the reply.
In the examples above, you need worry only about joe-blow and
the mailing list, since the group cannot be replied to and will
be dropped, often without warning, by most MUAs (the others will
get confused). I also note that, unless the membership of the
mailing is available to all list members or perhaps the public,
the cases of "replying to a Bcc" and "replying to a message
delivered via the list" are not as different as you might
assume. In both cases, you are disclosing the fact that you
have received the message to people who might not have any other
way to know that. You sort of cover this below, but I want to
avoid any possible misunderstanding.
> My question is how would it decide that I should be warned in
> lieu of the message actually getting queued/sent. I will
> assume a sanity-check that the warning should NOT be raised if
> the message being replied to has a List-ID header (ie: It is
> OK to reply to mailing list messages since if you only want to
> lurk/monitor you should be cognizant of the fact the message
> came from a mailing list and it is your fault for responding
> if you do not want to indicate you are subscribed). Thus we
> are talking about only true BCC'ed messages. The only way I
> can see for the MUA to detect this is to look for me in the To
> and Cc headers and not finding me there (and not finding a
> List-ID) to issue the warning.
If there is no empty group syntax (for which "(undisclosed
recipients)" is a popular surrogate) and you trust the "List-*"
heuristic, then yes, that works and is the closest approximation
you can get. In practice, there is no way to know with complete
certainty. If an empty group --which, again, is not a bcc--
although you might consider it equivalent for your purposes-- is
present, then the distinction you are trying to make is pretty
hopeless.
Moving back to some of the answers that you don't believe are
relevant to your question, this situation is precisely why
senders who want to warn about inadvertent disclosure of bcc
recipients either insert explicit warnings into the first text/
body part or use a "forward"-like mechanism to send the original
message to the bcc recipient in encapsulated form (maybe also
with a warning).
john
Robert,
When I added this special note to our MUA (PX - Platinum Xpress) it
was due because there was no current way to get this information to
the BCC target. Since the PX MUA was specifically written for sysops,
this activity would be higher than normal and it was important any BCC
would get a top-posting note. MIME was not an issue at the time. It
was all pure text.
Even if there was a IETF proposal, it would be for the new stuff, and
you could not take a chance any IETF protocol level support not be
available, so the PX MUA had to do it.
I don't see how it be done without the sending, mail creation MUA have
some knowledge about it or knowledge the backend will do it. That is
why in my last post, I winged it with using a SMTP extension proposal
using a BLIND keyword.
The BLIND[=options]
NOTE - MSA router MAY add the "This is blind copy" body text
BCC - MSA router MAY add the 5322.BCC for the blind recipient only.
none - MSA router decides.
- For MIME mail, assume BLIND=BCC
- For text/plain simple mail, assume BLIND=NOTE
The point is that AFAIK for a long time, the way it worked for most
systems, the BCC is stripped and two mail streams are sent. (I am
going to do a test with my TBIRD shortly to confirm, but I use to use
OE and it was the same way.)
That means the end-point MUA will never really know unless:
- The BCC is kept in the 2nd Private Stream Only,
- A special top note is written making the reader aware of the
privacy nature.
I don't know if this answers your questions. I am just looking at the
technical aspects of it on how to technically implement it today. No
matter what, BCC targets must be made aware somehow so they they don't
mistakenly reply to all and that can only be done at the source today
(or the client MUA is 100% aware of its backend server MSA is going to
this work).
--
HLS
Robert A. Rosenberg wrote:
>
> At 16:14 -0400 on 04/15/2012, Robert A. Rosenberg wrote about Re:
> "proper" handling of BCC:
>
>> At 10:04 -0500 on 03/01/2012, Hector Santos wrote about Re: "proper"
>> handling of BCC:
>>
>>> There is also the consideration regarding displaying. The MUA may
>>> want to inform the BCC recipient to the privacy nature of the message:
>>>
>>> NOTE: THIS IS A BLIND COPY TO YOU. THE OTHER RECIPIENTS LISTED IN
>>> THE
>>> TO/CC DISTRIBUTION ARE NOT AWARE OF YOUR RECEPTION OF THIS MESSAGE.
>>
>> Query - For issuing this message, how do you determine that the
>> recipient is getting a copy of the message without being listed in a
>> To or Cc header due to being BCC'ed or being subscribed to a mailing
>> list (or do you treat a mailing list received copy as a BCC'ed copy)?
>>
>> I ignore the case of being listed in a To or Cc as a suppressed
>> address (ie: Group-Name:add1, add2, etc. ;) since the existence of a
>> group-name:; comment implies a hidden BCC list.
>
> I asked this question over a month ago and there were a number of
> replies which branched off from my query but did not answer it (due to
> misunderstanding my question or shoving the support onto the MSA).
>
> Thus I will ask it and try to be more explicit in what I want to
> understand.
>
> The situation is that I have just received a normal message with NO
> explicit indication that I was BCC'ed in the message body or via a
> header. IOW: I am not listed in the supplied TO or CC header (although I
> may be listed in a Received For clause if I am the only recipient in my
> domain).
>
> This BCC delivery would be due to being listed in the BCC header by the
> sender, being listed in a Group-name:address-1, address-2,etc.; address
> in the To or Cc header (shown in the received message as Group-name:;),
> or being sent the message by a mailing list. As I state, I will ignore
> the mailing list delivery as non-BCC (assuming that there is a List-ID
> header to flag this) and ask ONLY about the other two which are true
> cases of being BCC'ed.
>
> With that out of the way, I am reading a received message and want my
> MUA to warn me that replying will expose to whoever I reply to via
> Reply-To-All (ie: The To,Cc,From/Sender addresses) that I received a
> copy (even though not listed as To or Cc). Note that this is a warning
> that the MUA sends me when I try to queue/send the reply.
>
> My question is how would it decide that I should be warned in lieu of
> the message actually getting queued/sent. I will assume a sanity-check
> that the warning should NOT be raised if the message being replied to
> has a List-ID header (ie: It is OK to reply to mailing list messages
> since if you only want to lurk/monitor you should be cognizant of the
> fact the message came from a mailing list and it is your fault for
> responding if you do not want to indicate you are subscribed). Thus we
> are talking about only true BCC'ed messages. The only way I can see for
> the MUA to detect this is to look for me in the To and Cc headers and
> not finding me there (and not finding a List-ID) to issue the warning.
>
>
>
Hector Santos wrote: > > The point is that AFAIK for a long time, the way it worked for most > systems, the BCC is stripped and two mail streams are sent. (I am going > to do a test with my TBIRD shortly to confirm, but I use to use OE and > it was the same way.) > > That means the end-point MUA will never really know unless: > > - The BCC is kept in the 2nd Private Stream Only, > > - A special top note is written making the reader aware of the > privacy nature. > According to the TBIRD test, it stripped the BCC, and used one transaction (with two RCPT TO). I just did the test with OE, and the same happen. Our PX MUA creates two messages, one with the special privacy note. I don't see off hand how this can be otherwise be done currently today without some new IETF MSA proposal that the source MUA is aware of. If its going to use a single transaction with multiple RCPT TO lines, the RCPT TO: needs an attribute or a new command - RCPT BCC: or something like that. But the fact that its one transaction, to me, the design assumption by these MUA is that the backend is not expected to do anything here, and its doesn't expect the MSA to reconstruction the distribution list. That would be a major flaw here when it comes to the BCC. -- -- HLS
Hector Santos wrote:
> According to the TBIRD test, it stripped the BCC, and used one
> transaction (with two RCPT TO). I just did the test with OE, and the
> same happen.
>
> Our PX MUA creates two messages, one with the special privacy note. I
> don't see off hand how this can be otherwise be done currently today
> without some new IETF MSA proposal that the source MUA is aware of. If
> its going to use a single transaction with multiple RCPT TO lines, the
> RCPT TO: needs an attribute or a new command - RCPT BCC: or something
> like that.
>
> But the fact that its one transaction, to me, the design assumption by
> these MUA is that the backend is not expected to do anything here, and
> its doesn't expect the MSA to reconstruction the distribution list. That
> would be a major flaw here when it comes to the BCC.
Hmmm, I am just thinking, we can have a backward compatible method to
support a RCPT BCC: command.
For example:
C: MAIL FROM:< user1 <at> domain1.com>
S: 250 OK
C: RCPT TO:<user2 <at> domain2.com>
S: 250 OK
C: RCPT BCC:<user3 <at> domain3.com>
Two responses:
S: 250 OK - will MARK message.
S: 500 command not understood
If the MSA provides a positive response, then the MUA is does not have
to send a 2nd message. The MSA will add a special note and/or maybe
add back the BCC to the header so that at least the end-point MUA will
see the BCC in the mail view header display.
If the MSA provides a negative response, especially 500, then the MUA
now knows it will need to send a 2nd transaction with a special note
to the message or perhaps keeps the BCC in the header.
It all seems doable. The question I will consider is whether keeping
the BCC in the special message only good enough for the end targets to
realize it is special.
--
--
HLS
Hector, Three very quick observations about this: (1) Doesn't work end-to-end. If any relaying is involved, the odds that the relay knows enough about the delivery server to reliably make this commitment on its behalf are not high. (2) For a number of technical reasons, I'd recommend thinking about parameters or a separate command rather than changing the "TO" argument to something else. If nothing else, the extension model has been extensively tested for parameters and new commands and is basically fail-safe. I don't have any reason to believe that one could change "TO:" or "FROM:" in the RCPT or MAIL commands without encountering new and quite interesting bugs in one system or another. (3) IMO, we need to keep in mind that every extension has costs. While Robert has explained what he is trying to do, no one has offered a persuasive argument that it is important enough to justify trying to change huge numbers of MUAs and MTAs to make a heuristic that would work slightly better in some cases. In particular, a command variation would not help the recipient determine the difference between "no intentional BCC" and "sender doesn't support this mechanism for telling the recipient that a BCC is present". One could improve that situation by having the sender use a MAIL parameter with semantics of "if there are BCCs among the recipients, I promise to tell you" as well as the RCPT parameter (or other option) but it is questionable whether even that would make this valuable enough to be worth the effort. best, john --On Wednesday, May 23, 2012 10:06 -0400 Hector Santos <hsantos <at> isdg.net> wrote: > > Hector Santos wrote: > >> According to the TBIRD test, it stripped the BCC, and used >> one transaction (with two RCPT TO). I just did the test with >> OE, and the same happen. >> >> Our PX MUA creates two messages, one with the special privacy >> note. I don't see off hand how this can be otherwise be >> done currently today without some new IETF MSA proposal that >> the source MUA is aware of. If its going to use a single >> transaction with multiple RCPT TO lines, the RCPT TO: needs >> an attribute or a new command - RCPT BCC: or something like >> that. >> >> But the fact that its one transaction, to me, the design >> assumption by these MUA is that the backend is not expected >> to do anything here, and its doesn't expect the MSA to >> reconstruction the distribution list. That would be a major >> flaw here when it comes to the BCC. > > Hmmm, I am just thinking, we can have a backward compatible > method to support a RCPT BCC: command. > > For example: > > C: MAIL FROM:< user1 <at> domain1.com> > S: 250 OK > C: RCPT TO:<user2 <at> domain2.com> > S: 250 OK > C: RCPT BCC:<user3 <at> domain3.com> > > Two responses: > > S: 250 OK - will MARK message. > S: 500 command not understood > > If the MSA provides a positive response, then the MUA is does > not have to send a 2nd message. The MSA will add a special > note and/or maybe add back the BCC to the header so that at > least the end-point MUA will see the BCC in the mail view > header display. > > If the MSA provides a negative response, especially 500, then > the MUA now knows it will need to send a 2nd transaction with > a special note to the message or perhaps keeps the BCC in the > header. > > It all seems doable. The question I will consider is whether > keeping the BCC in the special message only good enough for > the end targets to realize it is special.
On 5/22/2012 8:45 PM, Robert A. Rosenberg wrote: >The only way I can see for > the MUA to detect this is to look for me in the To and Cc headers and > not finding me there (and not finding a List-ID) to issue the warning. This is the same configuration of information that occurs when you receive mail from mailing lists that do not use the List-ID field. Hence, your heuristic will fail some/much of the time. Since you are describing a user interface 'warning', as the action to take, it might tolerate some failures, depending upon the percentage and rate of failure. There is also the question of whether such a warning message would have any efficacy for regular users. There's good indication that it would not. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
> Francesco Gennai wrote: > > > >> I'd actually rather have an extension that worked the opposite way: Construct > >> the headers from an appropriately decorated envelope and add them to the > >> message, and if handling error results from RCPT TO is an issue for clients > >> have a means to require that only outright syntax errors be reported as a > >> command result and report all other errors later with a DSN. > > > > I would add to this discussion a possible (new?) need about the BCC handling > > (that come out in some scenario, see below) that is to forbid at MSA level > > the use of a BCC. > My Opinion: > After rethinking this, at first I would agree but I don't quite see > how this would fall under SMTP (as an extension) due to the wide agree > of how the integrated systems are done, i.e. the presumption as I > read SMTP would be processing the headers once it is accepted. You're right. The extension will not solve the problem because I will need to check for messages coming from clients that doesn't support it. > Maybe a internal (local vs remote) router will, perhaps even a gateway or a > mail importer who may be already doing final clean up (i.e. stripping > Return-Path or old uucp/slip "From " headers are no longer necessary). > > In this case I agree with the Ned approach (based on a SMTP extension) > > versus the one that currently we are using in the Italian Certified email > > system, where we are parsing the TO and CC headers and comparing the result > > with the list of RCPT-TOs (many platforms have been adapted to be compliant > > with such MSA requirement). > Interesting and curious for the genesis of that logic. The two don't > need to match. The offline MUA used did not do the separation? I suspect the most of the MUAs just sent only a copy with no BCC header. But in the case that a MUA should generate more than a copy there could a problem in managing such requirement by just comparing TO/CC with RCPT-TO (the copy without any BCC address could be accepted.... ) .... Francesco > -- > Sincerely > Hector Santos > http://www.santronics.com > jabber: hector <at> jabber.isdg.net
There are many angles to all this, including one that there is a major
difference in the types of MUAs, including in how it relates to the
headers, the managed "privacy" control required for blind copies, etc,
and in regards to the "Inventor" of email, in that era he was using a
ONLINE MUA, not an store and forward, offline based MUA.
That is a major distinction in all this. In fact, if you go the
fellows web site, there is sad and hilarious picture showing him in
front of what appears to be a DEC VT100/102 terminal and the caption
says something to the effect
if you look carefully, you can see the clear From/To/BCC UI
evidence of the
new EMAIL system.
It was saying "huh?" I could even come close to seeing any readable
characters or any fuzzy screen resolution whatsoever - but then again
it could be my failing eyes.
Any hoo, for MUAs regardless of the network, gateway, etc:
o Online
The backend handles the separation when the frontend/GUI offers fields
for this. When the post (clicks the Post/Send button) is made, the
backend needs to handle the distribution for privacy requirements
before putting/moving them into system's mail transport outbound
queues and/or local storage user bins.
o Offline
The RFC-based offline MUA is responsible for separating the targets
before SMTP sending for the following reasons:
First, there is no current SMTP solution, such as "BCPT TO" state
machine command option, and second, there is no expectation for SMTP
receivers to parse for 822/2822/5322 headers to extract distribution
targets.
In all case, backend or offline MUA needs to make sure the separation
for the privacy requirements are met.
There is nothing more embarrassing, including legal, to have mistakes
of exposing blind copies to the other non-blind recipients.
Robert A. Rosenberg wrote:
>
> At 13:17 -0500 on 02/28/2012, Tony Hansen wrote about Re: "proper"
> handling of BCC:
>
>> I actually started writing such a doc about a year ago, but never
>> finished it.
>>
>> Is it worth dusting off?
>>
>> Tony Hansen
>>
>> On 2/28/2012 12:24 PM, Dave Crocker wrote:
>>>
>>> On 2/28/2012 9:11 AM, Paul Smith wrote:
>>>>>
>>>> OK, I was wrong - but I've never seen a BCC handled in that way
>>>> before... I've sometimes received messages with a 'BCC' field
>>>> containing addresses who were NOT me (ie I shouldn't have known they
>>>> existed), and most MUAs I've seen (in fact, all those I've
>>>> investigated fully) just list those recipients in the envelope for a
>>>> single copy of the message. So, I've never seen a BCC field in a
>>>> message header, used 'correctly'.
>>>
>>> We have never really standardized BCC as an end-to-end construct, at
>>> the MUA-MUA level.
>>>
>>> d/
>
> Ways it can be handled is for the MUA to submit the BCC header to the
> MSA and have it remove the header while cloning the message to create
> one master and one copy for each BCC listing only the Address, have the
> MSA scan the To and CC assuming that any RCPT-TOs not there are BCCs and
> do the cloning, OR add a BCC indicator to the RCPT-TO and do the
> cloning. Not that the first 2 alter the MSA while the last alters both
> the MSA and MUA.
>
> In any case there needs to be some way of indicating the BCC contents.
> Note that there needs to be a way of triggering the insertion/display
> of the BCC listing only the recipient in the recipient's copy of the
> message that WILL NOT get triggered by a normal Mailing List message.
> Options 1 and 3 above qualify since there is a indication to the MSA to
> clone the message with a BCC. Option 2 since it triggers via a mismatch
> between the To/CC contents and that of the RECPT-TO will be the problem
> since there would be no difference to the MSA between a BCC and a
> Mailing List generated message.
>
> Note that I am just winging it and may be missing something and I am
> just doing some design spec thoughts above.
>
>
>
--
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector <at> jabber.isdg.net
At 18:45 -0500 on 02/28/2012, Hector Santos wrote about Re: "proper" handling of BCC: >There is nothing more embarrassing, including legal, to have >mistakes of exposing blind copies to the other non-blind recipients. Remember the MTA that when presented with only RECPT-TOs and no addresses in either the TO or CC headers injected the full list of recipients as APPARENTLY-TO headers. OOPS.
To get back to the original question: On 2/28/12 7:17 PM, Tony Hansen wrote: > > I actually started writing such a doc about a year ago, but never > finished it. > > Is it worth dusting off? > > Tony Hansen which was a reply to: > > On 2/28/2012 12:24 PM, Dave Crocker wrote: >> >> >> >> On 2/28/2012 9:11 AM, Paul Smith wrote: >>>> >>> OK, I was wrong - but I've never seen a BCC handled in that way >>> before... I've >>> sometimes received messages with a 'BCC' field containing addresses >>> who were NOT >>> me (ie I shouldn't have known they existed), and most MUAs I've seen >>> (in fact, >>> all those I've investigated fully) just list those recipients in the >>> envelope >>> for a single copy of the message. So, I've never seen a BCC field in >>> a message >>> header, used 'correctly'. >> >> We have never really standardized BCC as an end-to-end construct, at >> the MUA-MUA level. and given the long thread of messages from at least ten people that followed, I certainly think it would be good if Tony wiped of the dust from his document and send a first draft to this list. /rolf
At 8:21 AM -0800 2/28/12, Ned Freed wrote: > > (Not to mention that bcc "fields" should not exist anyway - that's the >> whole point) > > Strongy disagree. The problem with implementations that cheat and implement > Bcc: by generating a single message copy with the Bcc: addresses only > appearing in the envelope is that those recipients do not get any sort > of indication that that were Bcc:'ed. If they don't realize that and > do a reply-all, the cat's out of the bad and the sender may be in big > trouble. Another source of potential BCC leakage are MTAs, which might record all local recipients. Most MTAs only record the recipient in a "Received:" header field if there is only one, but there have been some which record all. If the MUA generates multiple message objects and transactions, it no longer relies on the MTAs also not letting the feline escape its confinement/concealment. > And since users are careless, it really makes a lot of sense for MUAs > to check and see if they are doing a reply-all to a message that was Bcc:'ed > to them. That's only possible if a Bcc: field is present in their copy > of the message. Good point. > > In short, this is an implementation quality issue. The MUA I'm using to > enter this messages handles all of this correctly. > > Ned -- -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Politics offers yesterday's answers to today's problems. --Marshall McLuhan
> At 8:21 AM -0800 2/28/12, Ned Freed wrote: > > > (Not to mention that bcc "fields" should not exist anyway - that's the > > > whole point) > > Strongy disagree. The problem with implementations that cheat and implement > > Bcc: by generating a single message copy with the Bcc: addresses only > > appearing in the envelope is that those recipients do not get any sort > > of indication that that were Bcc:'ed. If they don't realize that and > > do a reply-all, the cat's out of the bad and the sender may be in big > > trouble. > Another source of potential BCC leakage are MTAs, which might record > all local recipients. Most MTAs only record the recipient in a > "Received:" header field if there is only one, but there have been > some which record all. If the MUA generates multiple message objects > and transactions, it no longer relies on the MTAs also not letting > the feline escape its confinement/concealment. Good point. I haven't seen that particular leakage, but I have seen one case where a for clause for only one recipient, selected who knows how, got inserted into a multi-recipient message and the message wasn't split. Of course the only way to be absolutely certain your bcc never leaks out is not to send it. But a certain amount of prudence on the part of implementors in the face of potential infrastructure issues is still a good thing. Ned
On 2/28/2012 8:21 AM, Ned Freed wrote: > In short, this is an implementation quality issue. The MUA I'm using to > enter this messages handles all of this correctly. I'll make clear what I implied. I think this is deeper than an implementation quality issue. We do not have a "protocol" specification for MUA-MUA (nevermind MUA/MSA, etc.) behavior involving BCC. More generally, we do not have a clear model and technical details for group communication with email. We have tidbits of mechanism. They variously work and don't. But we haven't defined a model and its details to form a solid, stable technical protocol basis for extended, group exchanges. Which makes the relatively high level of utility we get out of the current system for such communication modes pretty impressive... d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
> On 2/28/2012 8:21 AM, Ned Freed wrote: > > In short, this is an implementation quality issue. The MUA I'm using to > > enter this messages handles all of this correctly. > I'll make clear what I implied. I think this is deeper than an implementation > quality issue. > We do not have a "protocol" specification for MUA-MUA (nevermind MUA/MSA, etc.) > behavior involving BCC. Quite true, but neither do have have a specifications for a lot of other MUA-MUA behavior. Heck, we don't even have a clear specification for replies and forwards - yes, RFC 5322 talks about it some, and even tries to break it down into some specific use-cases, but falls far short of specifying the specifics of how it is supposed to work. > More generally, we do not have a clear model and technical details for group > communication with email. True as well, but as it happens there is a pretty clear and simple model for the semantics that attach to bcc. We didn't come up with it - in fact it goes all the way back to typewriters and hand manipulation of copies and the carbons between them - but it's a model nevertheless. And many if not most of the technical details of how you implement this stuff follow directly from this model. Of course this is no reason not to write this stuff down, if for no other reason that to spare new implementors the pain of working it out for themselves - and possibly working it out incorrectly. > We have tidbits of mechanism. They variously work and don't. But we haven't > defined a model and its details to form a solid, stable technical protocol basis > for extended, group exchanges. And I personally am dubious we could get consensus on one if we tried. > Which makes the relatively high level of utility we get out of the current > system for such communication modes pretty impressive... Agreed. Ned P.S. It's actually kind of fascinating how the implementation specifics of email have determined which parts of the venerable "office memorandum" model and structure we have kept intact, which ones we've discarded, and which ones we've moved around. For example, the lack of a structured footer combined with the relative ease of adding additional header fields caused the old "auther-initials:typist-initials" convention to morph (or if you prefer, be replaced by) our current From:/Sender: mechanism.
ned+ietf-smtp <at> mrochek.com wrote: > ... but as it happens there is a pretty clear and simple model for > the semantics that attach to bcc. We didn't come up with it - in fact > it goes > all the way back to typewriters and hand manipulation of copies and > the carbons > between them - but it's a model nevertheless. And many if not most of the > technical details of how you implement this stuff follow directly from > this > model. X.400 documented this pretty clearly. If we're going to discuss a model for Internet Mail, it'd be worth at least using that as a starting point. <csg>
> ned+ietf-smtp <at> mrochek.com wrote: > > ... but as it happens there is a pretty clear and simple model for > > the semantics that attach to bcc. We didn't come up with it - in fact > > it goes > > all the way back to typewriters and hand manipulation of copies and > > the carbons > > between them - but it's a model nevertheless. And many if not most of the > > technical details of how you implement this stuff follow directly from > > this > > model. > X.400 documented this pretty clearly. If we're going to discuss a model > for Internet Mail, it'd be worth at least using that as a starting point. Gonna have to disagree with you there. Having spent literally hundreds of hours poring over the X.400 documents and having done complete implementations of both X.400-1984 and X.400-1988, yes, the documents expand a large number of words documenting something they called a model, but the term "clear" definitely did not apply. If it had then none of the various operational profiles of X.400 like GOSIP (which added another three inch of paper to the pile) would have been wanted or needed. And even in the parts that were clear, they got an appalling number of details either flat out wrong or made them dependent on deployment of other services that was never going to happen. A good example of the former is the X.400 approach to media types - if you think our media type system has issues try building one that names things with random OIDs and which imposes no serialization requirement. (Every media type in X.400 is allowed to define it's own ASN.1 structure and you have to know that structure to interpret it properly.) To its credit, the EMA was working to address these issues by setting up a registry and disallowing all but the use of a single octet string to store the content, but X.400 faded away before any of that could be implemented. A good example of the latter is how read receipts in X.400 depend on being able to correlate envelope and header addresses. That effectivey presumed the existence of a global white pages service that allowed read access to everyone's aliases, which pretty obviously was a nonstarter from the get-go. In the specific case of the bcc model in X.400, my copies of the specifications are at work so I cannot check them, but if memory serves the model, while being fairly clear for once, called for this to be handled as part of P3 (the X.400 equivalent, more or less, of SUBMIT). In practice this was problematic if for no other reason than P3 was rarely if ever implemented, so the semantics it was supposed to provide didn't actually exist in most real world systems. Another issue was the X.400 equivalent of the issue Randy brought up with "for" clauses. In X.400 when a message is split information about all recipients is retained in both message copies; the information for recipients in the other copy is just marked inactive. The implications of that should be obvious. And the rules in the model for when this information was supposed to be dropped were ... unclear to say the least. Anyway, I really need to stop remembering this stuff before, as they say, any more of my gray cells hit the bug lamp. Ned
ned+ietf-smtp <at> mrochek.com wrote: >> > ... but as it happens there is a pretty clear and simple model for >> > the semantics that attach to bcc. > >> X.400 documented this pretty clearly. If we're going to discuss a model >> for Internet Mail, it'd be worth at least using that as a starting >> point. > > Gonna have to disagree with you there... yes, the documents expand a > large number of > words documenting something they called a model, but the term "clear" > definitely did not apply. If it had then none of the various operational > profiles of X.400 like GOSIP (which added another three inch of paper > to the > pile) would have been wanted or needed. I was only referring to BCC, which (in the dusty corners of my memory) I recall being one of the very few features of X.400 that I liked better than what we were doing on Internet Mail, if only because it actually defined it. <csg>
Carl S. Gutekunst wrote: > > ned+ietf-smtp <at> mrochek.com wrote: >>> > ... but as it happens there is a pretty clear and simple model for >>> > the semantics that attach to bcc. >> >>> X.400 documented this pretty clearly. If we're going to discuss a model >>> for Internet Mail, it'd be worth at least using that as a starting >>> point. >> >> Gonna have to disagree with you there... yes, the documents expand a >> large number of >> words documenting something they called a model, but the term "clear" >> definitely did not apply. If it had then none of the various operational >> profiles of X.400 like GOSIP (which added another three inch of paper >> to the pile) would have been wanted or needed. > I was only referring to BCC, which (in the dusty corners of my memory) I > recall being one of the very few features of X.400 that I liked better > than what we were doing on Internet Mail, if only because it actually > defined it. Yes, certainly a high usage usefulness to keep certain people in the loop. To me, as I seem to recall, it became harder with the advent of gateways and store and forward, i.e. decentralization. For example, in my old 80's Silver Xpress product, which I promoted as a "time shifted emulation of online hosting" supporting all the online security requirements in an offline fashion, there was some parts where the MUA can just push the mail with a BCC marker to the server and it knew how to handle it. The server was ready for it. The reader was offline, but it 100% emulated how the host will manage the mail. With an RFC-Based offline MUA, it needed to separate the sending as different transactions because the SMTP host was not ready for BCC separation idea and in my view, this was better for mail network gateways didn't need to worry about it as well. -- -- HLS
> ned+ietf-smtp <at> mrochek.com wrote: > >> > ... but as it happens there is a pretty clear and simple model for > >> > the semantics that attach to bcc. > > > >> X.400 documented this pretty clearly. If we're going to discuss a model > >> for Internet Mail, it'd be worth at least using that as a starting > >> point. > > > > Gonna have to disagree with you there... yes, the documents expand a > > large number of > > words documenting something they called a model, but the term "clear" > > definitely did not apply. If it had then none of the various operational > > profiles of X.400 like GOSIP (which added another three inch of paper > > to the > > pile) would have been wanted or needed. > I was only referring to BCC, which (in the dusty corners of my memory) I > recall being one of the very few features of X.400 that I liked better > than what we were doing on Internet Mail, if only because it actually > defined it. The problem is the pure definition is so short it isn't worth bothering with, and the larger scope of how it was implementing isn't really compatible with Internet mail, even if you consider it to be a good idea, which it wasn't. Ned
On 2/28/2012 5:33 PM, Ned Freed wrote: > Quite true, but neither do have have a specifications for a lot of other > MUA-MUA behavior. Heck, we don't even have a clear specification for replies > and forwards - Exactly. I didn't mean my comment on the lack to be taken narrowly. It was merely referring to what popped up in front of us. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
On 2/28/2012 1:02 AM, Paul Smith wrote:
> So, apparently he should be remembered for writing something like:
>
> send("From: ");
> send (sendersAddress);
> send(CRLF);
>
> (Not to mention that bcc "fields" should not exist anyway - that's the whole point)
BCC is more interesting than usually appreciated, IMO.
At the architectural level is the distinction between a construct limited to the
author's MUA, versus something with end-to-end properties.
As an MUA construct it lets an author note recipients that won't be indicated to
other recipients. Constrained to a UI mechanism, it's not really part of
Internet Mail architecturally. Its contents get added to the transport protocol
list (RFC5321.rcptto). The result looks rather like what a mailing list posts.
The tendency for MUAs has been to do only the above and thereby create only a
single submission posting. To do more requires at least one additional posting.
With separate postings, the MUA can submit variants of the email object.
What some MUAs do is a single additional posting, where the email object
contains an empty rfc5322.bcc header field. This can serve to alert the bcc
recipient that they are, in fact, a bcc recipient. One could have a receiving
MUA handle such a message differentially, though I believe none do.
I've also seen an added posting per bcc recipient, where the individual bcc
recipient's address is in their copy of the message.
There's a variant I did, but can't remember whether I got it done to the
original MH (by Bruce Borden and later taken over by Marshall Rose at UC Irvine)
or to MMDF while I was at UDel.
Anyhow, the enhancement was to prevent a Bcc recipient from unintentionally
sending a reply that copied the primary recipients. (This happens when a bcc
recipient does a Reply All.)
As I recall, for the bcc posting, I modified the rfc5322.to and rfc5322.cc
header field names to be: [To]: and [cc]:
Visually, this could look quite natural to the recipient, but of course the
Reply command wouldn't see them.
(the next person responsible for that code removed the feature.)
d/
--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
Well, this is sad: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian <http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html>It's more just strange. Looking at the article and the pictures that go with it, can anyone figure out what it was he was doing?
On 2/18/2012 5:39 PM, Carl S. Gutekunst wrote: > He holds the patent for Auto-reply, among other things. Yeah, he's characterizing it that generically. The patent claims are rather more constrained. I don't remember when auto-replying happened first, but I'm pretty sure it was the 70s. Certainly sendmail enabled such capabilities. Arguably so did MMDF. My guess it was in some earlier systems. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
Carl S. Gutekunst wrote: > John Levine wrote: >>> Well, this is sad: >>> V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian >>> <http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html> >>> >>> >> >> It's more just strange. Looking at the article and the pictures that >> go with it, can anyone figure out what it was he was doing? > > https://en.wikipedia.org/wiki/Shiva_Ayyadurai > > EMAIL is the name of the software package he wrote while in High School. > He holds the patent for Auto-reply, among other things. Which is frivilous and really silly because RBM (Rule Based Messaging) was patented technology a long time go and probably around the time where the new TIMELINE was instituted where PRIOR ART was thrown own by these silly software method patents. Just look at this way, his patent claims the idea for VACATION replies and mail filters using flexible rules you can create that include using body words triggers or more importantly long time CMS technology and help desk methods that 100% are based on body context. That is just a few. His patent is a prime example of the ills of the new Timelines in Software-Method Patents that essentials allows the ignorance of prior art for applying and when contested, allows him to simpler add reference to it in a patent update. But he has no power to enforce it on people who can prove prior art implementation and thus why I don't worry about this silly crap. -- -- Sincerely Hector Santos http://www.santronics.com jabber: hector <at> jabber.isdg.net
John Levine wrote:Well, this is sad: V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian <http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html>It's more just strange. Looking at the article and the pictures that go with it, can anyone figure out what it was he was doing?
https://en.wikipedia.org/wiki/Shiva_Ayyadurai
EMAIL is the name of the software package he wrote while in High School. He holds the patent for Auto-reply, among other things.
<csg>
Hi Dave, At 15:07 18-02-2012, Dave CROCKER wrote: >Well, this is sad: > > V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian > ><http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html> RFC 733 was published in November 1977. That's a year before what is mentioned in the article. RFC 680, published in 1975, mentions the header fields. Regards, -sm
On 2/18/2012 8:11 PM, SM wrote: > RFC 733 was published in November 1977. That's a year before what is mentioned > in the article. RFC 680, published in 1975, mentions the header fields. There were a series of efforts, with RFC 733 being the culmination, not the start. RFC 561, Standardizing Network Mail Headers, was Sept, 73. And then, of course, there's RFC 475, March, 73, specifying mail transport. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net
Going back to the original thread, Dave CROCKER wrote: > Well, this is sad: > > V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian > > http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html > This rebuttal article in TechDirt is useful for its links to other articles. http://www.techdirt.com/articles/20120222/11132917842/how-guy-who-didnt-invent-email-got-memorialized-press-smithsonian-as-inventor-email.shtml <csg>
On 3/1/12 1:51 PM, Carl S. Gutekunst wrote: > Going back to the original thread, Dave CROCKER wrote: >> Well, this is sad: >> >> V.A. Shiva Ayyadurai: Inventor of e-mail honored by Smithsonian >> >> http://www.washingtonpost.com/national/on-innovations/va-shivaayyadurai-inventor-of-e-mail-honored-by-smithsonian/2012/02/17/gIQA8gQhKR_story.html >> > > This rebuttal article in TechDirt is useful for its links to other > articles. > > http://www.techdirt.com/articles/20120222/11132917842/how-guy-who-didnt-invent-email-got-memorialized-press-smithsonian-as-inventor-email.shtml > And the Post has issued apologies: http://www.washingtonpost.com/blogs/omblog/post/origins-of-e-mail-my-mea-culpa/2012/03/01/gIQAiOD5kR_blog.html Well done, Dave and all. pr -- -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102
RSS Feed