VB2012, Dallas: Call for papers

See below. Submissions deadline is in just over a month from now.

Martijn.

Virus Bulletin is seeking submissions from those wishing to present
papers at VB2012, the 22nd Virus Bulletin International Conference,
which will take place 26-28 September 2012 at the Dallas Fairmont
hotel, Dallas, TX, USA.

The conference will include a programme of 30-minute presentations
running in two concurrent streams: Technical and Corporate.
Submissions are invited on all subjects relevant to anti-malware and
anti-spam. In particular, VB welcomes the submission of papers that
will provide delegates with ideas, advice and/or practical techniques,
and encourages presentations that include practical demonstrations of
techniques or new technologies.

Abstracts should be submitted via the online abstract submission
system at http://www.virusbtn.com/conference/abstracts/ and must be
submitted no later than FRIDAY 9th MARCH 2012.

Further details of the paper submission and selection process,
including a list of suggested topics for papers, can be found at
http://www.virusbtn.com/conference/vb2012/call/.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

Paris IETF

It's session scheduling time again.  I'm not going to ask for a session 
for ASRG, since we don't have anything going on to merit one, but if 
people will be there we could arrange to all have lunch one day.

Regards,
John Levine, johnl <at> iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

Re: RFC 6471 and "listing the Internet" as a punishment

At 07:07 24-01-2012, Martijn Grooten wrote:
>(Vamsoft ORF is a spam-filter.) Basically uribl.com was returning 
>127.0.0.1 to _all_ queries from nameservers that are sending high 
>volumes (presumably without paying for it) as some kind of 
>punishment. http://uribl.com/ confirms that.

   "After investigating this further, it seems the affected ORF users
    all use Google public DNS servers for the queries (or use such servers
    as forwarders in their local DNS configuration)."

Anyone using open recursive DNS servers or their ISP's DNS server for 
DNSBL queries is asking for trouble.  The listing is to get the 
attention of the sender.  It's "antisocial".

Regards,
-sm 

RFC 6471 and "listing the Internet" as a punishment

It was nice to see the RFC being published. Good work.

Then I came across this:

http://blog.vamsoft.com/2012/01/24/ub-black-uribl-com-url-blacklist-started-to-block-everything/

(Vamsoft ORF is a spam-filter.) Basically uribl.com was returning 127.0.0.1 to _all_ queries from
nameservers that are sending high volumes (presumably without paying for it) as some kind of punishment.
http://uribl.com/ confirms that.

Now, as Vamsoft mentions, it is not a good idea to use third-party nameservers on a server you're making DNS
requests from. (Although, unlike openDNS, Google's nameservers do return NXDOMAIN when they can't
resolve a domain.) Moreover, it does seem Google's nameservers are now getting REFUSED as a response to
any uribl.com request. I was just wondering whether the RFC says anything about this kind of behaviour
('listing' everything as a punishment). To my reading it doesn't.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

Re: RFC 6471 on Overview of Best Email DNS-Based List

I just blogged about RFC 6471 as well. Great update to usher in 2012.

Udeme 

-----Original Message-----
From: asrg-bounces <at> irtf.org [mailto:asrg-bounces <at> irtf.org] On Behalf Of asrg-request <at> irtf.org
Sent: Thursday, January 19, 2012 3:00 PM
To: asrg <at> irtf.org
Subject: Asrg Digest, Vol 88, Issue 1

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

http://www.irtf.org/mailman/listinfo/asrg

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Asrg mailing list submissions to
	asrg <at> irtf.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.irtf.org/mailman/listinfo/asrg
or, via email, send a message with subject or body 'help' to
	asrg-request <at> irtf.org

You can reach the person managing the list at
	asrg-owner <at> irtf.org

FW: RFC 6471 on Overview of Best Email DNS-Based List (DNSBL) Operational Practices

FYI

From: rfc-editor <at> rfc-editor.org <rfc-editor <at> rfc-editor.org>
Subject: RFC 6471 on Overview of Best Email DNS-Based List (DNSBL) Operational Practices
Date: 2012-01-19 01:04:37 GMT

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6471

        Title:      Overview of Best Email DNS-Based 
                    List (DNSBL) Operational Practices 
        Author:     C. Lewis, M. Sergeant
        Status:     Informational
        Stream:     IRTF
        Date:       January 2012
        Mailbox:    clewisbcp <at> cauce.org, 
                    matt <at> sergeant.org
        Pages:      21
        Characters: 49264
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-irtf-asrg-bcp-blacklists-10.txt

Handling of abusive DNSBL/WL clients

This spamassassin bug comment provides some information on what happens
when various methods of blocking abusive DNS queries are attempted.
The tests were conducted on dnswl.org, a public email whitelist enabled
by default in spamassassin, and presumably other things.

There seems to be a surprising lack, in RFCs and BCPs, of statements
that clients and forwarding DNS servers should stop querying if they
receive an NXDOMAIN, REFUSED, or an answer with the TLD of "invalid",
which seem likely to help if they were widely implemented.

It also seems like it would be good to define best practices for handling
this situation, quite possibly based on the information below.

SpamAssassin is currently asking DNS black/white list providers
to indicate the client is being blocked via a specified returned
IP value for all queries, in the case of DNSWL, 127.0.0.255.
There has been some debate on what would be an ideal value.
This is not in line with the blacklist BCP's suggestion to check
the values of 127.0.0.1 and 127.0.0.2, I guess because the SA devs
feel it's easier to implement.  Some related discussion was here:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6724

(My involvement - I'm not a SA dev, I've been participating on the dev
mailing list for a number of months.  I've been helping DNSWL on and
off for about 5 years.)

----- Forwarded message from bugzilla-daemon <at> bugzilla.spamassassin.org -----

Date: Thu, 22 Dec 2011 10:32:43 +0000
From: bugzilla-daemon <at> bugzilla.spamassassin.org

Reminds me of this list the most

http://tompreston.deviantart.com/art/Welcome-to-the-Internet-273281497

antiphishing idea

Hi,

I dont know if this is exactly the right place for discussing my idea
but I want to do a little bit of brainstorming with experts. I come
with a "crazy" thing but the logic is not so bad ! Please dont tell me
"you are crazy" ! .....at least at first time! :p

Users believe in what they read in the header from of the mail ! Users
don't also know about the existence and differences between envelope
and header From. And they also don't know that those addresses can be
forged. They blindly believe !

My idea is to invert the logic of DNSBLs. That is, instead of asking
third parties about spam/phishing why not asking the domain involved
in envelope and header itself about non-spam ?

Domains should have to publish in their DNSs the message-id (among any
other thing) through a TXT or A record of any legit mail sent by them.
The TTLs of those records can be adjusted to compensate for queued
mails, etc.

When you receive a mail from A and "aparently" from B you can query A
and B DNSs looking for the message-id the mail has. If you have a
nxdomain or whatever error from them you can score the mail as
phishing! ..on the other hand if you have a hit from at least one of
them you can be confident that this is the real domain that sends that
mail or it sends it on behalf the real address!

The check against both is to account for multi identities in what one
mailer sends in behalf of another (like gmail). You can also check

Phishing and domain reputation

The anti-phishing working group (APWG) published a report on phishing in the first half of 2011:

  http://www.apwg.org/reports/APWG_GlobalPhishingSurvey_1H2011.pdf

Lots of statistics on phishing, such as a significant rise in attacks compared to the previous six months,
which was largely due to attacks on Chinese organisations and their customers.

One thing I found interesting, and which prompted me to post about it here, is that only 2% of the phishing
domains contained the brand name of a variation thereof (e.g. paypaI dot com) and they've only seen two
examples of phishing attacks using IDNs and homographs (e.g. fácebook dot com) in since 2007.

Also, only 18% of the domains used (down from 28%) were registered by the phishers themselves; the other
domains were hacked or compromised.

It suggests that phishers do care about the reputation of domains as used by email/web filters (does the
domain have a history of legitimate content?), but little about reputation among users (does the domain
look like the one I expect for this site?).

I'm not sure about their definition of 'phishing'. This could have some influence on their statistics.

Martijn.

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

anti-spam updates for ISOC from the ASRG (fwd)

---------- Forwarded message ----------
Date: Mon, 14 Nov 2011 16:16:23 +0800
From: Joel M Snyder <Joel.Snyder <at> Opus1.COM>
Subject: anti-spam updates for ISOC from the ASRG

I am working with Sally Wentworth at ISOC on an update to ISOC's 
anti-spam web pages.  I wonder if the ASRG folks would be willing to take a 
look at what Sally sent out and offer up any comments or suggestions?

Sally's motivation is that some ITU Member States are proposing to define spam 
and include provisions related to spam in the ITR treaty at the WCIT.  In 
preparation for this, she thought it was time to update ISOC's anti-spam 
websites to highlight what the technical, policy and commercial communities are 
doing to combat spam and unwanted traffic (without the "assistance" of a 
treaty).

Here are the questions I have. I don't know whether you're comfortable with 
just passing them along (which would be fine with me) or whether you think I 
should try and connect more directly or whether you think  I should just go 
away and be quiet?

We are looking for short statements and pointers to work in the following 
areas:

- general description of the spam problem, including definitions, statistics, 
academic research in the area, and other general overview discussion.  The less 
commercial the better.

- general discussion of technical solutions to spam, such as CPE filtering, 
cloud filtering, reputation systems,   Any overview descriptions, comparisons,