Ryan,
I don't have to be a lawyer to understand the trade I've been directly
involved in nearly all aspects for the past 25+ years. I'm very competent
with the subject, especially product liability Product liability is an very
important aspect of our products engineering and design.
Trust me. You are putting your company and CEOs at risk by practicing
unethical mail tampering ideas.
Since 1986, the US ECPA (Electronic Communications Privacy Act) has covered
wiretapping (snooping), the privacy and tampering of electronic mail. It
is the basis for the ethical engineering and design of online mail hosting
and distribution systems. The exception to the rule is criminal activity at
the system level (illegal entry) and employer systems, but only from a
snooping standpoint and even then the employer is a risk.
The US ECPA also made it so that system policies must be used as
disclaimers, but this is only for covering why a MESSAGE will not be
accepted. Once the message is accepted, you take on the responsibility of
delivery with no mail tampering and more importantly keeping the privacy
intact.
Systems with TOS deal with contract law. However, not even then can it be
used to justify violating provisions in US ECPA and other cyber-space laws.
Finally in regards to current laws, I should note the US PATRIOT ACT has
open the door to wiretapping in the name of "security." While an system
always had the option to protect itself against system harm, the Patriot Act
opens it up to snooping "mail of interest," i.e, no-warrant spying. This
is quickly being challenged in court more and more (successfully).
In any case, the basic rule of thumb is:
- Thou should not tamper with route or passthru mail.
- Rejection is legally allowed at the submission level (transport or
interactive only).
- Once accepted, you must deliver or provide reason for non-delivery.
- On final storage, That means privacy must be maintained and no tampering.
This is all based on a key US ECPA concept - the all important "intent of
the user" must be respected. This has the been the design tradition for
decades now ever since the 1986 US ECPA.
Sure, over the years, especially with the advent of the internet, people
have broken these rules to the extent that many (like GMAIL.COM) are
outright doing unethical practices in your face. GMAIL.COM quickly got sued
as expected by many companies. But in general, if something goes wrong
where a harm occurred, you are responsible and thus claims or charges be
made against you.
This is one critical reason why the SENDER-ID or RFC 2822 analysis concepts
were problematic. In order to perform this task, unless the SMTP system
does it dynamically at the DATA state, you had to accept the mail for
post-smtp analysis. This post-smtp analysis raises many product liability
issues. It was no longer a legitimate "user didn't exist" concept but new
era of fuzzy mail interpretation analysis (as you said, false positives).
This is why in our product, our anti-spam/spoof system is strictly a 2821
concept. This level of security allows the operation to keep with the laws.
Yet, at the same time, we provide a "hook" system for 2822 analysis the
admin wishes to perform on his own. In other words, we pass on the product
liability responsibility to the admin here. It is not something we will do
on our own. The "2822 Hook" is skeleton the sysop defines on his own. This
is where most of our customers use some level of AVS software - free or
commercial.
Finally, I should note that 2822.From is an important network control
header. It is not just for information. It is the fallback reply address
if the Reply-To: header is not present. So you can't change this.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "Ryan Malayter" <malayter(_at_)gmail(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, September 30, 2004 7:23 PM
Subject: Re: [spf-discuss] The pretty name
[Hector Santos]
Push comes to shove, this is mail tampering and its against the law.
We're talking about *email*, not postal mail. I don't think the U.S.
laws regarding tampering with postal mail apply to email; I'm not sure
about other countries. Maybe wiretapping laws apply in some way.
Anyway, in the US at least, email received by an organization on
behalf of an employee is the property of the organization, not the
individual. And to cover another base, most service providers have
terms of service which give them the right to inspect, modify, block,
or do whatever else they want to to your traffic to keep things
running smoothly. An example can be found here:
http://www.earthlink.net/about/policies/dial/
...which seems to let Earthlink do whatever it wants to your traffic,
and change the terms of the agreement at any time.
But IANAL, and I don't really know what I'm talking about. Are you a
lawyer?
Don't screw around with user mail. Please consider
the fact I am not admin. We supply admins with the mail transport and
hosting software. Admins may have a different view on all this and in
many
respects,
I am an admin, for a few organizations. And I have had CEOs tell me to
stop the spam, phishing, and viruses. Now. Without changing anyone's
email address. The company owns all of the servers and mail content on
the network, so I do it as best I can.
I don't mind saying, it has caused a bigger mess over the years,
especially in the name of spam.
I assume you're talking about false-positive bounces caused by IP
blacklisting, challenge-response systems, etc. These all suck,
especially from an ISP's perspective, but something had to be done to
restore the utility of email for organizations. End-user content
filters may get 95+% of the junk, but that 0-5% is still an
overwhelming amount of crap.
ISPs, as a group, caused a big chunk of the problem we admins have to
deal with, by providing hosting and bandwidth to spammers. For a tidy
profit.
Of course, lazy admins contributed to the huge problem too, by
allowing all those virus-infected machines to spew spam and
virus-laden email. But consumers PCs are mostly to blame for that.
So in the end, we all suck eggs together.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com