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

Gordon Peterson <> Mon, 22 June 2009 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44E213A67B5 for <>; Mon, 22 Jun 2009 11:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R5xTY9wASMzB for <>; Mon, 22 Jun 2009 11:27:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9E6123A67D9 for <>; Mon, 22 Jun 2009 11:27:15 -0700 (PDT)
Received: from (ff-bigip1 []) by (Postfix) with SMTP id 7992F20FA9AB for <>; Mon, 22 Jun 2009 18:27:30 +0000 (UTC)
X-Spam-Summary: 30, 2, 0, 1108748d39e1eb5b, d41d8cd98f00b204,,, RULES_HIT:2:355:379:599:854:945:946:967:972:973:980:988:989:1042:1187:1260:1261:1277:1311:1313:1314:1345:1358:1437:1515:1516:1518:1535:1593:1594:1605:1730:1747:1766:1792:1963:2194:2196:2197:2198:2199:2200:2201:2202:2234:2378:2379:2393:2525:2553:2559:2563:2682:2685:2689:2691:2692:2693:2705:2730:2736:2737:2739:2745:2828:2857:2859:2898:2910:2917:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3636:3657:3743:3865:3866:3867:3868:3869:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4051:4120:4250:4321:4470:4659:5007:6117:6119:6248:7576:7652:7679:7808:7809:7903:8660:8957:8985:9025:9040:9108:9153:10007, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:none, DNSBL:none, Custom_rules:0:1:0
X-Session-Marker: 6765703261407465726162697465732E636F6D
X-Filterd-Recvd-Size: 9208
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTP for <>; Mon, 22 Jun 2009 18:27:29 +0000 (UTC)
Message-ID: <>
Date: Mon, 22 Jun 2009 13:27:29 -0500
From: Gordon Peterson <>
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
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-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Jun 2009 18:27:17 -0000

Gordon Peterson wrote:
 > > I believe that ultimately, the best way to deal with spam (okay, we're
 > > talking principle here, not necessarily given existing, insufficiently
 > > clever mail clients) is to simply deliver the spam to the recipient's
 > > system, and let their system decide which mail is wanted, and which is
 > > not, and to either simply delete or archive somewhere the mail which the
 > > recipient user's rules determine is not wanted.  I do not consider a
 > > bounceback message to be necessary or even desirable if a message is
 > > found to be spam/virus/phishing ... in part because you cannot reliably
 > > determine who the original, legitimate sender is (even if there IS one)
 > > to send the bounceback message to.

 > 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.

 > Machines do not understand human language. They make spam/ham
decisions based on indeterministic criteria. Why do we run journaled
file system on RAID drives when we would want to kill random files for
the sake of spam abatement?

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.

 > > [...] I (a) still want to use my own
 > > From: address for reply or posting permission purposes, even though (b)
 > > I might not have ANY say at all regarding what outgoing mail server(s)
 > > are used [...]
 > >
 > > The fact that it's easier, or cheaper, or otherwise "more efficient" to
 > > do antispam blocking using some halfassed, braindead scheme which
 > > doesn't work reliably or well for (even some admittedly small)
 > > legitimate mail transmissions doesn't make that the right solution.

 > The difference between content filtering and however braindead
authentication schemes is that the latter ones are deterministic,
rather than easier, or cheaper, or otherwise "more efficient".
Deterministic results mean that messages sent correctly are delivered
independently of their content, uniformly.

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.

 > 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

All mail can be vulnerable to spammers.  But:

   1)  you can eliminate the shadows and tricks they use to conceal themselves;

   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);

   3)  there is an enormous installed base, including applications (as in the 
case of embedded e-mail based accounting systems and similar) which are not 
something where humans are directly involved in sending the messages.

 > you have to accept that your mail will be handled via
compatibility options, including unreliable spam filtering.

That's okay, as long as the unreliable filtering happens at the RECIPIENT (and 
is something they can tweak) and and not at their ISP, (or, worse, enroute) 
where "nothing" can be done about it.

 > If you
expect your From: address to be treated specially, be aware that any
spammer can use it just like you do

That would be true, if they could guess the rules that are being applied to the 
messages.  Since those rules are determined by individual recipients, that 
becomes a very difficult gauntlet for the spammers and abusers to negotiate.

 > (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.

 > Anything that is capable to deterministically recognize that you are
really you, is an authentication scheme.

Right, but just establishing the definition seems like it doesn't advance the 
discussion much.

 > > Another situation is where an accounting system at one of my consulting
 > > clients generates and sends electronic invoices, EFT notices, price
 > > updates, etc to their customers.  For these cases, it is VERY helpful
 > > for their own inhouse outgoing LAN mail server (which maybe doesn't try
 > > to handle incoming mail at all) is going to try to send outgoing
 > > mails... if for no other reason than to have a local, inhouse log that
 > > evidences the delivery of the e-mail not just to a relay somewhere, but
 > > actually to (usually) the mail server associated with the destination
 > > indicated for the e-mail message.

 > How come you consider that log line reliable, given that it doesn't
tell you whether the corresponding message has been "simply deleted or
archive somewhere"?

It only tells me what it needs to tell me... that the message was delivered to 
the intended recipient's own incoming mail server (whether inhouse, at their ISP 
or whatever).  Anything that happens to it after that is (of course) beyond our 
control.  At least we got the message "there", and that's adequate evidence of 
our own "best faith" effort to deliver it.  As far as it being reliable, it's as 
reliable as our own outgoing mail server.

 > > Yet another case is where a traveling salesperson connects via a
 > > prospect's WiFi connection during a sales call visit on-site to his
 > > customer, and where that host's corporate network policy blocks sending
 > > of port 25 messages other than to/through that company's own outgoing
 > > SMTP server.

 > 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.

 > > I still believe that a far better and more worthwhile direction for spam
 > > blocking involves a combination of tools, probably much of it performed
 > > at the receiving end, involving a finely grained discrimination tailored
 > > to familiar versus unfamiliar (to the recipient) e-mail senders.  This
 > > is not unlike the way locks work... they generally provide a series of
 > > grooves, chamfers and cuts (to the key BLANK!) which prevent the vast
 > > majority of presented keys from even being inserted INTO the lock,
 > > before the pins of the lock do the final determination based on how the
 > > individual key has been cut.

 > Except that you want external unknown people to be able to contact you
by email (otherwise you could just use an unofficial port different
than 25 and relay mail privately within your closed group.)

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!).

 > It would
be also appreciable if newcomers could open brand new ESP shops and
run their SMTP servers without having to spend years learning the
intricacies of finely grained discrimination tools.

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.

 > As those tools evolve, desperately seeking new ways to find needles in
the growing haystack of spam, users experience more and more
malfunctions. If you dig into the actual rules and data that your
filters base their decisions upon, you may get surprised.

Maybe, but if it's not open to auditing and inspection, then that's the fault of 
the e-mail client software that implements it... and users can presumably switch 
to software that works better.


Gordon Peterson II
1977-2007:  Thirty year anniversary of local area networking