Re: [Asrg] What are the IPs that sends mail for a domain?

Alessandro Vesely <vesely@tana.it> Tue, 23 June 2009 05:22 UTC

Return-Path: <vesely@tana.it>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844DE3A689F for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 22:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQAWiOUOUUMw for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 22:22:07 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id EFEE03A681F for <asrg@irtf.org>; Mon, 22 Jun 2009 22:22:06 -0700 (PDT)
Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Tue, 23 Jun 2009 07:22:20 +0200 id 00000000005DC031.000000004A40668C.00003343
Message-ID: <4A4066A0.50404@tana.it>
Date: Tue, 23 Jun 2009 07:22:40 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4A3FCD11.4080702@terabites.com>
In-Reply-To: <4A3FCD11.4080702@terabites.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] What are the IPs that sends mail for a domain?
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2009 05:22:08 -0000

Gordon Peterson wrote:
>  > Except that you cannot reliably determine whether a message is spam.
> 
> UCE isn't the only issue.  The issue is whether it's something that the 
> recipient wants to receive, or doesn't want to see.

What if I don't like to see bad news?

>  > Machines do not understand human language. [...]
> 
> I wouldn't "kill" stuff, unless the user has specified rules under which 
> they are willing to summarily kill it.  I think it's generally 
> worthwhile to file stuff on a local hard drive at the recipient, hard 
> drive space is cheap, so that they can go back and search for something 
> that maybe got routed to the spam folder that shouldn't have been.

Are senders required to send an SMS to prompt recipients to go 
search for their mail? Why don't we just use SMS transport then? We 
can still store it on our hard disks via bluetooth connections...

> Deterministically bad or incorrect is not an improvement.  The finely 
> grained rules I am talking about are absolutely deterministic, in any 
> case... even if they are hard for spammers to determine.

They are not. You may hold they are deterministic since they are the 
output of a deterministic machine. However, from users' points of 
view, both senders and recipients, based on just the data that each 
one sees, the behavior is randomly intermittent.

In facts, spammers and friends are treated alike. Making friend or 
foe determinations based on authentication would allow to discern 
more consistently.

>  > IMHO, the correct way to go is to have a (weak) authentication scheme
> that works well enough for most relevant cases, and at the same time
> keep the existing system as a compatibility option for the cases where
> it doesn't work.
> 
>  > If you want to use prehistoric appliances deploying obsolete mail
> transmission methods that have historically proven to be vulnerable to
> spammers,
> 
> All mail can be vulnerable to spammers.  But:
> 
>   1)  you can eliminate the shadows and tricks they use to conceal 
> themselves;

Not quite. E.g., Bill recently suggested, and I agree, that the 
single most effective method is using Spamhaus Zen list. Why would 
people use it if they could eliminate shadows and tricks spammers use?

>   2)  you can set up rules to eliminate the great majority of bogus 
> stuff (and I continue to add rules to my personal copy of Thunderbird on 
> an ongoing basis);

One could generate all combination of words and then look for those 
that make sense. That collection would include most literature 
masterpieces. It is not deemed the most effective method for 
creating new ones, though. BTW, how would your rules behave at that?

>  > (and wait until spammers decide to
> relate recipients to the From: addresses that they whitelist.)
> 
> They have no way to determine what addresses are and are not 
> whitelisted, and what the rules are for a given recipient.

There are places where they can sniff mail traffic. Infected 
machines is one, but I guess there are more, possibly related with 
spyware (too many times sending a sporadic mail abroad starts a 
sequence of spam apparently unrelated, except for the language; and 
I don't believe all of those recipients were infected, as some were 
part of tough organizations.) They could easily try and pick your 
whitelisted addresses from the recipients you write to, for example. 
I think they don't do it because they don't need it, yet.

>  > Try port 587.
> 
> How about if he's sitting at a desktop machine inside the customer's 
> office? He's not going to be able to reconfigure the mail software he's 
> sitting in front of.

Webmail

> Fine.  I am willing to simply decree that (for example) I don't accept 
> HTML mail, big messages, or attachments from people I don't know.  This 
> doesn't preclude people from contacting me, only preventing them from 
> abusing me (by whatever my own definition of "abuse" is, and ONLY MY 
> DEFINITION MATTERS!).

There are legitimate senders who use HTML just because it may look 
nicer, and is very difficult to acquaint them with the technical 
details that make it bad. Given that, you can delete their messages 
without telling, or reject them with an appropriate message. For a 
number of reasons, complicated rules are fired after the message has 
been accepted, and they may result in deleting or hiding the 
message. The more often that happens, the more misunderstandings. 
You may call that anything but a reliable system.

> I think the place to implement these tools is at the e-mail client 
> software level, where it is integrated and maps well with the user 
> interface that the user is familiar to with their e-mail.

Hmm... and the desktop machine inside the customer's office?