A preview of this month's (unofficial) ASRG summary. Comments/changes by
tomorrow morning 10pm UK time, please, although we'll entertain minor
suggestions for changes for the rest of the week.
<BEGINS!>
This month's ASRG posed quite a few interesting legal questions, and
brought to light some interesting statistics.
Hector Santos wondered if the CAN-SPAM act gave spammers legal recourse
to sue or harass ISPs/anti-spam companies who were blocking spam that
complied with the law. Philip Miller thought not, and said that CAN-SPAM
only defined what senders can NOT legally do. Hector wasn't so sure, and
said that the act does "not attempt to change any current policy or
status quo", and that is was a 'long standing practice held by ECPA
(Electronic Communications Privacy Act) precedence' that once you accept
a message, it must be delivered.
Denny Figuerres suggests that by permitting some content to be
'published', and other similar content to not be 'published', then
you're effectively engaging the role of "Editor/Publisher", and that can
cause you legal problems - ISPs have found this can cause problems if
they decide to censor some Usenet groups. John Levine suggested that US
law in fact 'provides broad immunity from liability due to good faith
efforts to filter offensive material'. As always, the author points out
he is NOT a lawyer, and that concerned parties should seek independant
legal advice.
Somebody reasearching Challenge/Response patents prior to 1997 mailed
the list asking if anyone had any information. Hector Santos pointed out
that this depended just how specific he was being - BBSs of yonder year
used a number of programs to verify email addresses and phone numbers.
'mathew' was clearly feeling a little cynical when he said that he
thought "any kind of 'ADV' flag belongs in the header defined for the
purpose, so it won't collide with existing use of the subject line no
matter how inevitably poorly client developers implement filtering." He
provided a real-world example of a mailing-list tag that he thought
might be problematic ("[sec-adv] Security advisory"). Jon Kyme pointed
out that the act requires clear labelling of the email as such - either
all MUAs would have to adapt to read the new headers, or the marker
would have to remain in the subject line itself.
Hector Santos, who himself develops SMTP server-software thinks that in
the future, customers looking for an SMTP server will 'ask one basic
question [even if they don't know what they're talking about]: Is your
system CAN-SPAM ready?' Yakov happened to get in touch with someone
selling email 'hosting' services, who claimed to be 'CAN-SPAM' friendly
... a telling transcript can be found here:
<http://article.gmane.org/gmane.ietf.asrg/7698>
Eric Dean found out that he apparently does business with 'some dumbass
spam company', who sent him their entire year-to-date spam history.
Interested parties can check out the data here:
<https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg08868.html>
B. Johannessen has been working on some spam analysis, and posted a link
to his excellent and informative spam statistics: <http://db.org/spam/>.
Yakov made the point that there was a subgroup specifically for
analysis, and that perhaps would be a better place to discuss such
things.
John Levine wondered if one of the reasons spam was more prevalent over
SMTP and NNTP because of the possiblity of a Usenet Death Penalty (UDP)
- sort of like a listing on an all-pervasive email real-time blackhole
list - or if it was simply because of the abundance of email users
that spammers don't bother trying to get their email onto Usenet.
Gordon Peterson had an interesting idea in reducing some of the
collateral damage that comes from spam by having a size limit and
content-limit (nothing but plain text) on all unsolicited email - to
start sending around large files and HTML, you need to be in your
recipient's whitelist. The idea behind this being that a number of
spammer's tricks (large sections of unrelated text, embedded images,
etc) would be rendered useless, while friends could still send
themselves cute little HTML postcards, or whatever floats their boats.
This was an idea to some extent reflected by Denny Figuerres, who
suggested that a subset of HTML allowed in email be defined, and that
MUAs should start supporting only that, dropping support for embedded
images and scripting in email.
John Fenley had seen some work on stylometric classification
(<http://www.sciencenews.org/20031220/bob8.asp>), and suggested its
use in anti-spam. Art Pollard pointed out that compared to Bayesian
filtering, they take a lot longer to train, and you need to throw some
serious horsepower at them.
Yakov announced the formation of some new subgroups, and the
reformation of another two. In brief:
Abuse Reporting Standards Subgroup:
This subgroup will investigate standards for email and network abuse
reports. It will coordinate with similar efforts in the IETF (IDWG and
INCH).
Best Current Practices (BCP) Subgroup:
This subgroup will research and document best practices for spam
management.
Filtering Standards Subgroup:
This subgroup will investigate standards for filtering for automatic
updates and sharing of filtering information, and better interaction
between filters, MTAs and MUAs.
Inventory of Problems Subgroup:
This subgroup will research and list problems in the current email
architechture relevant to spam.
Message Verification Subgroup:
This subgroup will research solutions for verifying and authenticating
email messages and header information.
SMTP Session Verification (SMTP-VERIFY) Subgroup:
This subgroup will research approaches for authenticating and
verifying the SMTP session.
More information about these can be found at the new ASRG website:
http://asrg.sp.am/
--
If you ever go temporarily insane, don't shoot somebody, like a lot of
people do. Instead, try to get some weeding done, because you'd really
be surprised.
-- Jack Handey
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg