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



--On 22 June 2009 07:19:04 -0500 Gordon Peterson 
<gep2(_at_)terabites(_dot_)com> 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
IS STUPID AND COUNTERPRODUCTIVE TO BOUNCE NOTICE OF NON-DELIVERY TO
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, thenrecipients can easily decide to reject (not bounce) messages. Add DKIMsignatures, and they'll be able to tell when someone has forwarded yourlegitimate 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 terabites.com) 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 http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg