Nabble - IETF - Asrg

Modified CEAS CFP

2009-10-30T09:11:46Z

CEAS 2010 Call for Papers [Online]

      Collaboration, Electronic messaging, Anti-Abuse and Spam
      Conference [formerly the Conference on Email and Anti-Spam]

The Seventh Annual /Collaboration, Electronic messaging, Anti-Abuse and
Spam Conference/ (CEAS 2010) invites the submission of papers for its
meeting in July, 2010. Papers are invited on all aspects of electronic
communication and collaboration, including email, instant messaging, and
other messaging methods including voice and video; social networks, blogs,
and wikis; user-generated content, ratings, and reviews; crowdsourcing,
citizen science, and human-based computation.

Academic and industrial research perspectives including novel applications,
theoretical work, analysis of real-world users and trends, and operational
or deployment case studies related to the conference topics are all warmly
encouraged.

Both full papers of up to 10 pages and poster papers of up to 4 pages will
be considered. Papers will be peer-reviewed by a committee of experts from
academic and industrial research centers.

---Suggested topics---

    * Message filtering, organization, and security
    * Adversarial learning using machine learning and natural language
      processing
    * Automated assistance, summarization, and search for online
      communication
    * Social networking security, privacy, and fraud prevention
    * Modeling and analysis of economics of abuse, phishing, spam, and
      fraud
    * Studies of abuse tactics and patterns
    * Scalability, reliability, archiving, and retrieval
    * Collaborative filtering of user-generated content
    * Protocols and standards for social networking, collaboration, and
      messaging
    * Standards for abuse reporting and monitoring
    * Crowdsourcing analysis, applications, and theory
    * Novel uses of wikis and blogs in science, problem solving, and
      education
    * Studies on the use of citizen science and human-based computing
    * Novel modes of distributed collaboration
    * Collaboration in adversarial environments
    * User trust and reputation
    * User identity issues that relate to the conference topics
    * Online fraud, cyber crime, identity theft, and other online crime

These are examples, and other topics within the scope of the conference are
also welcome; if you have questions about the applicability of your work,
contact the program committee at information@... <mailto:
information@...>

---Key dates---

    * *Submission deadline: March 26, 2010, 23:59:59 UTC*
    * Author notifications: May 21, 2010
    * Final accepted papers due: June 11, 2010
    * Conference dates: July 13 and 14, 2010

The 2010 conference will be held at The Commons, on Microsoft's main campus
in Redmond, Washington, and will dovetail with the SOUPS conference <
http://cups.cs.cmu.edu/soups/> at the same site during the same week.

The conference will once again run a /Spam Challenge/. Information about
the challenge will be posted on the conference web site, http://ceas.cc

Paper submission and venue details can be found online at the conference website.
http://ceas.cc

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: "email templates" for sale

2009-10-28T12:18:06Z

On Wed, Oct 28, 2009 at 12:33 PM, Danny Angus <danny.angus@...> wrote:
>
> Or, with respect, any need to forward spam to the list when it can be
> selectively quoted.

Right. Sorry.

--
warlorded myself
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: "email templates" for sale

2009-10-28T10:33:51Z

> They're
> quite useful but there's no need to change SMTP to handle them.

Or, with respect, any need to forward spam to the list when it can be
selectively quoted.
If we open that can of worms we'll really regret it.

d.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: "email templates" for sale

2009-10-28T08:12:38Z

>some time ago I suggested a template-filling SMTP extension and nobody
>on ASRG thought that would be a useful idea. Of course the consumers
>of the template product advertised in the message below will be
>passing filled templates to their outbound MTAs, and bandwidth is not
>their limiting factor, but anyway I feel validated.

People have been selling mail templates for years. There's even a
version of qmail that fills in templates as the mail is sent. They're
quite useful but there's no need to change SMTP to handle them.

R's,
John
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

"email templates" for sale

2009-10-27T13:45:30Z

some time ago I suggested a template-filling SMTP extension and nobody
on ASRG thought that would be a useful idea. Of course the consumers
of the template product advertised in the message below will be
passing filled templates to their outbound MTAs, and bandwidth is not
their limiting factor, but anyway I feel validated.

---------- Forwarded message ----------
From: What's New Now <wnn@...>
Date: Tue, Oct 27, 2009 at 12:28 PM
Subject: 10 free tried & true email templates

=========================================================
-------- WHAT'S NEW NOW SPECIAL OFFERS--------
=========================================================
-----------------------------------------------------------------
10 free tried & true email templates
-----------------------------------------------------------------

Download the Tried & True Templates + HTML Basics How-to Guide

http://eletters.whatsnewnow.com/u.d?v4Gvm2rS5IyrT78ieyRb=70

Is it time for you to try new email templates, but you just don't
have the resources to develop them yourself?

Are you uncertain whether your designs are built to ensure delivery
of your emails?

http://eletters.whatsnewnow.com/u.d?74Gvm2rS5IyrT78ieyRQ=80

Whether you are marketing to consumers or businesses, Lyris has
tried and true email templates to help you upgrade your efforts
and get better results without delay, including:

* Three email templates
* Two newsletter templates
* One business-to-business newsletter template
* Two consumer newsletter template
* And two transactional email templates

That's 10 Tried & True Templates. Plus, you'll also receive our
popular HTML Basics How-To Guide - all for free.

Download the Tried & True Templates + HTML Basics How-to Guide now.

http://eletters.whatsnewnow.com/u.d?jYGvm2rS5IyrT78ieyRV=90

Brought to you by Lyris HQ.

Please send an email to unsubscribe@... with the subject
line as "unsubscribe" if you'd like to stop receiving further
emails from Lyris HQ.

---------------------------------------------------------

=========================================================

You are subscribed to WHAT'S NEW NOW -- bringing you
important news and analysis from around Ziff Davis,
and special offers like this one -- with the

--
warlorded myself
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-27T11:06:39Z

On Tue, Oct 27, 2009 at 11:34 PM, Danny Angus <danny.angus@...> wrote:

> Hi Yao Ziyuan,
> I see you also posted this to the asrg. I'm shamelessly cross posting
> my reply, sorry in advance to *both* lists!
>
> My response is in two parts:
>
> a) I like the fact that the recipient can set up a test which must be
> passed by the sender. I also like the fact that the test would be
> passive protection when protecting against, for example spam viruses.
> In other words the recipient can set up a test, but the test itself
> only generates load when the sender considers it worthwhile to take
> the test.
>
> However I would prefer to see the test administered by the mail
> system, rather then via another channel.
> Solving the problem of spam by invoking a channel not currently
> involved in mail transport is not really a solution, it is both
> delegating the problem to another arena, and changing the nature of
> email.
>
> There's nothing inherently wrong with this, but if we are to consider
> changing the nature of email and channels involved we assume that we
> could design out the problem from the outset by introducing a strong
> concept of identity to the process.
>
> If we anticipate a design which uses the mail transport the passivity
> advantage breaks down as the sender must be notified that a test
> exists. In this case it would fail the criteria for not introducing
> *more* load (email) in response to spam.
>
> The goal is to find a solution which reduces the load as it becomes
> successful, even if faced with increased demand. What I mean is that a
> true solution would be completely passive when confronted with spam,
> and in reducing the spam transported would result in a net decrease in
> demand.
>
> A passive test that meets the criteria would be one in which a test is
> published in advance at low cost (perhaps by a third party), and for
> which the solution is encapsulated in the message when it is sent.

A sender may not think it's necessary to solve a test when sending a
message, but changes his mind later, when he realizes the message is
important and a reply is expected but doesn't arrive in time.

>
> For example the test may be for the sender to publish SPF records, or
> use a mark similar to the habeus warrant mark. A recipient domain can
> publish the test in the their T's & C's.
>
> If you want to consider CAPTCHA, perhaps the test would be to
> pre-solve a CAPTCHA, send the UID of the puzzle and its solution in
> the mail headers, but CAPTCHA is not really low cost, and is still
> another channel.
>
>
> b) the idea of using a CAPTCHA is flawed and has already been
> discussed at length by the asrg.
>
> In essence CAPTCHA works where there is less value in solving the
> puzzle than it costs to solve.
> If you introduce a strong commercial incentive you will start an arms
> race which will see people compete to develop systems which can solve
> puzzles at a lower cost, and others compete to develop more complex
> puzzles.
> We must assume that this will happen unless you can describe a test
> which can be reasoned to be unable to be solved by a machine.
> The fact that CAPTCHA are impractical to solve with current technology
> doesn't imply that they are impossible to solve.
>
> This ties in with point a) because it suggests that in operation the
> incentive is there for spammers to now not only send spam but also
> create additional work for the CAPTCHA component and the quarantine
> components.
>
> Even if spammers use systems which can only achieve a low sucess rate
> at the test, there is an incentive to attempt the test every time.
> This generates additional demand.
>
> d.
>
>
> On Mon, Oct 26, 2009 at 12:16 AM, Yao Ziyuan <yaoziyuan@...> wrote:
>> Passive Spam Revocation (PSR)
>>
>> Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam
>> filter, which can drop good and important messages.
>>
>> I propose an optional feature for current mail systems. The main idea
>> is if a message is considered spam, this spam status can be tracked by
>> the sender (but not sent to him directly, as the From field can be
>> faked). The message can be re-marked as "not spam" if the sender can
>> solve a CAPTCHA.
>>
>> STEP 1: A is going to send B a message. A's mail client generates a
>> random code and puts it in a custom field in the outgoing message's
>> header:
>> Code: <random code>
>> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
>> https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<Code>
>> This page displays one of these possible "spam statuses":
>> * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
>> * MESSAGE CONSIDERED NOT SPAM.
>> * PENDING. PLEASE TRY AGAIN LATER.
>> * All other responses mean B's mail system doesn't support this feature.
>> In the first case, A's mail client will report the status and the
>> CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message
>> is not spam.
>>
>> Like the idea? Here is the official Google group for it:
>> http://groups.google.com/group/passive-spam-revocation
>>
>> Regards,
>> Yao Ziyuan
>> http://sites.google.com/site/yaoziyuan/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@...
>> For additional commands, e-mail: server-dev-help@...
>>
>>
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-27T08:34:06Z

Hi Yao Ziyuan,
I see you also posted this to the asrg. I'm shamelessly cross posting
my reply, sorry in advance to *both* lists!

My response is in two parts:

a) I like the fact that the recipient can set up a test which must be
passed by the sender. I also like the fact that the test would be
passive protection when protecting against, for example spam viruses.
In other words the recipient can set up a test, but the test itself
only generates load when the sender considers it worthwhile to take
the test.

However I would prefer to see the test administered by the mail
system, rather then via another channel.
Solving the problem of spam by invoking a channel not currently
involved in mail transport is not really a solution, it is both
delegating the problem to another arena, and changing the nature of
email.

There's nothing inherently wrong with this, but if we are to consider
changing the nature of email and channels involved we assume that we
could design out the problem from the outset by introducing a strong
concept of identity to the process.

If we anticipate a design which uses the mail transport the passivity
advantage breaks down as the sender must be notified that a test
exists. In this case it would fail the criteria for not introducing
*more* load (email) in response to spam.

The goal is to find a solution which reduces the load as it becomes
successful, even if faced with increased demand. What I mean is that a
true solution would be completely passive when confronted with spam,
and in reducing the spam transported would result in a net decrease in
demand.

A passive test that meets the criteria would be one in which a test is
published in advance at low cost (perhaps by a third party), and for
which the solution is encapsulated in the message when it is sent.

For example the test may be for the sender to publish SPF records, or
use a mark similar to the habeus warrant mark. A recipient domain can
publish the test in the their T's & C's.

If you want to consider CAPTCHA, perhaps the test would be to
pre-solve a CAPTCHA, send the UID of the puzzle and its solution in
the mail headers, but CAPTCHA is not really low cost, and is still
another channel.

b) the idea of using a CAPTCHA is flawed and has already been
discussed at length by the asrg.

In essence CAPTCHA works where there is less value in solving the
puzzle than it costs to solve.
If you introduce a strong commercial incentive you will start an arms
race which will see people compete to develop systems which can solve
puzzles at a lower cost, and others compete to develop more complex
puzzles.
We must assume that this will happen unless you can describe a test
which can be reasoned to be unable to be solved by a machine.
The fact that CAPTCHA are impractical to solve with current technology
doesn't imply that they are impossible to solve.

This ties in with point a) because it suggests that in operation the
incentive is there for spammers to now not only send spam but also
create additional work for the CAPTCHA component and the quarantine
components.

Even if spammers use systems which can only achieve a low sucess rate
at the test, there is an incentive to attempt the test every time.
This generates additional demand.

d.

On Mon, Oct 26, 2009 at 12:16 AM, Yao Ziyuan <yaoziyuan@...> wrote:

> Passive Spam Revocation (PSR)
>
> Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam
> filter, which can drop good and important messages.
>
> I propose an optional feature for current mail systems. The main idea
> is if a message is considered spam, this spam status can be tracked by
> the sender (but not sent to him directly, as the From field can be
> faked). The message can be re-marked as "not spam" if the sender can
> solve a CAPTCHA.
>
> STEP 1: A is going to send B a message. A's mail client generates a
> random code and puts it in a custom field in the outgoing message's
> header:
> Code: <random code>
> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
> https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<Code>
> This page displays one of these possible "spam statuses":
> * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
> * MESSAGE CONSIDERED NOT SPAM.
> * PENDING. PLEASE TRY AGAIN LATER.
> * All other responses mean B's mail system doesn't support this feature.
> In the first case, A's mail client will report the status and the
> CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message
> is not spam.
>
> Like the idea? Here is the official Google group for it:
> http://groups.google.com/group/passive-spam-revocation
>
> Regards,
> Yao Ziyuan
> http://sites.google.com/site/yaoziyuan/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@...
> For additional commands, e-mail: server-dev-help@...
>
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T14:27:41Z

On Mon, Oct 26, 2009 at 03:26:40PM +0200, Pars Mutaf wrote:
> What if the CAPTCHA needs to be solved before the status can be seen?
> That would work?

Nope. (Let me pause to note that there are a number of other problems
with this idea as well, I just didn't articulate those.)

The gap between "captcha which is difficult enough to defeat a program"
and "captcha which is easy enough to be solved by a human" has already
closed -- and even if it hadn't, spammers have numerous other techniques
available to them that scale reasonably well, including (a) captcha
replay and (b) mass cheap labor. So I think it's reasonable that if
it becomes advantageous to spammers to solve captchas en masse, they will.

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T11:45:10Z

On Tue, Oct 27, 2009 at 2:35 AM, Yao Ziyuan <yaoziyuan@...> wrote:
> On Mon, Oct 26, 2009 at 9:26 PM, Pars Mutaf <pars.mutaf@...> wrote:
>> What if the CAPTCHA needs to be solved before the status can be seen?
>> That would work?
>
> Right. The sender can set a "wait period" for every outgoing message

for important messages

> -- if the wait period is over and there is no reply, his mail client
> can remind him to solve the CAPTCHA to see and fix the status.
>
>>
>> pars
>>
>> On Mon, Oct 26, 2009 at 1:41 PM, Rich Kulawiec <rsk@...> wrote:
>>>
>>> On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz
>>> wrote:
>>> > On the other hand, consider valid the hypothesis that spammers don't
>>> > know what kind of filter is being used (by some particular site) is also
>>> > a bad idea.
>>>
>>> Oh, I agree. It's long been known that [some] spammers have taken pains
>>> to track the characteristics of target sites/systems/networks/etc. And
>>> some of those sites are (in various ways) "announcing" details of their
>>> configuration to the outside world, which makes that task easier.
>>>
>>> ---Rsk
>>> _______________________________________________
>>> Asrg mailing list
>>> Asrg@...
>>> http://www.irtf.org/mailman/listinfo/asrg
>>
>>
>> _______________________________________________
>> Asrg mailing list
>> Asrg@...
>> http://www.irtf.org/mailman/listinfo/asrg
>>
>>
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T11:35:07Z

On Mon, Oct 26, 2009 at 9:26 PM, Pars Mutaf <pars.mutaf@...> wrote:
> What if the CAPTCHA needs to be solved before the status can be seen?
> That would work?

Right. The sender can set a "wait period" for every outgoing message
-- if the wait period is over and there is no reply, his mail client
can remind him to solve the CAPTCHA to see and fix the status.

>
> pars
>
> On Mon, Oct 26, 2009 at 1:41 PM, Rich Kulawiec <rsk@...> wrote:
>>
>> On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz
>> wrote:
>> > On the other hand, consider valid the hypothesis that spammers don't
>> > know what kind of filter is being used (by some particular site) is also
>> > a bad idea.
>>
>> Oh, I agree. It's long been known that [some] spammers have taken pains
>> to track the characteristics of target sites/systems/networks/etc. And
>> some of those sites are (in various ways) "announcing" details of their
>> configuration to the outside world, which makes that task easier.
>>
>> ---Rsk
>> _______________________________________________
>> Asrg mailing list
>> Asrg@...
>> http://www.irtf.org/mailman/listinfo/asrg
>
>
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg
>
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T06:26:40Z

What if the CAPTCHA needs to be solved before the status can be seen?
That would work?

pars

On Mon, Oct 26, 2009 at 1:41 PM, Rich Kulawiec <rsk@...> wrote:

On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz wrote:
> On the other hand, consider valid the hypothesis that spammers don't
> know what kind of filter is being used (by some particular site) is also
> a bad idea.

Oh, I agree. It's long been known that [some] spammers have taken pains
to track the characteristics of target sites/systems/networks/etc. And
some of those sites are (in various ways) "announcing" details of their
configuration to the outside world, which makes that task easier.

---Rsk

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T04:41:07Z

On Mon, Oct 26, 2009 at 11:08:15AM +0100, Jose-Marcio Martins da Cruz wrote:
> On the other hand, consider valid the hypothesis that spammers don't
> know what kind of filter is being used (by some particular site) is also
> a bad idea.

Oh, I agree. It's long been known that [some] spammers have taken pains
to track the characteristics of target sites/systems/networks/etc. And
some of those sites are (in various ways) "announcing" details of their
configuration to the outside world, which makes that task easier.

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T03:56:15Z

Yao Ziyuan wrote:

> Showing a message's spam status to the sender can be bad, if he is
> really a spammer. So the page can also return:
> * SPAM STATUS HIDDEN. (A CAPTCHA is also presented below.)
> This means the sender can solve the CAPTCHA to see the status and
> change it to NOT SPAM.

This would solve the problem of spammers testing the filters without
solving the captchas. However, any automated mailing system would be
unable to take advantage of the system. If the goal is just to provide
an additional mean for people to check if their messages have been
delivered, this wouldn't be a problem, but it would require some changes:
- it would be useless to automatically check for the message status
(which would be HIDDEN anyway), unless you expect people to be willing
to solve captchas for every message they send
- message status should be availabe for a long time, since people would
use this opportunity only if they somehow suspect that the message has
not been delivered

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T03:08:15Z

Rich Kulawiec wrote:
> On Mon, Oct 26, 2009 at 12:45:12PM +0800, Yao Ziyuan wrote:
>> The main idea is if a message is considered spam, this spam status
>> can be tracked by the sender (but not sent to him directly, as the From
>> field can be faked).
>
> Providing useful intelligence about (a particular site's) spam filters
> to spammers is a seriously bad idea.

On the other hand, consider valid the hypothesis that spammers don't
know what kind of filter is being used (by some particular site) is also
a bad idea.

JM

--
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T02:43:58Z

On Mon, Oct 26, 2009 at 12:45:12PM +0800, Yao Ziyuan wrote:
> The main idea is if a message is considered spam, this spam status
> can be tracked by the sender (but not sent to him directly, as the From
> field can be faked).

Providing useful intelligence about (a particular site's) spam filters
to spammers is a seriously bad idea.

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T02:03:21Z

On Mon, Oct 26, 2009 at 12:45 PM, Yao Ziyuan <yaoziyuan@...> wrote:

> Passive Spam Revocation (PSR)
>
> Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam
> filter, which can drop good and important messages.
>
> I propose an optional feature for current mail systems. The main idea
> is if a message is considered spam, this spam status can be tracked by
> the sender (but not sent to him directly, as the From field can be
> faked). The message can be re-marked as "not spam" if the sender can
> solve a CAPTCHA.
>
> STEP 1: A is going to send B a message. A's mail client generates a
> random code and puts it in a custom field in the outgoing message's
> header:
> PSR-Code: <random code>
> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
> https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code>
> This page displays one of these possible "spam statuses":
> * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
> * MESSAGE CONSIDERED NOT SPAM.
> * PENDING. PLEASE TRY AGAIN LATER.
> * All other responses mean B's mail system doesn't support this feature.
> In the first case, A's mail client will report the status and the
> CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message
> is not spam.

Showing a message's spam status to the sender can be bad, if he is
really a spammer. So the page can also return:
* SPAM STATUS HIDDEN. (A CAPTCHA is also presented below.)
This means the sender can solve the CAPTCHA to see the status and
change it to NOT SPAM.

>
> Like the idea? Here is the official Google group for it:
> http://groups.google.com/group/passive-spam-revocation
>
> Regards,
> Yao Ziyuan
> http://sites.google.com/site/yaoziyuan/
>
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T01:01:43Z

Yao Ziyuan wrote:
> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
> https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code>
> This page displays one of these possible "spam statuses":
> * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
> * MESSAGE CONSIDERED NOT SPAM.

A possibile problem is that a spammer can send a few test messages,
check which one is not considered spam and flood with the same kind of
message for a while, then check again and change format if required,
thus increasing spam effectiveness. It doesn't need to solve the captcha
for this.

--

Claudio Telmon
claudio@...
http://www.telmon.org

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Passive Spam Revocation

2009-10-26T00:57:02Z

Yao Ziyuan wrote:
> I propose an optional feature for current mail systems. The main idea
> is if a message is considered spam, this spam status can be tracked by
> the sender (but not sent to him directly, as the From field can be
> faked). The message can be re-marked as "not spam" if the sender can
> solve a CAPTCHA.

The mailing system described below is equivalent to direct-to-MX
mailing, except for the fact that the message is pre-fetched via
regular SMTP, which may be regarded as a compatibility hack. In
facts, the client connects directly to the recipient's server in
order to formalize the submission.

Direct-to-MX delivery has been discussed previously on this list.
Bill pointed out that funneling email through MSA systems run by
providers had been conceived for the very purpose of authenticating
authors and introduce domain-level accountability. See
http://www.ietf.org/mail-archive/web/asrg/current/msg15593.html

Allowing direct-to-MX delivery is likely to introduce more spam. The
requirement of human interaction would only raise the entry level
for leveraging such opportunity. CAPTCHAs can be solved by low cost
personnel, as it is currently done, e.g., by http://decaptcher.com/
at 0.002 USD per solved CAPTCHA. Although those micro-payments might
be considered similar to e-postage, that money would flow toward the
wrong ranks.

In addition, letting senders monitor whether their messages have
been marked as spam may turn out to be an advantage for those
senders who can tweak their messages until they cannot be discerned.
That's the reason why several servers drop spam rather than
rejecting it.

Finally, if widely adopted, PSR would hinder any form of mass
mailing, even legit.

> STEP 1: A is going to send B a message. A's mail client generates a
> random code and puts it in a custom field in the outgoing message's
> header:
> PSR-Code: <random code>
> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
> https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code>
> This page displays one of these possible "spam statuses":
> * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
> * MESSAGE CONSIDERED NOT SPAM.
> * PENDING. PLEASE TRY AGAIN LATER.
> * All other responses mean B's mail system doesn't support this feature.
> In the first case, A's mail client will report the status and the
> CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message
> is not spam.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Passive Spam Revocation

2009-10-25T21:45:12Z

Passive Spam Revocation (PSR)

Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam
filter, which can drop good and important messages.

I propose an optional feature for current mail systems. The main idea
is if a message is considered spam, this spam status can be tracked by
the sender (but not sent to him directly, as the From field can be
faked). The message can be re-marked as "not spam" if the sender can
solve a CAPTCHA.

STEP 1: A is going to send B a message. A's mail client generates a
random code and puts it in a custom field in the outgoing message's
header:
PSR-Code: <random code>
STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<PSR-Code>
This page displays one of these possible "spam statuses":
* MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
* MESSAGE CONSIDERED NOT SPAM.
* PENDING. PLEASE TRY AGAIN LATER.
* All other responses mean B's mail system doesn't support this feature.
In the first case, A's mail client will report the status and the
CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message
is not spam.

Like the idea? Here is the official Google group for it:
http://groups.google.com/group/passive-spam-revocation

Regards,
Yao Ziyuan
http://sites.google.com/site/yaoziyuan/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Anyone read that bot remediation draft?

2009-09-28T22:45:20Z

It's pretty good, but it's worth reading and commenting anyway.

>Dear Members -
>
>We are looking for feedback on draft-oreirdan-mody-bot-remediation-03.
>URL: http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03
>
>The I-D describes how:
>
>1. ISPs may detect that a customer has a bot infection,
>2. Ways to notify the customer,
>3. What the user should do to remediate the infection.

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: Request for Feedback: draft-oreirdan-mody-bot-remediation-03

2009-09-23T04:56:49Z

Mody, Nirmal wrote:
> We are looking for feedback on draft-oreirdan-mody-bot-remediation-03.
> URL: http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03

I think this bot-remediation I-D might be better coordinated with the
RID, http://tools.ietf.org/html/draft-moriarty-post-inch. Since
"[d]etection of a security incident is outside the scope of [the
latter] paper", they complement one another. In particular, the former
paper misses a definition of ISP, which is less ambiguously termed
"network provider (NP)" in the latter.

The definition of "Computer" given in 2.3 apparently limits the scope
of the I-D to end-user appliances, i.e. not servers. Although that's
consistent with the Problem Statement, it might be worth repeating it
in section "4. Important Notice of Limitations and Scope".

In section "2.4 Malware", I'd reword this snippet

This is short for malicious software. In this case, malicious bots
are considered a subset of malware. Other forms of malware could
include viruses and other similar types of software.

to make a clearer definition, e.g. as

This is short for malicious software. The bots we consider are a
subset of malware. Malware also includes viruses, Trojans, spyware,
adware, and similar types of software.

In the successive snippet

Alternatively, Internet-connected computers may become infected with
malware through externally initiated malicious activities such as the
exploitation of vulnerabilities or the brute force guessing of access
credentials.

I would also mention that an attacker may already know the password
(but doesn't this involve servers?) E.g.

Alternatively, Internet-connected computers may become infected with
malware through externally initiated malicious activities such as the
exploitation of vulnerabilities, the brute force guessing of access
credentials, or the exploitation of such credentials obtained at a
previously compromised computer.

The second paragraph in section "5. Detection of Bots" is very long
and difficult. In particular, in this sentence

It is likely that a combination of multiple bot
detection data points will prove to be an effective approach in order
to corroborate information of varying dependability or consistency,
as well as to avoid or minimize the possibility of false positive
identification of computers.

it is not clear what is a "data point"? I guess you are talking about
data interchange between ISPs, as detailed in the above mentioned RID.

The same paragraph again talks about bots that are "malicious in
nature", a concept that I fail to understand. The I-D never talks
about ascertaining whether a user knows about the bot and accepts
accountability for its actions, which would classify it as non-malware.

The section continues with items (a) through (g). I'd suggest
converting them to subsections, for better quoting and pointing to
them. Only a couple of those items are relevant for mailbox providers;
should that be noted?

I'm surprised about item (f)

f. ISPs may also discover likely bot infected hosts located at other
sites; when legally permissible or otherwise an industry accepted
practice in a particular market region, it may be worthwhile for
ISPs to share evidence relating to those compromised hosts with
the relevant remote ISP, with security researchers, and with
blocklist operators.

I assume it is about firewall-detected scans, attempts to access
closed ports, well known URIs, as well as dictionary attacks, and
similar. If there really exist laws that forbid to notify such
intrusion attempts to the relevant abuse mailbox, they are wrong and
the IETF should lobby the relevant governments for abrogating them...

The title of section "6.2. Telephone Call Notification" might perhaps
be changed to "Telephone or Fax Call Notification". In particular, fax
numbers are more often answered by computers.

In section "6.4. Walled Garden Notification", it may be worth to
mention IP fingerprinting as a possible disambiguation for NATted
hosts, as described, e.g., in
http://www.rbeverly.net/research/papers/tcpclass-pam04.html
http://www.sflow.org/detectNAT/. This concern is addressed in section
7 ("diligence needs to be taken by the ISP where possible such that
they can identify") so a "see also" might be needed.

In section 7, the sentence
This security web
site should clearly explain why the user was notified and may include
an explanation of what bots are, and the threats that they pose.

assumes that the ISP is tightly coordinated with the provider of the
security web site. I only note that section 7 should be of interest
also for standalone computer servicing shops' web sites.

The text suggested for explanation ("What is a bot? [...]") does not
mention that the user may be held legally accountable for any damage
that the bot may perpetrate.

The paragraph of section "9. Security Considerations" sounds to me
like "since this doc is all about security, this section only exists
for accomplishing formal RFC requirements." IMHO, in this context, it
would be more useful to recap the risks of phishing by notifying false
infections, and to collect the passages where PII is concerned.

Finally, a few typos

s/solical/social/
s/poses can pose/can pose/
s/Compters/Computers/

HTH
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Request for Feedback: draft-oreirdan-mody-bot-remediation-03

2009-09-22T05:52:36Z

Dear Members -

We are looking for feedback on draft-oreirdan-mody-bot-remediation-03.
URL: http://tools.ietf.org/html/draft-oreirdan-mody-bot-remediation-03

The I-D describes how:

1. ISPs may detect that a customer has a bot infection,
2. Ways to notify the customer,
3. What the user should do to remediate the infection.

Thank you,
Nirmal

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

The difference between spam corpora

2009-09-07T09:05:33Z

All,

I have been wondering if any research has been done about the difference between different (kinds of) spam corpora*; I believe this is the right place to ask. (Oh, and hello, I am kind of new here too; a lurker for quite some time, but not sure if I've posted before.)

* throughout this email, by corpus I mean all emails in a live mail stream, used in real time.

To test a spam filter, or an anti-spam method or to do research about spam, it is inevitable to use a spam corpus. As the spam sent to one email address, or even one corporation, is unlikely to be representative of all the spam sent globally during that period, most people add the spam sent to one or more spam traps to their test. There is nothing wrong with approach, but, at least in theory, a lot of spam will not end up in such traps: mailings sent by dodgy ESPs; spam sent to addresses harvested from Outlook address books; spam sent to addresses obtained by hacking a company's customer database (or, perhaps more likely here in the UK, spam sent to addresses from a CD-Rom found on a train).

I am not sure how big a proportion of spam is of this latter kind, but I think it would be interesting to find out. Over the past months I have sent both our corporate mail stream and the spam from a distributed spam trap through a number of spam filters and the difference in performance was striking, with many products letting through ten or more times as much corportate spam as spam trap spam. Now easy-to-filter is just one way of quantifying a difference between spam corpora, but these results have led me to believe that spam traps, much as they are extremely useful, don't show the full picture.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-28T10:36:08Z

On 8/28/09 4:38 AM, Daniel Feenberg wrote:

Daniel,

> I don't doubt that many MTAs will accept IPv6 mail. What I dispute is
> the liklihood of anyone running a legitimate Internet MTA that accepts
> mail from an IPv6 only host. My reasoning is that such a host would have
> limited connectivity. There are two reasons for this. (1) Many MTA
> operators will lag in the adoption of IPv6 due to general lack of
> interest, ability or funds, so an IPv6 only MTA will have no access to
> many MTAs, much worse even than MTAs operating at dial-up addresses
> currently have. (2) Anyone operating an MTA on IPv6 will have to do
> without the single most effective anti-spam technique we have, the
> DNSBL. This will cause many operators with the resources to add IPv6 to
> hesitate to do so.
>
> Given either of these two reasons, few or no MTAs will run IPv6 only,
> which obviates the need for IPv6 entirely.

One of the significant changes we needed to make in our service when
becoming more popular in Asia's Pacific Rim, was to provide setting that
precluded other regions by default. This desire might not be
xenophobic, but based rationale interests. When large portions of a
country's connectivity is IPv6, having preferences for IPv6 seems
logical. The question you might consider would be whether those in IPv6
predominate regions even wish to accept IPv4 connections from areas
blighted with spam in languages foreign.

> Of course, some operators can do without DNSBLs, and they can easily
> operate dual-stack. There is no practical way they can drop IPv4, nor
> will they ever be able to do so.

Be a bit cautious about considering this a general statement.

> So, how much mail came from IPv6-only hosts? And what was the percentage
> of spam?

This type of measure will never uncover the amount of region specific
exclusions. You might be surprised to find IPv4 is not always king.

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-28T04:38:54Z

Tim Chown wrote:

>Based on our stats from June, we received an average of 158,000 messages
>per day over IPv4 transport, of which 81% were deemed spam, while we
>received 438 (yes, 438!) messages via per day IPv6, of which 32% were
>spam. So even for us, v6 is less than 1% of all received mail.

The relevant percentage would be the spam percentage coming from hosts
that have no IPv4 address. The quality of dual-stacked hosts is not
really germane to the question of whether IPv6 only hosts will ever exist.

I don't doubt that many MTAs will accept IPv6 mail. What I dispute is the
liklihood of anyone running a legitimate Internet MTA that accepts mail
from an IPv6 only host. My reasoning is that such a host would have
limited connectivity. There are two reasons for this. (1) Many MTA
operators will lag in the adoption of IPv6 due to general lack of
interest, ability or funds, so an IPv6 only MTA will have no access to
many MTAs, much worse even than MTAs operating at dial-up addresses
currently have. (2) Anyone operating an MTA on IPv6 will have to do
without the single most effective anti-spam technique we have, the DNSBL.
This will cause many operators with the resources to add IPv6 to hesitate
to do so.

Given either of these two reasons, few or no MTAs will run IPv6 only,
which obviates the need for IPv6 entirely.

Of course, some operators can do without DNSBLs, and they can
easily operate dual-stack. There is no practical way they can drop IPv4,
nor will they ever be able to do so.

So, how much mail came from IPv6-only hosts? And what was the percentage
of spam?

Daniel Feenberg

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-27T16:23:23Z

On 8/26/09 8:48 PM, Chris Lewis wrote:

> Steve Atkins wrote:
>
>> I see this asserted a lot, but I don't really see much in the way of
>> plausible arguments to back it up.
>>
>> If anything, some blacklist techniques are likely to be easier and
>> more effective on IPv6 than v4 for the obvious NAT / dynamic
>> assignment reasons.
>
> Frankly, I don't think anything that earth shattering will occur, even
> if ipv6 takes over completely.
>
> Undoubtably some techniques will work better, some about the same, and
> some won't work worth squat - they'll either evolve to work better, fade
> into meaninglessness, or just outright die.
>
> It's not as if it hasn't happened before. See much use of open relay
> DNSBLs anymore? Thought not.

Treating /64 (the network of an IPv6 addresses) as having the same
reputation is destine for support issues when exceptions are needed for
various legitimate services.

When establishing an IPv6 block list, once exceptions are made,
retaining evidence for each of these exceptions removes any semblance of
there being an upper limit on the number of IP addresses logged. After
all, bad actors will start wearing large snowshoes in exception ranges.

For IPv6 addresses to become first-class citizens of the email
community, listing those that should be accepted rather those blocked
represents perhaps the only scalable solution while using similar tools.
Using DKIM messages to request inclusion of a new domain can also
assist in validating the servers.

Alternative solutions such as accessing a link returned to the domain
might be used as well. Nevertheless, DKIM should help reduce the
validation steps needed, and could help prioritize and expedite
inclusions requests. Knowing the domain rather than just an IP address
also allows more extensive correlations with prior abuses.

-Doug

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-27T04:29:17Z

On Wed, Aug 26, 2009 at 11:17:28PM -0400, Jeff Macdonald wrote:
> So, if one were willing to accept that there will be valid IPv6 MTA
> based connections, and the practicality of using IPv4 methods is no
> longer feasible, then your list would be composed of only SMTP
> envelope and body checks?

Hmmm. At the moment, it sure looks that way. Happily (at the moment)
those methods do a very good job: roughly 85% of total spam rejected
is rejected by those means before any IPv4 methods are used. But I
have to guess that this percentage will decline and that I'm going to
need to revisit/revise this.

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-27T02:26:33Z

On Wed, Aug 26, 2009 at 05:22:35PM -0400, Daniel Feenberg wrote:

>
> I think it unlikely that an IPv6 only MTA will ever have acceptance even
> as wide as, for instance, MTAs with "pool" or "dial-up" in their RDNS.
> IPv6 only MTAs will be refused by many MTAs. There are simply too many
> IPv6 addresses to blacklist bad hats, and blacklisting /48s would be a
> very broad brush. The advantage of IPv4 is that the number of addresses is
> finite, and legitimate holders of addresses are loath to waste them.
>
> I understand that many IPv6 capable MTAs exist, but I expect they do all
> or nearly all of their external traffic via IPv4. I don't mean a general
> condemdantion of IPv6, I am only saying that SMTP traffic from strangers
> on IPv6 is not likely to be worthwhile.

I think this assumption has some problems, particularly in the area of
IPv6 transition.

If one assumes that RFC3974 is still generally valid, and sites use both
A and AAAA records for MXes (as we do here), then such sites may receive
email via IPv4 or IPv6, depending on the preference of the sending MTA.
And that's the important thing - that MTA if sendmail (for example)
defaults to trying IPv6 first, so you won't just receive IPv6 SMTP
connections by being IPv6 only, but also from any sender who, probably
like you, is dual-stack.

We choose to run MTAs dual-stack so we can accept mail (internally or
externally) from IPv4-only, IPv6-only or of course dual-stack nodes.

I think if you reject IPv6 SMTP, even if 'just' from strangers, you
make transition harder - you either don't turn on v6, or if you do you
prefer v4 over v6. Neither helps transition.

Based on our stats from June, we received an average of 158,000 messages
per day over IPv4 transport, of which 81% were deemed spam, while we
received 438 (yes, 438!) messages via per day IPv6, of which 32% were spam.
So even for us, v6 is less than 1% of all received mail.

The spam was largely from dual-stack mail list servers, not from random
clients/hosts. But it's interesting to look at specific connections -
non list spam tends to come from autoconfigured v6 addresses (implying
desktops) while 'good' mail comes from apparently manually configured
IPv6 addresses (because v6 admins know to not use autoconf addresses on
their servers).

One day I will convert the experience of 3+ years of running a dual-stack
MTA in production to a draft, and analyse the (at least) year's worth of
data on v6 spam sources that we have :)

Tim
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-27T01:50:44Z

John Levine wrote:
> A DNSBL that blocks a single IP at a time, like the CBL and XBL, would
> be unworkable. A typical v6 setup allocates a /64 to each host which
> allows various sorts of clever self-configuration, but also means the
> host can easily use a different IP address for every connection it
> ever makes. (At one address per millisecond, it would take 500 million
> years to run through a /64.)

Very well stated! I think we may say that, for any practical
concern, tracking IP addresses won't have clear advantages over
tracking registered domain names.

Rick's very detailed list provides many good hints. However,
sooner or later somebody should state some clear instructions
for running an MTA. I mean something that a company, an
association, or even a household can easily set up and maintain,
rather than an art/craft requiring arcane esoteric skills. In
particular, tracking registered domain names allows to keep
non-DNS settings unchanged through a change of connection
provider(s), which seems to me a worthwhile simplification.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-26T20:48:12Z

Steve Atkins wrote:

> I see this asserted a lot, but I don't really see much in the way of
> plausible arguments to back it up.
>
> If anything, some blacklist techniques are likely to be easier and
> more effective on IPv6 than v4 for the obvious NAT / dynamic
> assignment reasons.

Frankly, I don't think anything that earth shattering will occur, even
if ipv6 takes over completely.

Undoubtably some techniques will work better, some about the same, and
some won't work worth squat - they'll either evolve to work better, fade
into meaninglessness, or just outright die.

It's not as if it hasn't happened before. See much use of open relay
DNSBLs anymore? Thought not.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-26T20:30:17Z

On Aug 26, 2009, at 2:22 PM, Daniel Feenberg wrote:

>
>
> On Wed, 26 Aug 2009, John Levine wrote:
>
>>> Rich, does ipv6 change any of this?
>>
>> I'm not Rich, but the open question at this point is how effective
>> DNSBLs will be on IPv6.
>
> I think it unlikely that an IPv6 only MTA will ever have acceptance
> even as wide as, for instance, MTAs with "pool" or "dial-up" in
> their RDNS. IPv6 only MTAs will be refused by many MTAs. There are
> simply too many IPv6 addresses to blacklist bad hats, and
> blacklisting /48s would be a very broad brush. The advantage of IPv4
> is that the number of addresses is finite, and legitimate holders of
> addresses are loath to waste them.

I see this asserted a lot, but I don't really see much in the way of
plausible arguments to back it up.

If anything, some blacklist techniques are likely to be easier and
more effective on IPv6 than v4 for the obvious NAT / dynamic
assignment reasons.

Cheers,
Steve

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-26T20:17:28Z

On Wed, Aug 26, 2009 at 6:21 PM, Rich Kulawiec<rsk@...> wrote:

> On Wed, Aug 26, 2009 at 06:06:01PM -0000, John Levine wrote:
>> >Rich, does ipv6 change any of this?
>>
>> I'm not Rich, but the open question at this point is how effective
>> DNSBLs will be on IPv6.
>
> What John said.
>
> Point blocks already have their issues, for example (a) hosts using
> dynamic addressing can hop around within a network allocation and
> (b) spammers can try to use snowshoe techniques to tread lightly
> enough to evade them. And they can be unwieldly. I think all of
> this is likely to get worse with IPv6. I rather suspect that this
> will lead to mechanisms using entire network blocks -- some of which
> we already have. (For example, we have MTAs that understand blacklists
> in CIDR format.)
>
> At least some of the other measures should continue working, though,
> as they're independent of IPv4-IPv6. But I think while they may be
> helpful, they're not going to be enough.
>
> I don't see much help coming from SPF or DKIM or whatever: most of the
> spam that makes it past my setup is correctly marked with one of these.
> (<cough> Hotmail, Yahoo) I expect this will get much worse as spammers
> begin to leverage the full power of the botnets they're operating.

So, if one were willing to accept that there will be valid IPv6 MTA
based connections, and the practicality of using IPv4 methods is no
longer feasible, then your list would be composed of only SMTP
envelope and body checks?

--
Jeff Macdonald
Ayer, MA
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-26T15:21:05Z

On Wed, Aug 26, 2009 at 06:06:01PM -0000, John Levine wrote:
> >Rich, does ipv6 change any of this?
>
> I'm not Rich, but the open question at this point is how effective
> DNSBLs will be on IPv6.

What John said.

Point blocks already have their issues, for example (a) hosts using
dynamic addressing can hop around within a network allocation and
(b) spammers can try to use snowshoe techniques to tread lightly
enough to evade them. And they can be unwieldly. I think all of
this is likely to get worse with IPv6. I rather suspect that this
will lead to mechanisms using entire network blocks -- some of which
we already have. (For example, we have MTAs that understand blacklists
in CIDR format.)

At least some of the other measures should continue working, though,
as they're independent of IPv4-IPv6. But I think while they may be
helpful, they're not going to be enough.

I don't see much help coming from SPF or DKIM or whatever: most of the
spam that makes it past my setup is correctly marked with one of these.
(<cough> Hotmail, Yahoo) I expect this will get much worse as spammers
begin to leverage the full power of the botnets they're operating.

---Rsk
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-26T15:17:19Z

Apologies if this comes over in an inflammatory or tediously weak way,
but...

On Wed, 2009-08-26 at 17:22 -0400, Daniel Feenberg wrote:
> I understand that many IPv6 capable MTAs exist, but I expect they do all
> or nearly all of their external traffic via IPv4. I don't mean a general
> condemdantion of IPv6, I am only saying that SMTP traffic from strangers
> on IPv6 is not likely to be worthwhile.

This is different from IPv4 SMTP traffic from strangers how, exactly?
The vast majority of previously unseen connections handled by MTAs under
my direct control right now using v4 only are "not likely to be
worthwhile". The fact that there are several powers of 2 (well, many)
more hosts in the v6 world makes no difference apart from a scaling
factor.

Imagine if I ran a hypothetical organisation which used network
intelligence gathered from previous SMTP sessions to determine how to
handle a connection from a previously unseen host - it wouldn't matter a
jot if those connections came from a v4 or a v6 host. The only common
factor is that they were previously unseen (ie a "stranger").

Well run organisations will fix the address (as they do now) of their
outbound MTAs, and therefore allow intelligence to build up over time
about their usage and "goodness quotient". If anyone's crazy enough to
float the outbound IP around, even inside a v4 /24, then they should
expect their reputation to stay on the side of "low". If they do it
inside a v6 /64, they're really crazy.

Graeme

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

Re: [ASRG] SMTP pull anyone?

2009-08-26T14:22:35Z

On Wed, 26 Aug 2009, John Levine wrote:

>> Rich, does ipv6 change any of this?
>
> I'm not Rich, but the open question at this point is how effective
> DNSBLs will be on IPv6.

I think it unlikely that an IPv6 only MTA will ever have acceptance even
as wide as, for instance, MTAs with "pool" or "dial-up" in their RDNS.
IPv6 only MTAs will be refused by many MTAs. There are simply too many
IPv6 addresses to blacklist bad hats, and blacklisting /48s would be a
very broad brush. The advantage of IPv4 is that the number of addresses is
finite, and legitimate holders of addresses are loath to waste them.

I understand that many IPv6 capable MTAs exist, but I expect they do all
or nearly all of their external traffic via IPv4. I don't mean a general
condemdantion of IPv6, I am only saying that SMTP traffic from strangers
on IPv6 is not likely to be worthwhile.

Daniel Feenberg

>
> A DNSBL that blocks a single IP at a time, like the CBL and XBL, would
> be unworkable. A typical v6 setup allocates a /64 to each host which
> allows various sorts of clever self-configuration, but also means the
> host can easily use a different IP address for every connection it
> ever makes. (At one address per millisecond, it would take 500 million
> years to run through a /64.) DNSBLs can and do list ranges, and an
> obvious change would be to make the finest listed granularity be a
> /64, but we really have no idea how the vast number of v6 addresses
> will be handed out, and whether it will be practical to create
> listings that cover all of the available addresses for a particular
> host without also listing a lot of its neighbors.
>
> This suggests that whitelisting techniques (most likely based on DKIM)
> will become much more important to recognize mail from people you know
> are credible.
>
> R's,
> John
> _______________________________________________
> Asrg mailing list
> Asrg@...
> http://www.irtf.org/mailman/listinfo/asrg
>

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg