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

Ian Eiloart <> Mon, 22 June 2009 14:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA09C28C1BE for <>; Mon, 22 Jun 2009 07:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hL5vgtOrgYMl for <>; Mon, 22 Jun 2009 07:16:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6AB223A67F2 for <>; Mon, 22 Jun 2009 07:16:04 -0700 (PDT)
Received: from ([]:51503) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KLN912-000GBK-BV for; Mon, 22 Jun 2009 15:17:26 +0100
Date: Mon, 22 Jun 2009 15:16:19 +0100
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
Originator-Info: login-token=Mulberry:01MNXN6Jk2O01xQiFKnPujSkBblk3uQpP7pUA=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
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 14:16:06 -0000

--On 22 June 2009 07:19:04 -0500 Gordon Peterson <> wrote:

> And the circle goes round and round.
> Periodically, I feel it necessary to point out some of the serious flaws
> in all of these IP-based "authentication" type schemes.
> The first one has been pointed out, but perhaps not strongly enough.  IT
> RECOGNIZED SPAM E-MAILS.  It can double OR TRIPLE the bandwidth wasted by
> the original spam, in part because (at least in the case of spam which
> has been relayed one or more times) it is problematical to know WHO to
> send the bounce message to.
> In my personal mailboxes I have (way) more than 50,000 archived
> bounceback messages to e-mails which I have never sent... just because
> they have a (forged, and generally invalid) From: address that is
> supposedly in one of my domains.
> Since I haven't sent these messages (neither intentionally, nor by
> irresponsible management of my systems here) there is NOTHING I can do to
> prevent such messages.

There is, actually. If you publish SPF records with a strong -all, then 
recipients can easily decide to reject (not bounce) messages. Add DKIM 
signatures, and they'll be able to tell when someone has forwarded your 
legitimate email.

>  Meanwhile, the handling of the (worthless) bounce
> messages multiply by perhaps several times the bandwidth wasted due to
> the original spam.
> Barracuda spam blocking systems are particularly irresponsible by
> apparently not explaining to their users WHY bouncing spam back to the
> sender is a Bad Idea, resulting in their (even less clever) users often
> apparently leaving that option set.
> Also let me reiterate (as was pointed out) that sending inquiry messages
> to try to authenticate a valid mail agent LIKEWISE multiplies the
> bandwidth already wasted by the original spam.
> 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.
> Furthermore, and I've mentioned this before, my domains that I use for my
> e-mail (including generally are handled by my domain
> provider, although if I am away from home (say, at an Internet cafe,
> perhaps onboard a cruise ship or airport kiosk or at a public library
> somewhere, to name several examples) 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
> for mail submitted from the location that I happen to be sending from.
> The fact that I am sending outgoing mail though an unfamiliar and
> inhabitual location doesn't mean that it's not legitimate, and I'm
> certainly not going to switch my "From" address for such messages to some
> other "From" address just because it matches somehow the mail server that
> I happen to be sending through.
> 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.
> 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.  It is FAR less useful to only have the company's
> SMTP logs evidence to the delivery to an upstream ISP's 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.  The same situation occurs when a private individual is on
> holiday visiting (or staying with) a relative whose internet connection
> is provided by a different provider.  Again, sometimes legitimate mail
> must be routed through an inhabitual outgoing mail server.
> Anyhow, these braindead schemes about trying to decide whether a mail
> server is or is not supposed to be sending mail for a given return
> address, or blocking all mail being forwarded by a widely shared mail
> relay (based on its IP address) just because ONE of the (even tens or
> hundreds of thousands of) users of that same relay happened to get
> infected, is just insane.  It's not sufficient that the scheme initially
> looks appealing because it works "much" of the time.
> 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.
> In the case of E-mail, the corresponding policy could screen incoming
> e-mail messages based upon the characteristics _expected_ in e-mail
> coming from specific individual (familiar) senders (this is not unlike
> the technique that an intelligent human reader would use, when they open
> an e-mail claiming to come from a company or friend and the e-mail upon
> opening not looking "right" based on what we would expect that company or
> friend to be sending.  An example is cases where companies like Grouply
> manage to convince naive users to provide Grouply with the user's e-mail
> credentials, and where Grouply then uses the user's e-mail identity to
> send Grouply's spam... and when the recipient opens the message, it
> clearly doesn't look like an e-mail that Aunt Martha typically sends).
> E-mail coming from unfamiliar correspondents can be held to a (even much)
> higher-than-usual standard regarding the ground rules for what is
> acceptable and what is not.  As a recipient, for example, I would be
> willing to state that I don't want mail containing HTML or attachments
> (or more than, say, 50K or 100K) from unfamiliar senders.  That would
> block (and in a robust way!) misrepresented HTML links (a key part of
> most phishing exploits), malicious scripting, ActiveX exploits,
> infectious attachments, and the like.  It's also noteworthy that such a
> policy blocks in one fell swoop nearly all the ruses and tricks that
> spammers use to try to evade (SpamAssassin-like) antispam content
> filtering... meaning that such filters suddenly become a great deal more
> effective and reliable.
> It seems best if such filtering is largely done at the recipient user's
> end, and preferably in conjunction with their mail software... so that if
> they are looking for an expected e-mail message, and find it in their
> spam folder, they can have (say) a simple dialog box pop up that offers
> the user to "allow mail like this in the future from this sender."
> It makes it a significantly harder challenge for spammers and abusers to
> evade antispam protections when they don't even know what criteria are
> used by specific recipients, or what From addresses those recipients
> might have "cut their (individual) keyway" to accept.  (And again, note
> that this is NOT just a simple 'whitelist' scheme... since it will accept
> mail coming from unfamiliar senders, it only just holds such senders to a
> particularly strict standard for what can, and must not be, contained in
> the e-mails those unfamiliar senders send out.)

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see