| 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 |
|
