[BBLISA] ISPs with p=reject DMARC policies?

Dean Anderson dean.anderson71 at yahoo.com
Thu Oct 6 20:38:19 EDT 2016


Few thoughts for 2016:

So, many years ago (like 1996 or so) I did some investigation and found that Information Theory determines that a communications channel can't be made free of covert (as in unwanted, unintended, outright really really want to suppress that) communications.

I had the resource of a largely unused class B address space in which I set up some open relay servers on, logged their packets, and then reported them to some blacklists.  I found that it was the anti-spam blacklists that were sending the spam.

I then noticed that a lot of spam wasn't "useful" even for marketing or even phishing.  Attempted to lure in phishers failed at extremely high rate (100% of dozens of tries did not get a response, no matter how fast I tried to respond.  This junk, wasn't even commercial or monetarily dishonest.  I proposed a taxonomy of spam to distinguish the cases of pure noise, from commercial or even legitimately dishonest phishing.  Anti-spammers all _REALLY_ hated that idea.

You might recall from history that SPF was going to "completely end spam" in 2002 or 3. Bill Gates even said so.  Well, it didn't. It seems that information theory was correct.  Of course, SPF is patented and large ISP's are certainly paying for that.

So there is nothing you can do to stop spam.   If you seem to have success with using a blacklist, you can be pretty sure they're the ones sending the spam. It's a protection racket.

You can filter out the weak stuff yourself:   The stuff that arrived from mailing lists you aren't subscribed to. There are some good guesses to be made from IP addresses that are out of region and dont typically send email. Particularly when they abruptly start sending a repeating email.  

And of course, email from real companies can generally be stopped.

But whatever you do, so spam will still get through. You just have a accept that and improve your ability to catch the weak stuff.

And another blast from the past was the talk about IPV6. As some historians might recall, IPV6 was supposed to be done in 1994.  There was a "cutover day" in 2003.  No one did.  There was a cutover day more recently.  We're still waiting for a protocol that actually solves a problem without the expense trump-style addressing...

You might find that ISO/CLNS and IS-IS still works on all your routers, and it's very secure.... 

And whatever happened to DNSSec?  I discovered a way to conduct a DOS attack by using the global anycast root servers to send a response with a long key (using a short query).  No one ever exploited that.  If you have a short key, it's breakable. If you have a long key, it's dangerous.  Hmm...

Ok, that's all. Have a good weekend...

Sent from my iPhone

> On Oct 6, 2016, at 7:37 PM, Steven M Jones <smj at crash.com> wrote:
> 
>> On 10/06/16 06:26, Edward Ned Harvey (bblisa4) wrote:
>> 
>> "break user expectations and/or degrade the user experience" is synonymous with "rawr, I want a random email server on the internet to be able to relay mail from me, I don't like it when things in the world change, rawr."
> 
> Amusing, however I often see the complaints written as:
> 
> "We've been working this way for 20/30/40 years, and your new thing
> broke it. You never should have proposed a new protocol that would
> invalidate an existing model or practice."
> 
> "Passing SPF with the list address in the 5321.MailFrom is sufficient
> for anybody. And you can tell it isn't spam because it came from a list!"
> 
> "This was a security problem at the ISPs, and they turned into a problem
> for the rest of us."
> 
> "We never had a problem with spam or phishing affecting us, and never
> asked for this."
> 
> "The Big Senders/Receivers imposed this on us, and are forcing us to
> change behavior to suit their needs. This is fundamentally an unfair
> burden on us, they have nigh-limitless resources and I have none. They
> should create a public registry of all mailling list servers so we can
> whitelist them."
> 
> "All my message filing and sorting happens on the From: address, and
> your workaround breaks that."
> 
> "The From: header was intended by God and Jon Postel to indicate the
> actual, original message author. Any change you make to that field is
> sacrilegious as well as fraudulent and must be stopped."
> 
> "DMARC should only use the Sender: or Resent-From: headers that most
> MUAs hide from the recipient."
> 
> "The big ISPs just want to kill all mailing lists and force us to use
> their ``groups'' services!"
> 
> 
> Alright, I got a little carried away there but you get the idea. I'm
> very highly sympathetic to the complaints that DMARC forces a change in
> user/list behavior. My roots go back to academia and the IETF over
> ISO/OSI, etc. I miss the days when the majority of NetNews was
> user-generated content.
> 
> But as you alluded, the root cause here is actually the highly effective
> activities of phishers, spammers, fraudsters, and attackers who leverage
> that unattributable model of email as a vector to successfully
> compromise consumers, companies, and governments; after which they can
> harvest real money, account info & personal data, and more. It's not
> because anybody wants to punish or proscribe these traditional uses.
> It's because the features they use are also being actively used to
> attack people, companies, and government agencies.
> 
> 
>> Take this list, for example. bblisa at bblisa.org. Notice that the From address says "from bblisa-bounces on behalf of Dan Ritter." You can ask our list moderators how the list is configured - Are we using "Munge From?" or some other setting?
> 
> Actually, FWIW, I see your address (@nedharvey.com) in the address field
> of the 5322.From header.
> 
> --S.
> 
> 
> _______________________________________________
> bblisa mailing list
> bblisa at bblisa.org
> http://www.bblisa.org/mailman/listinfo/bblisa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bblisa.org/pipermail/bblisa/attachments/20161006/510d9e25/attachment.html>


More information about the bblisa mailing list