Re: [mailop] Super dumb gmail request ...

[Michael Rathbun via mailop]

On Thu, 29 Aug 2024 11:29:12 -0700, Brandon Long via mailop
 wrote:

>> "Don't be evil", indeed.  Missed that one by a mile.
>>
>
>The banality of evil or something, but trying to protect your personal
>information is generally considered
>a good idea and enforced legally around the world.  What is the benefit,
>the evil benefit, to Google of a
>poor choice of user verification?
>
>Evil : letting people other than you access your data
>Also Evil : trying too hard to make sure it's you accessing your data, or
>having bugs in the process

Evil is, in this case, making a major change in procedure that is central to
the user's needs, without notice to the user, while ignoring all the already
established and effective mechanisms which could accomplish the same thing
without as much fuss.  Assuming there is some value to the user's data and
services, locking the user out of those data and services without notice and
without recourse fits my personal definition of evil.

One reason I need to do the Special Login Dance is that my current employer
uses paid-for Google services, which are attached to a Google login ID that I
have no control over.  If you CAN tell me "Don't attempt to use your personal
Google services if you don't have your tablet with you, or it cannot make a
WiFi connection" ahead of time, then evil is NOT telling me.  

Evil can happen without any benefit to anyone at all.  I say this as a former
Microsoft employee.

mdr
-- 
   Sometimes half-ass is exactly the right amount of ass.
   -- Wonderella

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Super dumb gmail request ...

[Michael Rathbun via mailop]

On Wed, 28 Aug 2024 11:51:24 -0700, Brandon Long via mailop
 wrote:

>Typically, the phone number use in cases like this is part of trying to
>prevent bulk operations.

All I can personally say is that, when I recently tried to log in to Google to
retrieve some articles I had saved in Google News, I had to dig through the
old hardware pile to find a Galaxy Tab E that I had used years before, to
which Google had sent an unlock code.  There was no alternative channel for
the unlock code to be retrieved.  My only option was to dig through boxes to
find the Tab E, charge it up to the point where it could attach to local WiFi,
and see that, sure enough, there was a pop-up directing me to use this code
(now expired, due to all the rummaging) to log into my Google account.

Feh.  And again I say:  FEH!

"Don't be evil", indeed.  Missed that one by a mile.

mdr
-- 
My study of life and history inclines me to the apothegm "If you insist on
burning bridges, it is often best to cross them before engaging the
incendiaries." --  Shebardigan

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Uptick in Google Groups spam?

[Michael Rathbun via mailop]

On Tue, 27 Aug 2024 13:37:17 -0500, Robert Giles via mailop
 wrote:

>On the topic of free services that Google provides (with no support or 
>abuse contact whatsoever), has anyone else noticed an uptick in Google 
>Groups spam lately?

The latest Goog.spamflood here has been from the "appsheet" system.  Users of
this have enough "sudden death" spamtraps in their lists that at any moment at
least five of the outgoing IPs are in the penalty bin for at least 24 hours.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Amusing and Convoluted Request

[Michael Rathbun via mailop]

On 26 Aug 2024 16:11:30 -0400, John Levine via mailop 
wrote:

>This strikes me as yet another aspect of BMS, Bad Marketer Syndrome, the
>totally unwarannted belief that the entire world wants to hear what you
>have to say.

All the way back to '95, with those SoundCity guys in Altoona.  The wisdom was
received at the local level and they shut down the spewer, but the executives
absolutely forbade stopping all the spam, because EWWTHWYHTS.

Their upstream was able to clarify the issues, but alas times have moved on a
bit.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Plain connections on SubmissionS port

[Michael Rathbun via mailop]

On Sun, 11 Aug 2024 13:44:16 +, Slavko via mailop 
wrote:

>It is not big amount, nothing to worry about, i am just curious, if
>someone know what botnet/malware is behind that, as i cannot
>find any details about that. Please is it something known?

There is a wide variety of botnet activity, most of it startlingly inept.  

One variety insists on "EHLO User", ignores "550 5.7.1 Sender unknown" then
sends AUTH LOGIN, having no idea how to interpret "500 5.0.0 Unrecognized
command".  Eventually it gives up, to return 250 milliseconds later and try
again.  Hundreds of these from dozens of compromised IPs dot the daily log.
Eventually the "not more than N connections in M minutes" rule sends the IP
away for a day or two.

Then there's the 
  <-- MAIL From:
  --> 530 5.7.0 Authentication required
  <-- RCPT To:
  --> 503 5.5.1 Bad command sequence
  <-- DATA
  --> 503 5.5.1 Bad command sequence
show, repeated hundreds of time by dozens of compromised IPs.

The slightly less insane ones, apparently, notice the absence of "250-AUTH
LOGIN CRAM-MD5 PLAIN" in the banner (suppressed because of geolocated non-US
IP), do STARTTLS, notice no change in the banner, and quit.  Only to return
again and insanely try again N-1 times.

I mercifully refrain from detailing the other whackitudes.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Echospoofing

[Michael Rathbun via mailop]

On 30 Jul 2024 20:31:48 -0400, John Levine via mailop 
wrote:

>Sounds like it's the usual problem -- once the mail seems to work, no
>amount of nagging will get them to change anything until it visibly
>breaks.

This certainly accords with my daily lived experience.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Domains discrimination

[Michael Rathbun via mailop]

On Thu, 11 Jul 2024 17:21:29 -0400, "Scott Q. via mailop" 
wrote:

>I know it's not easy to handle hundreds of millions ( billions ) of
>e-mail accounts but they should suffer the same consequences as
>everyone else if they can't keep abusers in check. 

The system here has an extensive list of local addresses that could not have
signed up to receive email.  Sending to one of them gets the connecting IP
banned for at least 1440 minutes (with escalations to 2^14 minutes) of refused
connections on any port the server listens to.

Some of these began receiving mail within hours of the domain showing an MX
record, when it was established 27 years back.

I had paid little attention to the volume of spam from @gmail accounts,
through the Google system until a long-time co-conspirator began sending me ND
notices he had gotten for stuff he sent me from his gmail account.  We whack
at least one per day, at the moment; judging by the recidivism rate, it's
likely that a major part of their farm would be in the 
> 530 4.7.0 Connection refused 
territory.

Imagine if everybody did this.


>Just my 2 cents.

And raise you 1.

mdr
-- 
   Sometimes half-ass is exactly the right amount of ass.
   -- Wonderella

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] getting unblocked at outlook?

[Michael Rathbun via mailop]

On Thu, 11 Jul 2024 16:42:55 -0400, Bill Cole via mailop 
wrote:

>As far as I've ever been able to tell, S3150 means "Our Pseudo-AI thinks 
>you stink!" and the way out is to find the link on that page for senders 
>with  problems, jump through the hoops, respond to any requests for 
>info, and eventually get a reply from "Hotmail Sender Support" using the 
>magic phrase "not eligible for mitigation."  This incantation does not 
>mean what it seems. It is actually a signal that you have reached the 
>point where you can get a solution (usually?) by replying with the magic 
>phrase "PLEASE ESCALATE THIS TO SOMEONE WHO CAN ACTUALLY ASSIST ME" 
>which may or may not need to be in all caps.

This essentially represents my understanding of the net effect of the systems
being build when I worked there.

>This may sound like I'm joking, but I am not. 

This is sound reverse-engineering.

>   No one has ever claimed 
>to have an explanation for why a S3150 blockage happens or what exactly 
>the 'mitigation' consists of.

Not that I have seen.  You might need a GUTS clearance to find out.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Domains discrimination

[Michael Rathbun via mailop]

On Wed, 10 Jul 2024 12:15:41 -0700, Brandon Long via mailop
 wrote:

>Better case would be to automatically discover that a TLD is bad but also
>provide for the possibility that a given domain in the TLD is fine using a
>reputation based system.

Fortunately, the volume here (a few hundred a day) is low enough that I can
perform this personally.  

>And having enough traffic to be able to learn and a way for some mail to
>get through so that you can learn the "good" domains.

In the case of TLDs like .top and .xyz, the traffic is, by local standards,
profuse.

>Anyways, if your traders don't get the email updates from abc.xyz because
>you blocked the entire TLD, they'll probably get annoyed... and if enough
>money was involved, you may
>lose your job.  Which is to say, how you handle these things have more to
>do with the level of effort you're willing to put in for the payoff and
>what your customers require.

Heh.  The only one who can fire me is me (although a mob of enraged users
might be prejudicial).  My customers require that the amount of electronic
used food in their mail client be brought to a minimum, consistent with not
rendering their account even slightly nugatory.

>As a sender, you may want to avoid these instead of trying to work around
>the implicit penalty.

In this case, my role is as receiving administrator.  In my other role, giving
advice to senders, I promote avoiding exotic TLDs.  Since the average punter
never sees the (claimed) TLD of the sender in their mail client, any supposed
advantage is a matter of folklore.

mdr

-- 
   Sometimes half-ass is exactly the right amount of ass.
   -- Wonderella

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Domains discrimination

[Michael Rathbun via mailop]

On Thu, 11 Jul 2024 03:10:45 +0800, Jeff Pang via mailop 
wrote:

>Where can I see this statistics or similar reports? Thank you.

I don't plan on publishing mine, for what I hope are apparent reasons.  

I have a library of scripts that grep logs and draw conclusions.

mdr

-- 
I regret that I have but one * for my country.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Domains discrimination

[Michael Rathbun via mailop]

On Thu, 11 Jul 2024 02:44:50 +0800, Jeff Pang via mailop 
wrote:

>Is there domain name discrimination in the email industry? For example, 
>com, net, and org are considered to have higher reputations, while info, 
>xyz, and top are considered to have lower ratings. The latter do attract 
>a lot of spam because they are cheaper in the first year. Will this 
>lower the ratings of these domain names?

Sometimes, if you happen to note that 97.6% of ".xyz" traffic is spam, you
hear a "sproing!" that tells you that you can cut your overall costs by
sending those items to the gravel pit with a "22 out of 7.5" spam rating.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT&T Block

[Michael Rathbun via mailop]

On Mon, 8 Jul 2024 20:24:28 -0500, Scott Mutter via mailop 
wrote:

>I do suspect that John Von Essen's opinion has some merit.  I wish this
>information was posted on a trusted third party website.  Something to
>point customers to when they complain about being unable to send mail to @
>att.net email addresses.  There's no telling what email those same @att.net
>users are not getting.

Actually, the important party that's being entirely left out of this
discussion, the end user, is the one who needs the information.  A couple of
my clients have put notices on their sign-up forms, notifying persons with the
following email providers ... that they may not receive acknowledgements,
notifications, receipts, or other communications simply because the provider
they have selected cannot afford to exercise due diligence in their email
blocking.

A symmetrically opposite problem is when, e.g., Gmail users complain to me
that their recent mail was returned to them by Google, showing a

> 530 4.7.0 Connection refused 

response when the message delivery was attempted.

I have to respond that Google allows users to send between 20 and 40 messages
per week to "sudden death" spamtraps at this tiny domain, each of which will
cause the sending IP address to be banned for at least 24 hours.  Eventually,
a significant percentage of Google's outbound server farm is in the dog house.
They need to select a different provider.  Nobody is "too big to block".  My
users know this up front.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT&T Block

[Michael Rathbun via mailop]

On Mon, 8 Jul 2024 12:27:10 -0600, "Anne P. Mitchell, Esq. via mailop"
 wrote:

>A thing to remember is that after Harris filed the lawsuit they had a change 
>of management, and Harris approached us and actually asked for help in 
>reforming their mailing practices (and then did so), and so they dropped the 
>lawsuit.  For a while they were the poster child for doing it right as a 
>result of that.  So, in fact, they were the only lawsuit that didn't go to 
>trial. 

Indeed, it worked as designed.

Nice t-shirt, tho.  One of the few I can wear inside-in.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT&T Block

[Michael Rathbun via mailop]

On Mon, 8 Jul 2024 11:31:45 -0600, "Anne P. Mitchell, Esq. via mailop"
 wrote:

>Just a point of order (that's not quite the right term but you get the gist):
>
>> As you say there is nothing to stop a large operator from blocking a small 
>> operator simply because they can. 
>
>I'm not sure where the OP is from, but this has actually been litigated and is 
>settled law in the U.S. and has been for more than 20 years. In fact "my 
>server, my rules" is enshrined in our Federal law (of course not so succinctly 
>or in nearly as straightforward a manner).

And, I just recently found my "MAPS DEFENSE TEAM" t-shirt from an episode that
helped baked this into the crust.

(One of life's lovely moments came when I discovered that one of my
deliverability support clients at my new employer was Nielsen, who had
acquired Harris Polls a while back (the spammers who sued MAPS).  Nobody there
had a clue about what had happened in that episode, and their anti-spam,
anti-fraud measures were so thorough that my innocent attempts to open a seed
account to test their countermeasures were repulsed so strongly that I found
myself permanently barred from ever applying to be a reviewer/poll
respondent.)

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Yahoo Delays

[Michael Rathbun via mailop]

On Fri, 21 Jun 2024 13:46:27 -0400, Lili Crowley via mailop
 wrote:

>Things should be improving but it will take time for the queues to calm down

That was prophetic.  When I first read this, there was nothing in my Y! mail.
Eleven minutes later, 21 new pieces in the Spam folder...

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] t-online.de spam

[Michael Rathbun via mailop]

On Tue, 18 Jun 2024 11:33:48 -0700, Michael Peddemors via mailop
 wrote:

>Just an FYI, the list admin's prefer NOT to have the list used for 
>reporting spam.. It's okay to report generic trends, or 
>misconfigurations, or visibility into something new.. (And of course, 
>you are welcome to provide evidence of that.. ) but the list can quickly 
>get consumed if every spam was reported..

Aye.  I don't need more copies of spam I've already received (or which my
users have reported).  Perhaps a Public Shaming is intended, but public
shaming doesn't appear to be one of the published purposes of the list.

I, by myself, could multiply the volume on this list by at least ten if I only
reported a fraction of the hostile attempts to use the mail service I provide.
Lemme tell you about that new spam gang that is infesting Salesforce, for
instance.  They have forge-subscribed me to over sixty of their "brands" in
the past two months, and I now get around sixty pieces per day, and climbing.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What is Yahoo TSS09 ?

[Michael Rathbun via mailop]

On 6 May 2024 23:47:20 -0400, John R Levine via mailop 
wrote:

>> Any suggestions?
>
>To answer the obvious questions, it all has DKIM signatures and the SPF is 
>updated, so it ain't that.


My suspicions point in the direction of a seldom-updated file of invalid
routes, or some such.  Specifically, whob tells us:

>Origin-AS: 23086
>Prefix: 192.55.226.0/24
>AS-Path: 293 6939 7843 11351 23086
>AS-Org-Name: Pound Bang Incorporated
[snip]
>Route-Originated-Date: May 04 2024 13:42:56
>Route-Originated-TS: 1714830176

We had something like that at MSFT when I worked there.  Serious PITA on some
occasions.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] is warming IPs still necessary?

[Michael Rathbun via mailop]

On Mon, 25 Mar 2024 15:58:33 -0700, Gerald Oskoboiny via mailop
 wrote:

>Is it still necessary to warm up new IP addresses gradually 
>instead of going directly to this volume of deliveries? My 
>impression is that it's less and less necessary in the age of 
>DMARC, SPF and DKIM.

The rule that governs many of the dynamic IP reputation systems that I am
familiar with is:  "Don't give us any surprises."

When I was a spam analyst at MSFT in a previous geologic era, we had a guy who
would build out a new Eonix /24, send test messages to seed accounts until he
decided that he had found ways around the rules that killed the tail end of
yesterday's blast, made his changes, backed his truck up to our network and
dumped between five and fifteen million messages over a period of about half
to three quarters of an hour.

At that time, we had nothing technical implemented that would handle this, so
it worked quite well.  Eventually, we were able to convince people who did the
engineering at the border to consider the "No Surprises" rule.

One of my clients, without consulting aforehand, apparently decided that he
really needed to do a 10X augmentation to his daily volume.  Before the
inevitable algorithmic corrections based on the ghastly volume of spam
notifications, the border logic at several major providers moved his IP
reputations from Good or OK to reject, with sampling.  Overall, his border
rejection rate went from 1.45% (not great, but not yet a policy enforcement
matter) to 55.6% (yes, this is a policy enforcement matter).

The sudden onslaught you propose may actually succeed in the main, and after a
couple weeks of zero-complaint/excellent-open stats you will be back in good
graces overall, it might be well to look at a week-long cutover transition, if
the technology permits.

mdr
-- 
  Ad finem pugnabo.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debt Collection Client Email Servers

[Michael Rathbun via mailop]

On Mon, 25 Mar 2024 23:21:51 +, Matt Palmer via mailop 
wrote:

>That's some mighty early adoption you've got there.

Yeah.  I'm gonna have my cataract surgery in a couple weeks.  Meanwhile, the
correct number is 1996.

Fytu, &c.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Debt Collection Client Email Servers

[Michael Rathbun via mailop]

On Mon, 25 Mar 2024 15:47:11 +, Michael Irvine via mailop
 wrote:

>I can't say the specific lenders, but I can say that it is not just bank and 
>money lending. We have clients who are from the courts and other 3rd parties 
>that do not fully validate the email that is given to them. We still must take 
>it as there are no good ways to get the correct known email for a person. When 
>we started, we worked to clean up the list and asked them to pass along to the 
>3rd party that we need the list to be better cleaned as there were many bad 
>emails (I have seen many bad and incorrect emails listed). We also have setup 
>the blacklist for those emails that have been sent, but failed due to 
>non-existent mailbox, full mailbox, etc. 
>
>The problem I am trying to fix is that these are legal emails and I need a way 
>to signal that to the providers. With many states and USA government stating 
>that email is a legal form of communication, how can we guarantee it to the 
>inbox if many of the users mark it as SPAM and potentially blocks other 
>communication. 

If such a mechanism were put in place, it would be inevitable that soon EVERY
spam would bear the marks of "this is a government-mandated legal document
which MUST be delivered".  

From the UK, I regularly receive legal notices, trial summaries, updates from
various government offices...  at an account that I established at Yahoo! in
1986 and have never used to communicate with foreign governments.

Even if some legal authority somewhere declares that email is required to be a
completely reliable communication channel with legally mandated delivery
requirements, email will be unchanged:  it is a medium in which your message
may be delivered, unless it isn't, in which case it won't be.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SpamHaus listings

[Michael Rathbun via mailop]

On Fri, 22 Mar 2024 18:55:19 -0600, Richard W via mailop 
wrote:

>I don't participate in guessing games. Too old and grumpy for that.  I 
>just move on.

Thus my own lack of further engagement.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SpamHaus listings

[Michael Rathbun via mailop]

On Thu, 21 Mar 2024 18:40:16 +0100, Matus UHLAR - fantomas via mailop
 wrote:

>Are there any other checks or measures I can do?

What exactly is the Zen result code?  There are many reasons for such
listings.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone from Microsoft?

[Michael Rathbun via mailop]

On Tue, 5 Mar 2024 14:59:09 -0800, Mark Fletcher via mailop
 wrote:

>Is there somewhere else I should be looking?

You might wish to consider omphaloskepsis.  The chances of a useful outcome
will be closely similar.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bounces at cox.net (AUP#CXSNDR)

[Michael Rathbun via mailop]

On Wed, 28 Feb 2024 14:04:07 +, Simplelists - Andy Beverley via mailop
 wrote:

>Hi all,
>
>Has anyone seen an uptick in bounces in the last day or so to cox.net?

Looking at consolidated statistics for all our hosted senders, 1,034,662 new
messages in past 72 hours, 6,151 (0.52%) failed.

Looks like the problem may be on your end.

mdr
-- 
  Ad finem pugnabo.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Contact of postmaster for hostedemail.com domains

[Michael Rathbun via mailop]

On Mon, 26 Feb 2024 17:22:27 + (GMT), Andrew C Aitchison via mailop
 wrote:

>If nobody complains,
>then a single complaint is likely to get attention :-)

In my corporate experience, if nobody complains, then there will be nobody to
read complaints.   Simple cost containment.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase in outlook.com S3150 rejections

[Michael Rathbun via mailop]

On Mon, 19 Feb 2024 11:15:44 -0300, Fernando MM via mailop 
wrote:

>Hi,
>
>Over the past two weeks, I started to notice an increase in the number of
>S3150 rejections. 

A significant percentage of my clients are seeing complete blockage at those
domains.   At the moment the best we can offer is "don't send to those domains
any more." as remediation attempts appear to be futile.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

[Michael Rathbun via mailop]

On Fri, 16 Feb 2024 12:33:21 -0800, Robert L Mathews via mailop
 wrote:

>Interesting, thanks. I find I disagree with the "full stop" part, but it seems 
>I'm in the minority.

Perhaps.  I take Google for an example.  Fossicking through the logs here, I
find...

>> cidrsearch *all /nonu /ru=google.cid   | search screening
> Fri 2024-02-09 05:05:03.170: SMTP screening added 209.85.216.52; sender 
> triggered a spam honeypot
> Fri 2024-02-09 05:06:13.206: SMTP screening added 209.85.214.175; sender 
> triggered a spam honeypot
> Fri 2024-02-09 10:42:24.109: Dynamic screening refused connection to 
> 192.168.1.2:25 from 209.85.216.52; 1104 minutes remain
> Sat 2024-02-10 09:53:13.686: SMTP screening added 209.85.208.169; sender 
> triggered a spam honeypot
> Thu 2024-02-15 13:33:20.263: SMTP screening added 209.85.218.66; sender 
> triggered a spam honeypot
> Thu 2024-02-15 23:11:21.318: SMTP screening added 35.221.19.77; sender 
> triggered a spam honeypot

which tells us that Google has sent (or rather, has enabled to be sent) email
to "honeypots", which I designate as "sudden death spamtraps".  If you send to
one of these, your IP will be dropped into a list which will cause
>  530 4.7.0 Connection refused 
to be the response for 1 day, 3 days, 9 days, or 11 days, 9 hours, 4 minutes.

The "refused" connection was for the delivery of a message from an old friend
and current business partner.  He subsequently forwarded the DSN to me, with
the original message appended, I explained the business continuity risks of
using "free" email services that apparently have ineffective policy
enforcement (not to mention that we are discussing details of a product that
will, should it succeed, seriously challenge Google in one of its areas of
interest, especially since I know with certainty that their system reads every
message you send or receive).

If you are sending email to "nadine @ honet.com" or to some guy in Switzerland
who signed up at dozens of porno sites using a honet.com user ID well before
honet.com was registered (1997), you are NOT a legitimate sender of email.

Full stop

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP
  

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else noticing an increase in spam from Office365 distribution lists?

[Michael Rathbun via mailop]

On Wed, 17 Jan 2024 15:35:42 +0100, Hans-Martin Mosner via mailop
 wrote:

>Am 17.01.24 um 15:20 schrieb Paul Menzel via mailop:
>> With this in mind, did somebody compile a block list yet? Or should I just 
>> create a whitelist? 
>
>A block list does not make sense, as new domains are added continuously. It's 
>just too simple.

I have noticed the predominance of "x.onmicrosoft.com" domains in the spam
sump here.  In many cases, the envelope from and the "friendly" from contain
different x- domains, and these rotate rapidly.  They are either created
algorithmically, or by persons diddling their fingers on a keyboard.

Twelve years back, when I was on the team that theoretically combated
electronic used food both entering and exiting the Office 365 system, we saw
the same evolving set of tricks that some of us had encountered back in the
Dialup Epoch.  I wrote the front end for a lights-out dialup account creation
and provisioning system, and before long the volume of code designed to
prevent new accounts far exceeded that devoted to establishing new accounts.
After the Company changed hands, this focus was removed from the system that
replaced mine.

All of this is to say, you must have an active rather than reactive response
to hostile usage of your system, whether there is definite and immediate
revenue loss, or not.  

My diagnosis of MSFT's problem in doing anything effective is that the
fundamental model of the service does not entertain the notion of a strong
focus on being a constructive member of the net.community.  I don't know the
current situation, but our quest to discover who actually reads and acts upon
messages to postmas...@microsoft.com or ab...@microsoft.com eventually
returned the answer "nobody, really".  

mdr
-- 
  Ad finem pugnabo.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mimecast - Increased greylisting/rate-limiting

[Michael Rathbun via mailop]

On Thu, 7 Dec 2023 17:35:38 +0200, Stephan Fourie via mailop
 wrote:

>Anyone else seeing the same issue? Or, can offer some advice?

A large number of the clients I monitor daily are seeing this regularly.  The
mail eventually goes through.  

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Historical spam loads - was Re: Google rate-limiting more aggressively than usual?

[Michael Rathbun via mailop]

On Sun, 19 Nov 2023 19:02:04 + (GMT), Andrew C Aitchison via mailop
 wrote:

>That is a surprise to hear. Reading this list has given me the impression
>that the spam volume is worse now than it was then. Spamming is a much bigger
>business now and the internet is faster, so I would have thought spammers
>would be sending more messages, even compared to the increase in legitimate
>email.

"Better" can be an elastic concept.

On the one hand, from the script that ran this morning, I see that only 4.2%
of the SMTP dialogs registered in the logs qualified as "not hostile".  These
were communications that were consensual -- multicast from lists like this
one, broadcasts from sources that users had given permission to, and various
unicast messages from sources known and unknown.

The rest were relay attempts, false authorization attempts (often laughably
inept), messages to "sudden death" spamtraps, messages to "Nadine" and all of
the contact addresses that briefly appeared on http://www.honet.com/Nadine,
and a vast array of spammed addresses both valid and never valid.  A
significant percentage of these offenders are immediately identified by the
Spamhaus advisory lists, and other such public services.  There were also the
usual attempts to wake up resident malware.

>If they are sending comparatively fewer messages I can only imagine
>that is because their strike rate is better, which is *more* worrying.
>What have I misunderstood ?

Compared to what we were trying to deal with back in, say, 1997, the volume of
unsolicited broadcast email has gone up by several orders of magnitude. Simply
based on raw volume numbers, the spammers won the war over a decade ago.  From
the standpoint of my users, things are much as they were back around 2005 --
volumes up, detection and suppression also up commensurately.

>> but I wouldn't be at all surprised if some sites still have a 90%+
>> spam burden.

Much of the current evolution of intake evaluation strategies is governed by
the numbers describing what percentage of a major provider's resources are
consumed by messages that nobody will ever see, but which must be evaluated,
tested, examined, classified, and eventually stored/delivered to an account
that is never accessed.  

Expect upheavals for some cohorts of mail senders.

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Legit-looking mail to the wrong address with no unsubscribe

[Michael Rathbun via mailop]

On Thu, 24 Aug 2023 11:30:19 -0600, Anne Mitchell via mailop
 wrote:

>Well, and also *confirming* the email address to start with.

Let's think about Heather, a mother of three in eastern Kansas, who signed up
a while ago for real estate topics, presumably at a co-reg site of some sort.

Cometh now some e-penders, who have the co-reg database with ALL of the
personal information that Heather gave the site, but somehow managed to
associate my email address with that specific datawad:  Now I get all of the
stuff that the e-penders' customers have in store for Heather, about real
estate and many unrelated topics.  To prove their bona fides, they often
include personal detail morsels from that datawad.

As a result, over the years, I have Heather's full name, date of birth,
physical address, driver license facsimile, photographs of her home and her
family's two vehicles, the names and ages of her children, and the names and
locations of the schools they attend.

"Heather", like "Nadine", is not her real name, for obvious reasons.

>Because not doing so, (oh gosh *especially* for delivery services!) can lead 
>to very bad outcomes, and even liability for the sender!

Imagine that.  There are times when my opposition to the death penalty suffers
challenges.

At least I get to cancel healthcare service accounts, Amazon accounts,
insurance policies, and for others, to change their forgotten password to
%Disabled0.   Then trash all of the desperate password recovery emails; I
couldn't wise up the victim no matter how intense my desire might be, since
for their privacy all personal details have been elided.  

Just like CitiBank sending me ALL account update mails for a certain MD Rahman
somewhere in New York.  FOR YEARS.  And refusing to do ANYTHING about 
that -- I can't validate myself as the account holder, so it is utterly
impossible to change the contact email address.  Call back when I have MD
Rahman's DOB and SSAN, thanks for being a loyal Citi customer.  ("But... but I
can tell you the current balance on the accouts, and the last five deposits
and withdrawals to each of them (his financial situation has improved -- he
now has balances north of $40K, when he used to get lots of overdraft 
notices -- Yay, MD!), and the name of the person MD talked to the last time he
visited his local branch!")

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Charter/Spectrum contact

[Michael Rathbun via mailop]

On Tue, 25 Jul 2023 17:47:56 -0400, "John Stoffel"  wrote:

>
>I'd love to be contacted as well, since my VPS is black listed and I
>can't get email into my own personal @charter.net account from my own
>mail server.  Sigh...

Based on my experience so far today, I expect that you will already have heard
from the individual, who reads the group but chooses not to participate
directly.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Charter/Spectrum contact

[Michael Rathbun via mailop]

On Tue, 25 Jul 2023 18:10:50 +, Brian Kowalewicz via mailop
 wrote:

>Hi,
>
>For the record, someone did reach out. I’ll try and put you in contact.

I've been contacted.  Thanks, all.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Charter/Spectrum contact

[Michael Rathbun via mailop]

Hello,

Did you get a reply?  We're seeing some strange (reported) concurrent
connection issues with customers who never make more than one concurrent
connection, but when this condition is absent otherwise have a single-digit
per 10,000 messages refusal rate.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire


On Tue, 27 Sep 2022 17:49:39 +, Brian Kowalewicz via mailop
 wrote:

>
>Hi,
>
>Looking for a Charter contact to look at some apparent concurrent connection 
>issues.
>
>Thank you!
>
>Brian Kowalewicz
>bkowalew...@duckduckgo.com

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Michael Rathbun via mailop]

On 9 Jul 2023 22:07:38 -0400, John Levine via mailop 
wrote:

>In fact it's for people but you never know what some people will do.
>Don't start by letting your chatty user send "here's my new address"
>to all 10,000 people in his address book.

Ah.  Somebody doing that on my server would get an automated but polite notice
that we need to have a discussion of domain policy and expected behavior
before any more email could go out.  Good fences, good neighbors, &c.

mdr
-- 
   We are all temps.
  -- Daisy Adair

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Michael Rathbun via mailop]

On 9 Jul 2023 18:39:22 -0400, John Levine via mailop 
wrote:

>= start slow and look at any bounces

This implies to me that this will be a broadcast server rather than mailboxes
for individuals and businesses.  If so, there are some paragraphs that might
need to be added, especially about list hygiene.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Seeking Synacor / Zimbra contact

[Michael Rathbun via mailop]

We (GreenArrow Email) are having a bit of false-positive problems with the
spam filtering system that appears to be part of this product.  A couple of
our hosted senders only get complaints when their mail _doesn't_ arrive.  

When those complaints arrive, they open a ticket with us.  We'd like to find a
resolution.

Thanks,

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid is deleting your mail

[Michael Rathbun via mailop]

On Sun, 25 Jun 2023 14:28:33 +0100, Dmytro Homoniuk via mailop
 wrote:

>*In a very non-confrontational way* I want to express my opinion and to
>note that's pretty much how senders operate right now: too often the smtp
>code and enhanced code the recipient system returns have nothing to do with
>what the response text says - and every mailbox provider uses their own
>flavor to boot.

My favourite is a particular immense mailbox provider that is known to issue a
4xx code with text that basically says "This is a permanent temporary failure;
retries will never succeed."

Looking for design intent in this phenomenon, one possible objective
immediately comes to mind:

If you consider the sender to be hostile, issue permanent tempfails so that,
if the sender has used a default (long) queue expiration time in their sending
software, one can keep a full day or more of re-queued messages on the
sender's system, perhaps blowing out the system's disk space, and causing
other sending performance issues that reduce the spammer's ability to spam. I
have seen these effects in more than one system in the wild.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Strange mail delivery from microsoft

[Michael Rathbun via mailop]

On Tue, 20 Jun 2023 10:26:22 -0400, Bill Cole via mailop 
wrote:

>> That is absolutely ignorant to tell the people that you do mail in a
>> broken way and tell them it is for a reason, you don't want to tell.
>
>Sharing an outbound queue amongst many different machines is not 
>"broken" in any way. There may or may not be rock-solid simple 
>explanations for *WHY* that approach was chosen, but it is entirely a 
>local issue of purely local concern. There is no RFC asserting that 
>retries after a transient rejection should come from the same cliuent 
>IP.

One rock-solid simple explanation is that, for a multi-IP sending instance,
random IP selection in the routing rule delivers more reliably than binding a
particular message to the VMTA that first attempted to send it.  Sometimes
quirky things happen, and we will see that the customer delivers to Y! or
Hotmail et al. on three of their four IPs without incident, and sees zero
complaints and an open rate varying between 35% and 55%.  The remaining IP
enjoys complete blockage for $REASONS.

The brokenness is introduced by giving a false response at the first knock.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Strange mail delivery from microsoft

[Michael Rathbun via mailop]

On Mon, 19 Jun 2023 20:55:19 +, Michael Wise via mailop
 wrote:

>If you're using GreyListing, know that a given email will not be coming from 
>the same IP address twice.
>
>The outgoing IP address is randomized for ... reasons.

Most of our customers will look the same.  We don't got to show you no
stinkin'reasons.  Although, depending upon the number of IPs, and the requeue
backoff, it might happen more than once.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive botnet going off today?

[Michael Rathbun via mailop]

On Mon, 15 May 2023 17:31:47 +, Slavko via mailop 
wrote:

>Don't worry, you are not alone, ~3000 of them is already in my
>MSA's firewall due AUTH attempts.

On average, between 3,000 and 5,000 connection attempts occur per day, at my
tiny and shrinking (down to four active users).  After all of the auth
attempts are discarded, per day an average of 1993 SMTP sessions are
established, resulting in 416 messages received.  

Of those messages, 114 are to "sudden death" spamtraps, and are delivered only
to Rev Bayes's filtering system;

16 will be to "Nadine", and will be automatically forwarded to interested
blocklists;

Of the remaining 286 average messages per day, about 55 will not be marked as
spam by the filtering system.

55 possibly valid email messages delivered represents about 2% of the total
SMTP activity, on a per-session basis.  As a percentage of total network
activity involving TCP connections to the server, we se slightly less than
0.11% of all of that is actually useful.

Imagine what that's like if you are one of the big mailbos providers.  Spam
and other hostile activity must eat at least 90% of your expense budget.

mdr
-- 
 alt.metaphorical.dude.abides.abides.abides
 -- Chucky

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Official traffic shaping rule sources?

[Michael Rathbun via mailop]

On Mon, 8 May 2023 13:29:48 +, Mike Hillyer via mailop 
wrote:

>Thanks, these are good best practices but I was talking more about "10 
>connections max per IP, 5 messages per connection" type of traffic shaping 
>rules.

I should mention that our systems (GreenArrow) normally offer 1 message per
SMTP session, for various practical reasons, although some of our customers
have configured their systems for other values than one.  As a deliverability
dude as well as an administrator of a small receiving system, I normally urge
1 message per session.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Official traffic shaping rule sources?

[Michael Rathbun via mailop]

On Mon, 8 May 2023 13:29:48 +, Mike Hillyer via mailop 
wrote:

>Thanks, these are good best practices but I was talking more about "10 
>connections max per IP, 5 messages per connection" type of traffic shaping 
>rules.

Sorry, I didn't make the end point clear.  If you follow the warm-up plan, for
the major providers, if your list hygiene is effective and your recipients are
responsive, the rule is "one connection per 1000/hr", i.e. whatever the
traffic will bear.  A client whose performance I reviewed this morning
normally does about 50,000 per hour per IP at gmail.  Then again, his failure
rate is 0.08% and the averge open rate hovers around 44%.  The time per
transaction is usually pretty low at gmail, and the "1 connection per 10K" can
be reduced.  These will be dependent upon your processor's capacity and your
network connection.

The ones you need details for would be the smaller European and Asian domains,
which tend to be a lot more picky about simultaneous connections and rate
limits.  Many of those will be detailed on the Postmaster web pages, but often
not in English.  There are some smaller US providers who also get stroppy
about too many connections; finding out what those limits are is often best
done empirically.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Official traffic shaping rule sources?

[Michael Rathbun via mailop]

On Fri, 5 May 2023 13:39:03 +, Mike Hillyer via mailop 
wrote:

>I have a number of samples of various community-sourced traffic-shaping rules, 
>but does anyone know of any official posts where the desired traffic-shaping 
>behavior is listed for the larger MBPs?

They nearly all have "postmaster" pages with various requirements.  In my
experience, and that of my clients, there are a few basic rules that encompass
what those pages say, with some practical augmentations.  Roughly:

1.  Begin with your most engaged and responsive customers.  If they have not
subscribed, opened or clicked in the last 90 days, suppress them.

2.  Do not do anything surprising.  As you ramp up, do not increase the total
volume, the delivery rate per hour, and the number of simultaneous connections
by more than 50%.  

3.  Begin with about 20,000 pieces per IP per day, with not more than 25% of
the total going to any specific provider system.  Set the initial injection
rate to be such that the whole campaign takes about four hours.  Adjust the
domain-based throttles to 1,000/hour with not more than five simultaneous
connections.

4.  Pay close attention to deferrals, especially from Google and the Y!
complex.  If you see "Account over quota" or "account disabled" responses,
look into how your segmentation has failed to weed out non-responders, spam
traps and stale/abandoned accounts.

Sending to smaller systems, especially ones in .it, .fr, and .de may require a
much softer start, e.g. with simultaneous connections limited to one or two,
and delivery rates under 500/hr in some cases.

mdr
-- 
  Oh, when there’s too much of nothing
  No one has control.
 -- Bob Dylan

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ab...@microsoft.com => Mailbox full

[Michael Rathbun via mailop]

On Thu, 20 Apr 2023 14:25:41 -0500, Jarland Donnell via mailop
 wrote:

>I'm surprised they even have an abuse inbox. I just block spammy senders 
>from MS/O365 domains and let them deal with the reduced number of people 
>they can do business with, as the result of their choice to send spam.

As long as nobody at or above the reporting level that was Rajesh Jha a decade
back understands the issues and takes ownership, an abuse (policy enforcement,
actually) "department" will not exist, functionally.

Having built (or rebuilt) successful Policy Enforcement groups over time, I
was increasingly alarmed when I started working at MSFT as a Spam Analyst.  

Many years ago, Allegiance Telecom had acquired a highly competent abuse team,
but essentially defanged them.  It wasn't until the COO directly hired a
Policy Enforcement director, with the authority to disconnect customers with
up to US$50,000 monthly billing by simply dialing a 4-digit number, that the
network began to behave responsibly.  My job was basically to let my team do
their job, and keep the Mahoganites off their case.  Thus, they were in MD and
I was in Dallas, 3 floors down from C-ville.

MSFT has no path to such a solution.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ab...@microsoft.com => Mailbox full

[Michael Rathbun via mailop]

On Thu, 20 Apr 2023 15:32:18 +0200, Benoit Panizzon via mailop
 wrote:

...

>Delivery has failed to these recipients or groups:
>
>ab...@microsoft.com
>The recipient's mailbox is full and can't accept messages now. Please try 
>resending your message later, or contact the recipient directly.

Back when I worked in the O365 spam analysis process, I launched a crusade to
discover who, if anybody, actually reads abuse@microsoft.  The eventual result
was that there was a person who supposedly looked at it now and again.

[snip]

>Yes please, how can I contact the microsoft abuse desk more directly?

There wasn't one when I worked there.  Not from lack of trying to get one
launched.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Sendgrid abuse forwarding to Google - not one of your brightest ideas

[Michael Rathbun via mailop]

On Wed, 22 Mar 2023 10:01:53 +0100, Sebastian Nielsen via mailop
 wrote:

>A good idea when you get this type of response, just include the full 
>headersand not the actual body of message.A competent abuse department should 
>be able to fish out a verbatim copy of the message being reported in their 
>logging systems using the headers alone.

I only report to Sendgrid when one of their customers hits a "sudden death"
spamtrap, and then I simply send the log from the transaction.  I get a ticket
response, and later a survey request for my experiences, which I ignore.  I
also see zero repeat performances by that particular customer.

mdr
-- 
We must not confuse statistical probability with some transcendental
and utterly compelling force. 
  -- Unspiek, Baron Bodissey (Life, Volume II)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] vrfcanaclu03.rfcanalyzer.net / 2001:470:1f14:fa5::2 / tunnel613353-pt.tunnel.tserv11.ams1.ipv6.he.net

[Michael Rathbun via mailop]

On Sun, 12 Mar 2023 02:54:56 +0100, Tobias Fiebig via mailop
 wrote:

>So, has anyone else seen this in mail.logs/has an idea what that host
>is doing?

The connections here attempt STARTTLS, which fails with SSL error 0x80090331.

These come from 87.215.108.211 and .212, in .nl.  

This behaviour has been exhibited by a number of other hosts, mostly
originating from OVH netblocks geolocated in .fr.

mdr
-- 
  Ad finem pugnabo.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] *LIKELY SPAM 08.3* Re: New iteration of SMTP callback snakeoil

[Michael Rathbun via mailop]

On Sat, 11 Mar 2023 19:01:54 +0100, "Peter N. M. Hansteen via mailop"
 wrote:

>I hadn't noticed any of those, but then again the things that run automatically
>here are somewhat geared towards fishing out new candidates for spamtraps. 
>Those
>generated addresses have of course joined the list of imaginary friends now 
>some 308558 strong ;)

I only do that if the robot notices that such an address has been seen at
least three times.  I only have about 600 "sudden death" listings, but they
regularly continue to see hits until they are retired for some reasons.  Some
visualizations of the data resemble the pattern of combustion in fine steel
wool.

>I'll probably need to sniff around the various logs for further data.

I certainly find it a compelling activity.  Some hostile connection events are
correlated in unexpected ways.

mdr
-- 
   The System tends to oppose its own proper function.
-- Systemantics

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New iteration of SMTP callback snakeoil

[Michael Rathbun via mailop]

On Sat, 11 Mar 2023 12:57:11 +0100, "Peter N. M. Hansteen via mailop"
 wrote:

>Hi,
>
>Since some time yesterday I've seen a largish number of delivery attempts to
>obviously generated, invalid addesses in some of our domains, with the 
>following
>apparent senders:

>information@validmbx .com

I note with interest that the above domain suddenly is listed in URI BLs.  At
least new messages mentioning that domain get flagged as spam for that reason.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New iteration of SMTP callback snakeoil

[Michael Rathbun via mailop]

On Sat, 11 Mar 2023 12:57:11 +0100, "Peter N. M. Hansteen via mailop"
 wrote:

>Hi,
>
>Since some time yesterday I've seen a largish number of delivery attempts to
>obviously generated, invalid addesses in some of our domains, with the 
>following
>apparent senders:
>
>informat...@ckuser.com

[snip]

Looking for "RCPT TO:https://list.mailop.org/listinfo/mailop

Re: [mailop] New iteration of SMTP callback snakeoil

[Michael Rathbun via mailop]

On Sat, 11 Mar 2023 12:57:11 +0100, "Peter N. M. Hansteen via mailop"
 wrote:

>Hi,
>
>Since some time yesterday I've seen a largish number of delivery attempts to
>obviously generated, invalid addesses in some of our domains, with the 
>following
>apparent senders:
[snip]
>informat...@validmbx.com
[snip]

The most recent validmbx.com attempt failed the generated address as expected,
then validated one of my "sudden death" spamtrap addresses.  So, the sender is
welcome to saturate that addy with spam, since each delivering IP will be
blocked for at least 1,440 minutes, and the messages delivered only to 
Rev. Bayes.

I would point out that there appears to be a large number of such attempts
that don't use information@ as the envelope from.

mdr
-- 
   Sometimes half-ass is exactly the right amount of ass.
   -- Wonderella

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] warming up IPs, Microsoft?

[Michael Rathbun via mailop]

On Mon, 6 Mar 2023 10:52:35 +, Laura Atkins via mailop 
wrote:

>I have had a number of clients over the last 3 or 4 years using SES without 
>any delivery problems that we could attribute to the IP addresses. Once we ran 
>through fixing the things under their control, delivery was great. 

I have a couple of recent (last two months) clients using SES who also saw no
problems, but then they had open rates that climbed to above 50% and complaint
rates close to the cube root of zero.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intuit directly spaming

[Michael Rathbun via mailop]

On Sun, 05 Mar 2023 21:48:46 +, Slavko via mailop 
wrote:

>This looks very nice, i installed and tried it, but i got no output,
>after quick check it uses  by default whois.pwhois.org, which
>returns NXDOMAIN. Please, which whois server are you using?

I appear to be using the default.  From here:

>mdr@LUSZ ~ $ host whois.pwhois.org
>whois.pwhois.org is an alias for global.pwhois.org.
>global.pwhois.org has address 208.74.248.120
>global.pwhois.org has IPv6 address 2620:d1:4000:2::100

Not sure what to offer in that regard.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Intuit directly spaming

[Michael Rathbun via mailop]

On Sat, 04 Mar 2023 22:58:23 +, MRob via mailop  wrote:

>Thanks you Atro, is there popular tool for to do that in real time?

This works for me:

>mdr@LUSZ ~ $ whois AS11377
>% IANA WHOIS server
>% for more information on IANA, visit http://www.iana.org
>% This query returned 1 object
>
>refer:whois.arin.net
>
>as-block: 10240-12287
>organisation: Assigned by ARIN
>
>whois:whois.arin.net
>descr:Assigned by ARIN
>
>source:   IANA
>
># whois.arin.net
>
>ASNumber:   11377
>ASName: SENDGRID
>ASHandle:   AS11377
>RegDate:2012-06-28
>Updated:2012-06-28
>Ref:https://rdap.arin.net/registry/autnum/11377
>
>
>OrgName:SendGrid, Inc.
[snip]

Then there's stuff like

>mdr@LUSZ ~ $ whob 167.89.99.112
>IP: 167.89.99.112
>Origin-AS: 11377
>Prefix: 167.89.96.0/20
>AS-Path: 293 3356 11377
>AS-Org-Name: SendGrid, Inc.
>Org-Name: SendGrid, Inc.
>Net-Name: SENDGRID-167-89-0-0-17
>Cache-Date: Mar 05 2023 07:26:18
>Latitude: 39.749838
>Longitude: -104.995597
>City: Denver
>Region: Colorado
>Country: United States of America
>Country-Code: US
>Route-Originated-Date: Feb 16 2023 23:12:01
>Route-Originated-TS: 1676589121

mdr
-- 
  Where there is no law, but every man
   does what is right in his own eyes,
there is the least of real liberty.
  -- HENRY M. ROBERT

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail blocking of good customer

[Michael Rathbun via mailop]

On Sun, 26 Feb 2023 10:34:11 +, Laura Atkins via mailop
 wrote:

>If people intend to be interoperable, there is NO variation in what a 4xx and 
>a 5xx mean.
>
>4xx means: this message can be queued and retried at a future date.
>
>5xx means: this message cannot be retried without human intervention.
>
>Those interactions are defined in RFC 821 and it’s successors. [1]
>
>The variation / confusion / problems / conflict comes when we try and use 
>these very clear *transactional* signals to interpret what to do with a 
>different and future message to the same address. 
>

Then there's the Y! "4xx -- deferred, but retrying anything from this IP will
never succeed" message.  I speculate that this is in place to encourage the
spamming system to retain the messages to help blow out its queue space and
slow things down considerably.  Think of it as implicit rate limiting, while
increasing the senders' costs.

mdr
-- 
  If I laugh when a guy goes flying on a banana peel, is that a
  schadenfreudian slip?
   -- Zippy

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What is the canonical path around Microsoft S3150 breakage?

[Michael Rathbun via mailop]

On Tue, 08 Nov 2022 11:46:20 -0500, Bill Cole via mailop 
wrote:

>Meanwhile, my boss tried working another route and has opened 2 tickets: 
>SRX1544040988ID asking for just the one IP and SRX1544076120ID for the whole 
>/24. Got the dreaded "Not qualified for mitigation" boilerplate response to 
>both.

Replying to the "not qual" note simply moves you from talking to a robot to
talking to a contractor in India.  This has eventually worked out for me, in
the past, both from the inside and the outside.


>What is the way out of this? It feels a lot like intentional anticompetitive 
>behavior, but I'm paranoid.

Even they know how difficult that could become for all concerned.

mdr
-- 
  Ad finem pugnabo.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Michael Rathbun via mailop]

On Thu, 20 Oct 2022 20:47:40 +0200 (CEST), Bernardo Reino via mailop
 wrote:

>However, I still find that Postel's law should apply, in any context, and 
>specifically in this one. You want to run an e-mail server and don't want to 
>be 
>blocked, so you should (liberally) accept, instead of "being like them" and 
>block unfairly (for some definition of fairness anyway).
>
>After all, this is what we (should) teach our kids, so I'm a bit surprised 
>that 
>some people are proposing (or have already implemented) doing the 
>eye-for-an-eye 
>(or was it a tooth?) to T-Online.
>
>*We* can do better, and we should do better ;-)

Another rule from an earlier era outlines one of the fundamental principles of
the Internet Agreement:  I will accept your traffic, subject to my policies
and agreements, if you will accept mine, subject to your policies and
agreements.

As noted in the .sig below, things don't entirely work in this world as they
are assumed to work in the other.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[Michael Rathbun via mailop]

On Mon, 12 Sep 2022 19:15:46 -0700, Dave Crocker via mailop
 wrote:

>-
>
>On 9/12/2022 7:01 PM, Al Iverson via mailop wrote:
>> Because I disagree with the whole premise
>> that self hosting mail is impossible today
[snip]
>I believe the prevailing sentiment is that it is a challenging task, 
>requiring significant expertise.

I was going to write something countering this sentiment, until it dawned on
me that there is only one person I know within 200 miles of me that I could
ask to facilitate my wife's email access after I'm no longer vertical, and am
not maintaining the email server.

Hmm.

mdr
-- 
  The world was almost won by such an ape!
The nations put him where his kind belong.
  But do not rejoice too soon at your escape.
The womb he crawled from is still going strong.
-- Bertold Brecht,"The Resistible Rise of Arturo UI"

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[Michael Rathbun via mailop]

On Mon, 12 Sep 2022 12:50:57 -0700, Brandon Long via mailop
 wrote:

>By their very nature, the personal servers that people are talking about
>here just don't see
>the same volume of spam.

Just about any spammed account will see a different collection of senders,
topics, &c.  My tiny self-hosted (the server hardware is less than a meter
from my left shoulder at the moment) email system has the "nadine" account and
a large pile of collector accounts that attract spam that is occasionally
interesting.  The "trymysloutions@gmail" spamgang has attracted some larger
players, finally.

Apart from some players like Renewal By Anderson and the hundreds of thousands
of "law" firms offering Camp Lejeune claimant services, with a couple of
prominent insurance firms thrownn in, my local, Google, Hotmail, Y!, AOL, and
other accounts get a widely divergent set of spams.  The market is nowhere
near saturated yet.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SMTP noise from *.bouncer.cloud

[Michael Rathbun via mailop]

On Mon, 5 Sep 2022 12:27:05 -0700, Jay Hennigan via mailop 
wrote:

>I assume that:
>- When I walk up to a bank teller wearing a mask

One of the irritating aspects of the unnecessary pandemic was that my very
favorite Jack Vance quote became awkwardly inoperative.

mdr
-- 
"Honest folk do not wear masks when they enter a bank."
   -- Unspiek, Baron Bodissey

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Forged subscriptions affecting GovDelivery

[Michael Rathbun via mailop]

If anybody at GovDelivery has questions about deliverability issues, I see
some continuing fallout from a subscription forgery run against several US
Government agencies, beginning on Fri, 10 Dec 2021.

Some of these agencies performed subscription verification, and no further
traffic after "Account request expired" messages one week later.  Those were:
 U.S. Department of Homeland Security
 Health and Human Services Ready Campaign 
 Federal Emergency Management Agency

The non-verifying senders include 
 America250 Foundation
 U.S. Census Bureau
 The National Institute of Nursing Research

Subscription requests were entered for a tagged address used to
register a Palm Pilot device twenty or so years ago; the leaking of that
address was mentioned in a NYT article that Saul Hansell did about spam.  

This is a "sudden death" spamtrap.  On first delivery the IP will be
blocklisted for 24 hours.  Subsequent deliveries will cause the listing time
to double, up to about 16 days.  There are currently 8 IPs knocking at the
door, a couple have about eleven days left in exile.

Another address, a fraud/theft detection seed, was also forge-subscribed, and
around this time was added to a number of political mailing lists, as well as
being used as the contact address for a fraudulent AT&T account created in my
wife's name.

If nothing else, inserting a mechanism for dropping "subscribers" who have not
engaged in the previous 90 to 180 days would be helpful.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid

[Michael Rathbun via mailop]

On 13 Aug 2022 20:06:44 -0400, John Levine via mailop 
wrote:

>Sure, but do they come from Sendgrid, which purports to be a service for
>legitimate businesses?

The most recent was 

>Received: from o50316380.outbound-mail.sendgrid.net 
>(o50316380.outbound-mail.sendgrid.net [50.31.63.80]) 
by rabendary.tesp.com with ESMTPS id md5001009616935.msg; Sat, 30 Apr
2022 15:04:35 -0500

It appears to be a bog-stock advance fee fraud, claiming to be
>From:  Jeff Green 

mdr
-- 
"The fact of being reported multiplies the apparent extent of any 
 deplorable development by five- to tenfold"
 -- Tuchman's Law

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid

[Michael Rathbun via mailop]

On 13 Aug 2022 18:46:02 -0400, John Levine via mailop 
wrote:

>This showed up today, send to the email of my father who died in 2019.

I wasn't able to find anything notable about that.  "Nadine", who died quite a
while back, frequently gets the "I've hacked your system and have the video of
you...", along with numerous other equally well-targeted communications.  

mdr
-- 
The hits just keep on coming for poor "Nadine". See the sad tale 
of email lists gone horribly wrong at 
F - IWAA #2157 GEVNP

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Michael Rathbun via mailop]

On 4 Aug 2022 15:29:52 -0400, John Levine via mailop 
wrote:

>If my logs are at all typical, there are no large entities still using
>TLS 1.0. I see a lot of spambots, some compromised VPS at the usual
>suspects like OVH, one well-known IETFer who knows that he needs to
>update his mail server, and Team Cymru who should be embarassed.

Of the 1208 SMTP sessions using TLS during the past seven days, 35 were 1.0.
Of that, 10 were from an email list about an open-source product, 8 were the
mail client I am using at this moment (Forté Agent).  The others appear to be
spambots.

mdr
-- 
  Human beings are perhaps never more frightening than when they are
  convinced beyond doubt that they are right.
  -- Laurens Van Der Post, The Lost World of The Kalahari

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Michael Rathbun via mailop]

On Wed, 3 Aug 2022 13:34:02 +0200 (CEST), Sidsel Jensen via mailop
 wrote:

>We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for 
>MTA to MTA communication, and based on the numbers we've seen so far, it 
>doesn't look that far fetched.

Our analysis states that the most likely point of interception of email
transactions by a hostile party is in the local network, where clients
communicate in the clear, for the most part, and configuration audit trails
are slim.  Whether something foreign could be wiresharking your mail server is
a different discussion.

Large-scale MITM attacks present some interesting engineering problems, above
the doubtful ROI.  Correspondents who must exchange information that should
not be disclosed to a third party already know how to avoid an inherently
insecure channel.

mdr
-- 
  If you have a system set up where a single person can cause an
  extinction level event, it's time to re-examine that system.
  -- Florence  (Freefall)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Trouble sending to sympatico.ca

[Michael Rathbun via mailop]

On Sun, 31 Jul 2022 12:07:43 -0500, John Gateley via mailop
 wrote:

>The sending domain is annbauer.com, mx is hosted by mx.oustrencats.com.
>
>IP addresses:
>
>root@giraffe:~# host mx.oustrencats.com
>mx.oustrencats.com has address 50.116.29.164

Look clean as far as publicly accessible reputation lists are concerned.

>Not sure what you mean about domains referenced in the body, someone 
>contacted my wife and she was replying.

Some systems will examine the message in depth, and check some or all of the
domains found against domain reputation lists.  Some of my clients find their
mail is rejected because they are using a third-party statistics or image
hosting system, and that system's domain has been listed in URIBL or a similar
service, for a simple example.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Trouble sending to sympatico.ca

[Michael Rathbun via mailop]

On Sun, 31 Jul 2022 08:36:31 -0500, John Gateley via mailop
 wrote:


>I don't see any details in the error message.

Since you have included none of the information that might have been used by
the receiving system (your IP?  Your HELO string?  The domain in the envelope?
Any domains referenced in the body?) ... 

>Any ideas? Thanks!

...we really can't say too much.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

[Michael Rathbun via mailop]

On Sat, 30 Jul 2022 18:44:10 +, "Larry M. Smith via mailop"
 wrote:

>.. I really don't know, but I tend to discount the belief that this is a 
>conspiracy against them.

Looking over the past seven years' data, I find that exactly one Democrat
campaign purchased an address that delivers here.  Traffic to that address
stopped after the 2016 election.  There were two other accounts that opted in
to various Democrat candidates' campaigns.  They have seen moderate traffic.

In the same interval, six addresses that deliver here were used to deliver GOP
traffic, and subsequently from a number of organizations that appear to be
ideologically allied with other senders to these addressses.  Only one of
these addresses belongs to a living being that could voluntarily subscribe to
those messages.  That person did indeed give that email address to the the
RNC, which was pushing the Trump campaign in 2015.  Interestingly, when the
RNC gave a copy of that DB to the former president's operations, they
completely left out all of the juice:  Name, address, ZIP code, telephone
number, contribution history...  That address has collected well over seven
thousand messages since it was created.

With the sender(s) there is apparently no interest in suppressing
non-responding addresses after, say six months.

In my recent experience in deliverability, one would be utterly astonished if
the above characteristics did not result in delivery statistics at Google that
differed from the ones complained of by the aggrieved Party.

Also, after the outburst from a Legislator that he can EXPECT that postal mail
will be DELIVERED!...  I would love to ask how much he has paid Google,
compared to how much he has paid USPS, such that he could expect a
commensurate performance.  Unless, of course, this isn't a Free Market
Capitalist® situation.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

[Michael Rathbun via mailop]

On Fri, 29 Jul 2022 20:42:43 -0400, Brett Schenker via mailop
 wrote:

>"They can say whatever they want, but .. I'm +1 with John. They have a
>*lot* to learn about email and how it works"
>
>Unless the language has changed since I read it, it says you need to report
>on how much goes to spam. If you send it to quarantine instead, you can
>still report it as 0 going to spam, completely comply with it, and none can
>get to the inbox.

The Bozometric Tensor is severely strained in the neighborhood of who/whatever
drafted this piece.  "Label", indeed.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] HR 8160 and SB 4409: The "You're not allowed to run political campaign email through your spam filter" act

[Michael Rathbun via mailop]

On Fri, 29 Jul 2022 13:11:24 -0700, Justin Scott via mailop
 wrote:

>Interestingly any email "operator" with fewer than 500 employees or less
>than $5 billion in annual revenue is exempt, so clearly targeted at the
>major providers and not self-hosted operators or small hosting companies,
>thankfully.

If this misbegotten bit of sludge ever makes it to law status, I shall be
applying for an exclusion.  I have less than US$1.00 revenue, and exactly one
employee, but I DEMAND to be one of those operations included in its scope.

Of the over 9,000 political emails that have arrived here from the RNC, the
Trump Organization, the saveamerica45 pac, conservativeintel.com &c &c ad
nauseam, not a single one has reached what might be construed as its intended
recipient. 

And that ain't changing.  (There is a small trickle of Democrat spam, but that
gets suppressed as well.)

The problem:  not a single one of the addresses the injured party or parties
intended to send to actually delivers to a human being who could have agreed
to receive any large or small amount of used food.  Every single one of them
was scraped, purchased, traded for, stolen or made up out of various elemental
gases.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] How can spam originate fron a kazakistan governmental adress?

[Michael Rathbun via mailop]

On Sun, 19 Jun 2022 16:38:50 +0200, Sebastian Nielsen via mailop
 wrote:

>Got the following 2 spam emails, se attach, which originates from a
>kazakistan government.

Not particularly uncommon.  I get spam traffic through every imaginable sort
of governmental or institutional facilities.  In this case, the spammers have
been busy, but the lack of a CBL listing suggests that it has not been owned
by malware operators.

>91.214.42.12
>mgw.gov.kz
>12.42.214.91.NEW.spam.dnsbl.sorbs.net = 127.0.0.6
>12.42.214.91.RECENT.spam.dnsbl.sorbs.net = 127.0.0.6
>12.42.214.91.dnsbl-1.uceprotect.net = 127.0.0.2
>12.42.214.91.score.senderscore.com = 127.0.4.54
>--- 06/19/22 10:54:31 ---

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Talking DOXING of spammers on this mailing list..

[Michael Rathbun via mailop]

On Wed, 1 Jun 2022 15:52:35 -0700, Michael Peddemors via mailop
 wrote:

>
>The goal is not only to DOX this actor, but list EVERY IP Range they are 
>using in their spam operations..
>
>Does this sound like fun for this mailing list, or is this too off topic 
>or noisy?

I think it would be a bit oblique to the purposes of the list as I understand
them.  It would be good to have a forum dedicated to that activity.  

I have a minor pile of information to contribute.  I doubt it would be
something to do here.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] *LIKELY SPAM 27.9* Re: Any reason to NOT block the entire .cam domain?

[Michael Rathbun via mailop]

On Fri, 27 May 2022 15:22:29 -0600, Grant Taylor via mailop
 wrote:

>Is there a reason that you (dynamically) re-configure your MTA(s) via a 
>script verses configuring an upstream router to not route traffic from 
>the IPs in their ASN?
>
>I'm just trying to understand and learn vicariously through you.

Never one to turn that kind of opportunity down.

There is no "upstream" to null-route.  They have well over sixty network
providers they have infested in the past years.  I might just go through and
identify each AS, some day, but it's a non-useful exercise as far as I can
tell right now -- they roost wherever they aren't shot on sight.

These guys have the traditional snowshoe model:  

o  Register between seven and fifty new domains per day
o  Introduce a new netblock (usually just a /26 or smaller)
o  Send bunches of mail until things get all blocky.

It appears that it takes them, on average, roughly eleven minutes of sending
from a new IP range to get the first IP on Spamhaus CSS.  Over the following
ten hours, eventually SORBS, Barracuda and a few others will pick up on this.
Interestingly, Spamcop gets really early warning on these, but seldom actually
lists the IPs.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] *LIKELY SPAM 27.9* Re: Any reason to NOT block the entire .cam domain?

[Michael Rathbun via mailop]

On Fri, 27 May 2022 22:57:37 +0200, Hans-Martin Mosner via mailop
 wrote:

>If you look up the MX records for these domains, you see a certain clustering 
>around one provider. The IP addresses that 
>I checked don't accept port 25 connections at this time, but probably they did 
>when the spam run was active.

Correct.  This is "Slash and burn" spamming.  They've been doing this for at
least five years, with an extremely predictable behaviour pattern.  

>Whether blocking a whole ASN is more advisable than blocking a whole TLD is a 
>matter of opinion - I've often seen that 
>past spammer hosting in an ASN's IP space was a good predictor for future 
>spamminess, but of course as with TLDs you 
>will always have some legitimate servers in the mix...

I have a script that detects these guys when they fire up a new /24, which
happens about 1.3 times per week, and puts new rules in the MTA.  I'm simply
fascinated that they continue to attract new clients while essentially
remaining static in their practices for a net.geological_era.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] *LIKELY SPAM 29.9* Any reason to NOT block the entire .cam domain?

[Michael Rathbun via mailop]

On Fri, 27 May 2022 12:01:46 -0600, Anne Mitchell via mailop
 wrote:

>We've started getting a fair amount of spam from .cam domains; in fact they 
>all look the same, using the same HTML template with the same body format, but 
>from different .cam domain for different 'businesses', so I suspect that one 
>operation is selling "email marketing" packages to clients and setting it up 
>for them, especially as they all are sending through their own domains, and, 
>let's face it, these sorts of spammers usually don't know how to set up their 
>own MX, etc.. rather than spamming through Google or Outlook.

The same gang has been trying out .mom and .lol, of late.

>They are all coming from:
>
>77.73.131.0/24
>185.221.66.0/24

That's two of the 142 net blocks I have found them in over the last several
years (excluding the netblocks that have subsequently been resold to other
spammers).

If this particular spamgang interested you, I have a list of 53 body invariant
strings that nabs about 97% of their used food.

mdr
-- 
My study of life and history inclines me to the apothegm "If you insist on
burning bridges, it is often best to cross them before engaging the
incendiaries." --  Shebardigan

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Comcast thottling at a dozen emails

[Michael Rathbun via mailop]

On Mon, 23 May 2022 15:41:20 -0600, Rob Nagler via mailop 
wrote:

>I'm struggling to get mail through to Comcast on our new-to-us IPs from
>Linode. We are a sending less than a dozen emails and getting throttled:

It's not the quantity so much as the instantaneous rate.  If you have a
per-domain/mx throttle facility, set it to 250/hr or thereabouts.  If your
system does the usual inrush, the apparent delivery rate can be in the
thousands per hour, even if you only sent twelve.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Internet Research Project on Linode - Any Experience?

[Michael Rathbun via mailop]

On Fri, 06 May 2022 15:31:12 -0700, Mike D via mailop 
wrote:

>I highly recommend using greynoise.io to help filter your logs. They do
>a pretty good job of determining what connections are benign scanners
>and which lead to subsequent attacks.

Benign scanners are the ones who transparently announce their intentions,
preferably before commencing their scans.  

ALL others are hostile, without exception.   Especially the ones who are
checking out login vulnerabilities on an SSH port that has been moved to port
2271.

mdr
-- 
  The world was almost won by such an ape!
The nations put him where his kind belong.
  But do not rejoice too soon at your escape.
The womb he crawled from is still going strong.
-- Bertold Brecht,"The Resistible Rise of Arturo UI"

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Internet Research Project on Linode - Any Experience?

[Michael Rathbun via mailop]

On 6 May 2022 14:53:35 -0400, John Levine via mailop 
wrote:

>They appear to fail on all three criteria.

As do a couple of parties operating out of several /24 or smaller blocks, none
of which are now allowed to connect here.

I cheerfully participate in research, both to my personal benefit and to that
of the others.  I moderate a support group for a particular neurological
condition, and we allow and encourage researchers to invite participants.

I note that none of the "research" efforts I have observed from the logs have
at any time invited participation.  Accordingly, I engage the functional
equivalent of the machete mentioned above.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] WTaF? I just got spammed BY Active Campaign

[Michael Rathbun via mailop]

On Tue, 26 Apr 2022 15:30:28 -0600, Anne Mitchell via mailop
 wrote:

>WTaF?? 

I presume they are encouraging you to spam your legal services through them,
rather than on the cover and spine of the local Yellow Pages™?

mdr
-- 
  The world was almost won by such an ape!
The nations put him where his kind belong.
  But do not rejoice too soon at your escape.
The womb he crawled from is still going strong.
-- Bertold Brecht,"The Resistible Rise of Arturo UI"

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Michael Rathbun via mailop]

On Mon, 18 Apr 2022 12:17:25 -0400, Bill Cole via mailop 
wrote:


>Should Google be better about noticing when problems go away? Maybe. Should IP 
>addresses be made permanently useless for email because one well-intentioned 
>sysadmin didn't recognize a problem for long enough that Google noticed?

Indications we have here are that Goog puts about 1% of a sender's mail in
somebody's inbox regardless of reputation, even down to flat rejection at the
border.  I have actually seen a sender go from flat rejection to 100% inbox in
just under two weeks.  They just kept sending mail that got engagement (opens,
clicks) and minimal complaints and zero stale account hits.  

Senders who don't generate (or expect) these signs of "engagement" may not
always have pleasant outcomes.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Our experience on Gmail blacklisting our IPs range

[Michael Rathbun via mailop]

On Tue, 5 Apr 2022 16:39:16 +, ml+mailop--- via mailop 
wrote:

>BTW: AFAIK "don't be evil" is not Google's motto anymore.

Geek tradition requires inserting "FSVO 'Evil'".

mdr
-- 
One thing you discover after opening a can of worms is that 
each worm is carrying another can.
-- Shebardigan

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] large number of mail connections

[Michael Rathbun via mailop]

On Sat, 19 Mar 2022 17:57:44 -0600, Geoff Mulligan via mailop
 wrote:

>I have 3 different mail servers that are currently being inundated with 
>mail connections from:
>
>109.237.103.42
>
>This appears to be from Russia - go figure.

There were a bunch of relay attempts and AUTH LOGIN attempts before various
rules here began to compete to see how long the IP would remain in the "no
connections" bin.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] sorbs DNS problems

[Michael Rathbun via mailop]

On Fri, 11 Mar 2022 19:54:00 +0100, Slavko via mailop 
wrote:

>Please, encounter someone else this? Are here some problems on their
>side?

They frequently fail the timeout setting on a DNSBL checker tool I use.
Running the tool again pulls the records in cache that arrived after the
timeout.  The resolver is a local instance of bind.  

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft banned sender (Linode hosted IPs)

[Michael Rathbun via mailop]

On Tue, 1 Mar 2022 20:12:13 +, Andy Smith via mailop 
wrote:

>Following the link leads to a delist form but this comes back as
>"139.162.167.107 is not listed" and then says to get the Microsoft
>tenant to open a ticket. I've asked my recipient to do that and they
>said they would today, but I haven't heard back with a ticket number
>yet.

This is eight-year-old data, but we would regularly find that an address or
block of addresses, in a problem escalated to us from India, was present in
the "Banned Sender List", a flat text file which was invisible to support
people world-wide.  During my time at Exchange Online as a spam analyst, I
recall using vi as root on the Linux box that handled that manually-maintained
list.

I had thought they would have disposed of that, by now.

mdr
-- 
  Doctrine, when it lets its hair down,
   can trample, without fear,
   even the most innocent of truths.
-- Frederico Garcia Lorca

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [RESOLVED] Getting 'Access Denied' on Microsoft supportrequestform

[Michael Rathbun via mailop]

On Fri, 4 Feb 2022 15:25:39 +0100, Axel Rau via mailop 
wrote:

>Thanks Eric,
>
>I tried again (using Safari instead of Firefox) and it succeeded,

There is an often-unnoticed tie to one's Hotmail account (if one has one)
which can deliver this issue.  I found it necessary (when I worked at
Microsoft) to use a "private" or "anonymous" web browser session for support
forms if I had ever used the browser to access one of the freemail accounts I
maintained.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Forms vs email abuse reporting

[Michael Rathbun via mailop]

On Wed, 19 Jan 2022 22:01:49 -0600, Scott Mutter via mailop
 wrote:

>Further from that, I'm not really sure if that's the type of abuse contact
>the OP was referring to in this thread.

At various times over the past 26 years I have been responsible for the
various kinds of activities one needs (abuse/policy enforcement, fraud,
network security, customer service) together with opportunities to observe
some of the more dismal realities of corporate systems behaviour.  My
observations indicate that the mahoganites and the folks who infest certain
boardrooms have not quite absorbed the need not to starve cost centers.  

They will all go bad together, for essentially the same reasons.

mdr
-- 
There's a funny thing that happens when you know the correct
answer.  It throws you when you get a different answer that
is not wrong.-- Dr Bowman (Freefall)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Forms vs email abuse reporting

[Michael Rathbun via mailop]

On Wed, 19 Jan 2022 15:55:40 -0600, Scott Mutter via mailop
 wrote:

>(AT&T is just an example here, but serves to better illustrate how a form
>could be useful in this situation)

Based on their corporate behaviour in recent experience, I would assert that
AT&T is not a useful case, comparable to the general run.  

For instance, in the tariff side, it is well known that AT&T's Global Fraud
Department has not responded to telephone calls for many years, and if we want
to get traction handling a fraudulent account created in my wife's name, which
AT&T required NO confirming identification to establish, my wife must appear
in person at an official AT&T shop, with photo ID, to confirm that she is the
person who did not set up the account.  We decline to do this, so they
continue to bombard an email account I set up in 2008 for a test of a co-reg
site, demanding payment.  The fraudsters appear to have access to AT&T's
customer history database, my wife's SSAN, and access to the USPS database
that will give you the addresses of newly-vacated residences, the names of the
former occupants, when they moved, and where they have moved to.

AT&T could have caught the folks who ordered the tricked-out iPhone 13 on
installment, and had it sent to an address we vacated months ago, but yawn.

At least we have a free phone for all the hassle, though we haven't decided
what to do with it.  They do offer a form for fraud reports, but you can't
fill it out without knowing the entire account number, which you can't know
unless you activate the phone, or visit a store as noted above.

So, imagine how keen they will be to handle silly little issues such as the
ones you describe.  It's not difficult to imagine that the budget lines for
all those abuse-handling activities are asymptotically approaching the cube
root of zero.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft/Lindo - junked,not blocked

[Michael Rathbun via mailop]

On Mon, 17 Jan 2022 18:04:30 -0600, John Gateley via mailop
 wrote:

>The IP address in question is not currently blocked in our system. 
>Please refer to the email message you received from Microsoft and follow 
>the steps it suggests.

I have no detailed knowledge of what the current system structure is, but
seven years back I was one of the people maintaining blocking lists &c for
O365.  

At that time, there was a variety of lists that the system consulted, some of
which were maintained by somebody with root access and vi (or emacs, according
to taste).  At least two of those could result in a "banned sender" response.
The humans responding to delist request would have no idea that these lists
even existed, let alone how to check them.

Adding that to the generally stochastic response of the architecture as it was
back then made diagnosing some delivery failures an adventure.  I imagine it
still is, but in new and different ways.

mdr
-- 
Fail-safe systems fail by failing to fail safe.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Michael Rathbun via mailop]

On Sun, 26 Dec 2021 21:31:02 -0700, Dave Warren via mailop 
wrote:

>Many/most centralized communication systems require phone number 
>verification/validation (SMS or voice, typically) to activate a new 
>account. Even when multiple accounts can be activated using a single 
>phone number they can be linked and deactivated as a group.

What's interesting in this connection is that at least one telephone provider
(AT&T in my wife's case) requires no identification whatever (beyond a SSAN
and an address) to establish service and order equipment delivered to a
residence.  I do not consider this to be a challenge.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Michael Rathbun via mailop]

On 26 Dec 2021 21:39:36 -0500, "John Levine"  wrote:

>Last time I checked Gmail sends you an SMS with a code you need to provide to
>register a new account.

Ah, that.  Obtaining a phone is not difficult nor will the expense exceed zero
in a number of cases (such as my wife's recent adventure with a bogus AT&T
account demonstrates).  I suppose one could include paying for a burner phone.
But simply to have a throw-away "from" address, with the right equipment and
software, any mystic number will do.

>Given the amount of spam I'm getting from Gmail, who knows how much it's 
>slowing
>the spammers down.

In our collective experience, few things other than bankruptcy or imprisonment
seem to slow spammers.  "Nadine"'s favorite gang just fired up two new /24s
this past week.  They seem also to have around fifty new domains waiting
around in the cooler to get past the "day old bread" checks.  Human societies
can be such fun.

mdr
-- 
  Human beings are perhaps never more frightening than when they are
  convinced beyond doubt that they are right.
  -- Laurens Van Der Post, The Lost World of The Kalahari

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What a drag it is sending DMARC reports

[Michael Rathbun via mailop]

On Mon, 27 Dec 2021 02:44:35 +0100, Ángel via mailop 
wrote:

>I wonder however if that's still the case for "professional" spammers,
>as I expect they would be able to buy phone numbers more easily and
>cheap than common users.

What is this 'buy' of which you speak?   Phone numbers are composed of digits,
all of which have been freely available for use since they were propounded by
Indians, Arabs, Romans...   Unless you mean "phone numbers that are actually
routable from caller to called party" which is unnecessary in this context.  

Who wants to answer calls from infuriated civilians?

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Seeking route to AT&T Fraud on a weekend

[Michael Rathbun via mailop]

On Sun, 12 Dec 2021 08:42:23 + (GMT), Andrew C Aitchison via mailop
 wrote:

>Can your wife ask Frisco law enforcement to watch the address ?

As noted:  nope.

>If this were under UK law, the package would now belong to her, not AT&T
>- which is a complication that works in the thieves favour in this sort of 
>crime.
>You have an advantage in this case in that you know in advance that you
>have title to the to-be-stolen object.

Indeed.  Since AT&T Global Fraud department has been unreachable for several
years, according to online gripes, and no other interesting avenues existed, I
told FedEx to give me status notifications, and a friend of ours was available
to sail by the address and snaffle the parcel within a few minutes of it being
dropped.  It will be in our possession, if all goes well, in a couple days.

It turns out that AT&T requires much more stringent personal identification to
shut down a fraudulent account than to establish a fraudulent account.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Seeking route to AT&T Fraud on a weekend

[Michael Rathbun via mailop]

On Sun, 12 Dec 2021 08:42:23 + (GMT), Andrew C Aitchison via mailop
 wrote:

>Can your wife ask Frisco law enforcement to watch the address ?
>
>If this were under UK law, the package would now belong to her, not AT&T
>- which is a complication that works in the thieves favour in this sort of 
>crime.
>You have an advantage in this case in that you know in advance that you
>have title to the to-be-stolen object.

Frisco PD won't have resources for surveillance without probable cause, and in
any event the actual crime, in the Officer's view, was a fraudulent account
opened in my wife's name, making Austin, TX the locale where the local PD
would be the place to file the report.  I hope to get some more info when AT&T
Fraud opens tomorrow.  At least I will know within five minutes of the package
drop.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Seeking route to AT&T Fraud on a weekend

[Michael Rathbun via mailop]

This is actually email-related, as someone used an old seed address as a
contact point for a fake AT&T Wireless account to order a tricked-out iPhone,
to be sent to my wife at a street address we vacated months ago, and which is
not currently inhabited.

The email address is a test seed I used to check out data fate on a co-reg
site in 2008.  Appenders appear to have associated this address with my wife.
She now is inundated with half a dozen Trump-O-Grams™ daily, and now this.

On Friday, 10 Dec, that account received a note from AT&T requesting address
verification, followed by two more notes acknowledging order #
23-seventeendigits and giving its current status.   

That order is for an "Apple iPhone 13 - 512GB- Product(Red)".   Hooh, price
not disclosed, but over ninety dollars sales tax.  

Today, 11 Dec, more status email, the most recent containing the FedEx
tracking number.  The item was picked up by FedEx in Irving, Texas today at
11:10 USCST, and will be delivered on Monday to an address we vacated months
back.

Since crimes never occur on weekends, AT&T Fraud Department won't come to life
again until Monday, probably too late to ask law enforcement in Frisco, Texas
to see who picks up the package.

Being a veteran of operation at large providers, I KNOW that there is some way
to wake someone up before the bird is flown.  

If somebody has the resources to do this with li'l ol' us, there have to be
thousands of similar operations under way.

mdr

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Got any users in Texas? Better turn off your spam filters by Dec 2

[Michael Rathbun via mailop]

On Thu, 23 Sep 2021 20:41:41 -0700, Michael Peddemors via mailop
 wrote:

>Why is there no laws that help protect the innocent victims of all the 
>phishing attacks that go on unabated from some of the largest companies?

In the case of unsolicited broadcast email (UBE, spam) the laws tend to be
written by those who wish to send, and/or who receive financial support from
those who wish to send unsolicited broadcast email, also known as Forced
Pay-Per-View Advertising.  

Follow the money.

mdr
-- 
  Ad finem pugnabo.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Got any users in Texas? Better turn off your spam filters by Dec 2

[Michael Rathbun via mailop]

On 23 Sep 2021 23:42:38 -0400, "John Levine"  wrote:

>Oh, you can't block them at all.  See sec 321.054.
>
>https://statutes.capitol.texas.gov/Docs/BC/htm/BC.321.htm#321.054

Which states, unless my monitor deceives me, that the denial must be "based on
the content of the message".  Since the total number of blocking decisions
based on content at this server is exactly equal to the cube root of zero, the
statute is not applicable.  However, I would welcome adversarial court actions
affirming that the statute should not be interpreted as written.

mdr
-- 
   "There will be more spam."
  -- Paul Vixie

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Got any users in Texas? Better turn off your spam filters by Dec 2

[Michael Rathbun via mailop]

On 23 Sep 2021 23:26:12 -0400, John Levine via mailop 
wrote:

>Do you really want to negotiate with every spammer who complains
>you're blocking his stuff, as 321.114(a) requires? How much free time
>do you have?

Plenty.  I'm retired.

However, given that the quoted statute claims to govern "intentionally
imped[ing] the transmission of another person’s electronic mail message based
on the content of the message", there is nothing to discuss.  

The content was not taken into account in the blockage.  The fact that the
message constituted theft of service was taken into account:  the user did not
give actual or constructive consent to the sender to use their resources for
the sender's benefit.  In the case of many of the recipients, they failed to
give consent because they fail to exist.

Even former Republicans should have some idea of property rights.

mdr
-- 
 "There are no laws here, only agreements."  
-- Masahiko

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Got any users in Texas? Better turn off your spam filters by Dec 2

[Michael Rathbun via mailop]

On 23 Sep 2021 22:45:48 -0400, John Levine via mailop 
wrote:

>* it “provides a process for the prompt, good faith resolution of a dispute 
>related to the blocking with the sender of the commercial electronic mail 
>message” or

Fortunately, all of the senders that I publicly announce that I am blocking
are political messages from Texas members of the Former Republican Party, who
are not commercial senders, even when taking into account that all of the
messages present monetary demands upon the (usually nonexisting) recipient.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone seen this "email warmup" pattern?

[Michael Rathbun via mailop]

On Sat, 28 Aug 2021 12:35:54 -0500, Jarland Donnell via mailop
 wrote:

>However, I have reason to suspect Active Campaign may be related. 
>Roughly one day prior to the relevant outbound events, users who sign up 
>for this begin receiving a bunch of emails from the domains that they'll 
>later reply to when this activity kicks into gear. I captured the 
>domains from the most recent event, and the first one is where I get the 
>idea:
>
>https://paste.mxrouteapps.com/?3f1e9c94725acc29#JDHaaiYp4TU9nJLfkwEieqRRu1GXXQUsvxYivhjpo4Ha

Fascinating.  

>
>> This falls more under the "fraud" category, since this is a largely 
>> imaginary
>> strategy.
>
>It's refreshing to not question if I'm alone in this thought. 

If I have anything to say about it, you will not feel so all alone at all.

> I value my 
>customers, that's why I value one not performing activity which puts the 
>others at risk. I'm not just aiming to be a good neighbor, I want to be 
>the best neighbor I can possibly be.

Such is the nature of being society-oriented rather than self-oriented.
Sometimes the rewards are not immediately apparent.

This has given me much to consider, especially when noting that one of my
clients appears to be trying to do this on his own.  So far, a fair bit of
avoidable misery.

mdr
-- 
   Those who can make you believe absurdities 
   can make you commit atrocities.
-- Voltaire

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop