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

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

Gordon Peterson II
http://personal.terabites.com
1977-2007:  Thirty year anniversary of local area networking
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg