| Ref # |
Principle or Proposed Principle
|
| ECS001 |
Email Client Software Developers should build in technology into such software to enable users to optionally (and the option should be set as the default setting which the user may manually change) identify and disable "web bugs" or other tracking devices in emails received by the user. |
| ECS002 |
Email Client Software should be written to ensure that an "X-Mailer:" header line, containing the name and version of the software, is always sent to the mail server. |
| ECS003 |
All Email Client Software should mandatorily (not optionally) provide BCC: as a sending alternative in addition to the usual TO: and CC: sending alternatives. Where a user attempts to send an email to multiple recipients via either the TO: or the CC: alternatives, a pop-up help screen should automatically appear, giving the user a suggestion of sending via BCC instead "as a security measure" - and asking if they wish to continue or change the addresses to BCC. |
| ECS004 |
Email Client Software Developers should build tools into the software which will parse the email headers AND the body of an email, performing NSLOOKUP, DIG, Traceroute, Whois and other such tracing functions. |
| ECS005 |
Email Client Software Developers should build in security precautions to prevent viruses, trojans or ther suspicious or surreptitious downloads from infecting the machines of end-users receiving emails, whether those downloads are by way of attachments, or scripts or other mechanisms embedded in emails. |
| ECS006 |
Email Client Software Developers should build in default & user-configurable spam filter and virus filtering technology to identify and separate spam email from legitimate email. |
| ECS007 |
Email Client Software Developers should design their software in a way that enables third-party developers to provide additional spam filtering, virus filters and other security plug-ins for that email client software. |
| ECS008 |
|
| ECS009 |
|
| ECS010 |
|
| ECS011 |
|
| ECS012 |
|