[quote user="Thomas R. Stephenson"]
The people in the Bcc: field are to be hidden from the people on the To; and Cc: list, this is a strict requirement of the RFC. The people on the Bcc: list do not (i.e. not required by the RFC) have to be hidden from other people on the Bcc: list. Personally this is the way I want it to be since in this case the people on the Bcc: list will also know who else got the message. This is the same way a normal blind copy is done with the office documents, the Bcc: list is sent as a separate sheet of paper to all people on the Bcc: list.
[/quote]
That is very interesting. Although I had gathered from the help files that there is some "wiggle room" in the usage/definition of Bcc in the RFCs, I had never understood the detail. Thomas has explained it clearly and succinctly and it is much appreciated.
Not knowing this background, I am one of the people who expect that Bcc addresses are always suppressed and so I have always had this option checked in order to achieve that, despite not understanding the reasons for allowing the option.
What we have here is the same problem that Microsoft cause almost everywhere they go: how to respond to the creation of de facto standards when accepted standards already exist?
Thomas has told us that, in fact, Pegasus provides for users to configure it to work with either of the methods allowed by the standard. Microsoft clearly decided many years ago that one method was their chosen way and this has become expected by most people simply because they think Microsoft's way is the "right" way.
Whilst I find it extremely arrogant of Microsoft to have entirely ignored part of the standard (as they have done many times over the years), I also recognise that users' modern expectations need to be catered for. As such, I feel that it would be sensible to have this option checked by default. Leaving the option there and re-writing the help file to better explain the functionality (and reasoning) when it is unchecked would allow new users to get what they expect out-of-the-box but leave the door open for them to be educated and see that there is an alternative which may suit them at times.
In short, support the full breadth of the standards but default to user expectations.
[quote user="Thomas R. Stephenson"]<BLOCKQUOTE><P>The people in the Bcc: field are to be hidden from the people on the To; and Cc: list, this is a strict requirement of the RFC. The people on the Bcc: list do not (i.e. not required by the RFC) have to be hidden from other people on the Bcc: list. Personally this is the way I want it to be since in this case the people on the Bcc: list will also know who else got the message. This is the same way a normal blind copy is done with the office documents, the Bcc: list is sent as a separate sheet of paper to all people on the Bcc: list. </P></BLOCKQUOTE><P>[/quote]</P><P>That is very interesting. Although I had gathered from the help files that there is some "wiggle room" in the usage/definition of Bcc in the RFCs, I had never understood the detail. Thomas has explained it clearly and succinctly and it is much appreciated.</P><P>Not knowing this background, I am one of the people who expect that Bcc addresses are always suppressed and so I have always had this option checked in order to achieve that, despite not understanding the reasons for allowing the option.</P><P>What we have here is the same problem that Microsoft cause almost everywhere they go: how to respond to the creation of de facto standards when accepted standards already exist?</P><P>Thomas has told us that, in fact, Pegasus provides for users to configure it to work with either of the methods allowed by the standard. Microsoft clearly decided many years ago that one method was their chosen way and this has become expected by most people simply because they think Microsoft's way is the "right" way.</P><P>Whilst I find it extremely arrogant of Microsoft to have entirely ignored part of the standard (as they have done many times over the years), I also recognise that users' modern expectations need to be catered for. As such, I feel that it would be sensible to have this option checked by default. Leaving the option there and re-writing the help file to better explain the functionality (and reasoning) when it is unchecked would allow new users to get what they expect out-of-the-box but leave the door open for them to be educated and see that there is an alternative which may suit them at times.</P><P>In short, support the full breadth of the standards but default to user expectations.</P>