Subject: [Asrg] Re: 2a. Analysis - Changed patterns in spamming?

From: Fridrik Skulason <[email-masked]>
Date: Fri, 7 Nov 2003 00:10:30 +0000

I posted a reply on this subject earlier today, mentioning some analysis
I had done on the spam reaching my spamtraps, which get around 3000
spams per day.

Analysis of the Content-Type charset revealed a sharp (around 95%)
drop in the number of Korean messages around October 1st, but a 
gradual increase in the number of Chinese messages for the last 6
months.

However, in my post I made one mistake - I mentioned the actual
names of the charsets ;-)

This caused the ietf.org spam blocker to kick in and reject my 
message:

   **************** eManager Notification *****************

   The following mail was blocked since it contains sensitive content.

   Source mailbox: <[email-masked]>
   Destination mailbox(es): [email-masked]
   Policy: Non-English Trap
   Action: Quarantine

   To prevent excessive spam abuse, non-English character sets 
   have been blocked at www.ietf.org.  The IETF Secretariat's
   official language of operation is English - although the 
   message you have sent was proper, your mail composer's 
   settings specified an Asian 'charset'  which is widely 
   used by spam abusers.  To permit your message (and confirm
   human response),  please include the keyword:  ' spamcontrol '
   somewhere in your message.  We apologize for any inconvenience
   this may cause.

   ******************* End of message *********************

This is wrong, of course - the message charset was not an asian
one, but the names of several Asian charsets were included in
the message body.  It seems this was enough to trigger the
spam filter - it is not sufficiently intelligent to search only
for the offending charsets within Content-Type.

Slightly off-topic, but a bit funny ;-)

--
Fridrik Skulason   Frisk Software International   phone: +354-540-7400
Author of F-PROT   E-mail: [email-masked]       fax:   +354-540-7401

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 06 Nov 2003 19:44:18 -0500

That's strange since according to the IETF anti-spam guidelines 
(http://www.ietf.org/spamcontrol.html), we are supposed to be exempt 
from ALL anti-spam policies. I have notified the IETF Mail administrator.

---

From: "Christopher Bird" <[email-masked]>
Date: Sun, 9 Nov 2003 12:33:48 -0600

I have a number of friends who regularly send technical articles to me
from publications. These typically show up in my inbox with the title of
the article. So far so good.
Now, one publication puts its own email address as the return address,
so if I were to reply, my reply would go to the publication and not the
sender. Others send the reply with the return address of the sender.
Both of these approaches cause difficulties, but not the same
difficulty.
In the first case, it is annoying because if I wish to thank my friend,
by replying, I get to send my thanks down a rat hole at the magazine.
In the second case, because my friend's email address is not on the same
email system as the magazine, we have what looks like an open relay kind
of behavior. The message comes from interestingarticle at magazine.com,
but the response would go to jsmith at smith.com.
I might well have a consent agreement with jsmith, so as far as I am
concerned mail that comes to me from the magazine under his name would
be acceptable - even desired. General mail from the magazine
(solicitations, etc.) is not acceptable.
Have we considered in our consent framework the ability to have trusted
mail that has been sent under the auspices of one person, even though
the actual source of the content is from an entirely different source?
If this addressed somewhere else already, then apologies. The archive is
getting to be a good size!
Regards

Chris

---

From: Jonathan Morton <[email-masked]>
Date: Mon, 10 Nov 2003 05:20:52 +0000

> the actual source of the content is from an entirely different source?

I think we're working on the assumption that the most recent 
sender/forwarder is the entity that needs to be trusted.

But in that case, why do one publisher's articles have the magazine's 
return address on them, if jsmith sent the mail?  It sounds to me as 
though jsmith has hit a button saying "send a friend this article", 
rather than forwarding it himself.  In that case, it's very difficult 
to build a strong trust relationship of any kind (without permitting a 
lot more mail from the publisher than you might intend), but a hashcash 
token might be sufficient.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email-masked]
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.

---

From: "Christopher Bird" <[email-masked]>
Date: Mon, 10 Nov 2003 07:09:59 -0600

Jonathan describes the situation perfectly. Jsmith (in my example) does
exactly what Jonathan outlined. So the scenario goes that jsmith the
subscriber says please mail this to my friend Chris.

Now looking at this from all points of view. It is in the economic
interest of the magazine to make sure that I have every opportunity to
subscribe and not just freeload on jsmith's subscription. It is in
jsmith's interest to keep sending me the articles (because they give us
something to talk about when hoisting a pint)m it is in my interest
because I am learning about something or seeing a point of view that I
have never had before.
So in some sense, I think that the piece should come jointly from the
magazine and jsmith. I have a consent agreement with jsmith, and this
item should be under that agreement. Of course getting the publications
to buy off is a different issue. I think it is probably quite important
that the consent agreement not hop from jsmith to the magazine. Just
because jsmith has emailed me something under our agreement does not
give the 3rd party license in any sense to use that agreement for
anything at all. (I suspect that some of the cleverer people in this
group can come up with great counter examples.)

Regards Chris
<snip> the content is from an entirely different source?
> token might be sufficient.
<snip>

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 10 Nov 2003 09:47:10 -0500

> sender/forwarder is the entity that needs to be trusted.

  See RFC 2487 (SMTP + TLS).  Everyone who handles the message needs
to be trusted.  But you can only determine/prove trust with the person
you're currently talking to.  This is a problem...

  Alan DeKok.

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 10 Nov 2003 14:25:11 +0000

> group can come up with great counter examples.)

But you *are* asking that jsmith be allowed to give your consent to a third
party. The only easy way of doing this that I can see is to employ a
special email address only for your interaction with jsmith. jsmith can
then give this to whoever they like. I daresay other kinds of consent
tokens might be useful - but they'd require that the publisher (in this
case) knew what to do with them. That would be the publishers problem.

--