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, 

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, 

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,   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 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   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 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 is not a useful case, comparable to the general run.  

For instance, in the tariff side, it is well known that AT'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 required NO confirming identification to establish, my wife must appear
in person at an official AT 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'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 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  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 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
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 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
>- 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 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 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 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
>- 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
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 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 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 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 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

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

[Michael Rathbun via mailop]

On Sat, 28 Aug 2021 09:46:59 -0500, Al Iverson via mailop 
wrote:

>Yes, there are whispers of this in the deliverability world. Good
>people always recommend against doing this because it's scummy and
>unethical and even if it works today, it's not going to work tomorrow.
>I am absolutely certain it's something that providers like Gmail and
>Yahoo will figure out how to identify and deal with accordingly, if
>they haven't already.

There are several handles available for administators to grip the problem.  As
we saw, Hotmail figured out Boris' game quickly.

A delightful prospect emerges:  when you identify a batch of robot accounts on
your system, you simply adjust the filters to convert them to "sudden death"
spamtrap accounts, thus reducing all of that business's clients' reputations
down to the "do not resuscitate" level.

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] Anyone seen this "email warmup" pattern?

[Michael Rathbun via mailop]

On Sat, 28 Aug 2021 02:29:17 -0500, Jarland Donnell via mailop
 wrote:

>I've been catching my customers left and right lately signing up for 
>some email warmup service.

OK, I see I've been completely out of touch with that segment of the industry.

The process of attempting to game reputation systems by sending to
robot-administered accounts eventually leads to things like the Microsoft v.
Boris Mizhen et al. settlement in 2010.  There appear to be a number of
companies that offer to accomplish this.  Perhaps they also have a few tens of
millions lying about unused.

I see that Mailwarm.com promises to 

"[act] like thousands of perfect leads interacting with your emails.
This parallel activity sends a positive signal to email providers and their
spam filters.
...
"Your email account automatically sends dozens of emails to +1000 Mailwarm's
accounts, and get replies. Mailwarm daily interactions are sent according to
the schedule you set."

In other words, actionable fraud, against the providers and against your
customers.

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

___
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 02:29:17 -0500, Jarland Donnell via mailop
 wrote:

>I've been catching my customers left and right lately signing up for 
>some email warmup service. I don't know what it is. 

I take this to mean that you know they are signing up, but do not know what
they are signing up to?  

> What they do is they 
>take SMTP credentials, payment, and then supposedly send a bunch of 
>random emails hosted at other providers and mark them as not spam. 

This falls more under the "fraud" category, since this is a largely imaginary
strategy.  If the FTC were still in the enforcement game, this might be an
interesting prosecution.

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

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

Re: [mailop] Abuse reporting to Microsoft?

[Michael Rathbun via mailop]

On Wed, 23 Jun 2021 23:49:55 +0100, Simon Arlott via mailop
 wrote:

>Is it actually possible to report email abuse to Microsoft?

Glendower:  I can call spirits from the vasty deep. 
Hotspur:Why, so can I, or so can any man;
But will they come when you do call for them? 
-- Henry The Fourth, Part 1 Act 3, scene 1

Any person can report things dire or trivial to Microsoft.
The question is:  will anybody ever read them?

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: protection.outlook.com refusing to accept mail with misleading temp error message

[Michael Rathbun via mailop]

On Wed, 02 Jun 2021 22:35:56 +0200, Florian Effenberger via mailop
 wrote:

>what IMHO would be much better to check newly assigned IPs is, if 
>there's a way to query via DNS, or a web form. That way the issue can be 
>solved and clarified in advance, and not only when problems occur. Not 
>everyone has an account at hand to test it upfront.

That's quite appealing to me.  It would be cool to have a complete project
plan for this, with all the budgetary and schedule data, to submit to TPTB to
get the ball rolling.  The ball is extremely unlikely to roll, but nothing
ventured, nothing gained.

Any year now.

mdr
-- 
  Ad finem pugnabo.

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

Re: [mailop] [EXTERNAL] Re: protection.outlook.com refusing to accept mail with misleading temp error message

[Michael Rathbun via mailop]

On Wed, 2 Jun 2021 04:15:30 +, Michael Wise via mailop 
wrote:

>That would shut down email as a viable communications mechanism almost 
>immediately.

In the past six days of logs on the tiny server I run (friends, family,
personal business) 97.3% of all connection attempts were hostile in some form
(spam, dictionary attacks, malefactions NOI).  88% of all SMTP sessions were
spam delivery attempts.  I do have about a 2% false positive rate, still, even
though the filtering system has been personally crafted over the past 20
years.


mdr

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

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

[Michael Rathbun via mailop]

On Wed, 2 Jun 2021 10:50:05 +0100, Laura Atkins via mailop 
wrote:

>I think the system has accreted and evolved to a point where not even the 
>folks inside Microsoft can tell you why a mail was delivered where it was. I 
>mean, that’s been true for more than a decade now. It’s not, somehow, that the 
>folks answering sender support mail won’t tell you, it’s that they can’t tell 
>you. I suspect that even the system developers couldn’t tell you exactly why a 
>mail went to bulk or was discarded or was rejected. 

Toward the end of my careen at MS, my analysis of the architecture that the
system was evolving toward (on the O365 side) told me that it should be
possible for a message to completely disappear without the possibility that
any plausible investigation process would reveal why (or even if) a particular
message met a particular fate.

This architecture has been carried over into the "unified" system, with
considerable elaboration.  I often use the term "apparently occasionally
non-deterministic" for the platform.

Having watched the system behaviour from the outside for the past eight years,
I have found no reason to alter this impression.  I doubt strongly that there
is any individual with a full synoptic grasp of the System itself.

>With that being said, they try to help senders, much more than a lot of other 
>mailbox providers. 

Certainly most of the individuals I worked with had a keen understanding of
the issues facing all the parties.  The problem is that those who make budget
decisions or control the deployment of resources in the Corporation will often
have disjoint understandings and a different set of primary objectives.

(Then there was our Search for that individual or group who were actually
required and empowered to read and answer abuse@ and postmaster@...)

>Filters are not static, they are adjusting all the time. Sometimes ‘just keep 
>trying’ is the right thing to do. Sometimes ‘give it a rest for a week (or 2 
>or 3) and let your reputation reset’ is the right thing to do. Sometimes it 
>feels like there is nothing the sender can do to change delivery. 

The advice that MJW gave a while back (If you see significant deferrals, STOP
ALL SENDING for at least an hour.  If the problem persists, stop for 24
hours.) has proved to be worthwhile.  Fortunately, on the platform my clients
are using, implementing that for any recipient system is trivial.

>MS users and MS policy makers are about the only folks who are going to be 
>able to change what MS is doing. It sucks for those of us who are looking at 
>the mail in our outbound queues and going ‘yknow, this person paid for this 
>email and MS isn’t letting me deliver it” or “this person probably really 
>wants their appointment reminder, but MS isn’t letting me deliver it” or 
>“Auntie susie really wants to hear from cousin joan, sucks microsoft doesn’t 
>like this” but complaining on mailop isn’t going to change any of that. 

"Microsoft" and "Systems Microsoft is presently running" are distinct
entities, often with no discernible connection other than the accidental.
When it was possible to do so, I spent a considerable amount of my work day
investigating reported false positives, and fixed a lot of unneeded damage.  

Eventually I was reassigned.

In the end, however, "How to prevent CEOs of large client corporations from
calling Rajesh Jha in the middle of the night because of massive spam
problems" will become "How to prevent Rajesh Jha from calling ME in the middle
of the night due to client spam problems", which will then tend to drift to
the top of one's priorities.  (Rajesh Jha was $BIGNUM pay grades above us all,
at the time.)

I will point out to the assembled multitude that the world of email
experienced by a spam analyst at Microsoft or Y!/AOL or gmail is remarkably
different from the world of email experienced by someone trying to operate an
ethical and effective email sending operation, or to advise those that do.  

Then add, on top of that, designers and developers who personally are
relatively unconnected to actual email operations as a whole...

Your world (and mine, now) could actually be considerably worse.

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: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Wed, 12 May 2021 10:47:34 +0100, Laura Atkins via mailop
 wrote:

>Or… care? 

Heh.  The difference between not knowing and not caring is in the time lapse
between the offence and the inevitable "time wounds all heels" event(s).

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] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Wed, 12 May 2021 09:27:40 +0100, Laura Atkins via mailop
 wrote:

>The things we normally recommend to folks don’t always work as expected. 
>Sometimes they do and we can fix things no problem. But sometimes they are 
>just an inscrutable black box with variable responses.  

This is a characteristic that is also visible inside the system.  I found
instances in the architecture where it might be impossible to determine what
had happened to a given message.

>The other bit of speculation is that Microsoft as an entity just 
>doesn’t really care what any outside company or person thinks. They do things 
>The Microsoft Way. 

I endorse this analysis, noting that MSFT attempted to replace "commodity
protocols" like TCP/IP with their own concoctions; MSFT had no idea what
forces they were dealing with. 

>There isn’t the space inside the company for folks who know 
>what the problems are to effectively advocate for change. I think there are 
>lots of individuals who care and who see the issues, but the product 
>developers / managers / owners just don’t care. They’d care if there were 
>numbers to demonstrate the problem, but none of the numbers actually look like 
>a problem. 

My utmost respect for those who are still there, working in whatever way they
can.  The foe is not an evil supervillain.  It's simply the system as it has
evolved to work, within the systems in which it is embedded.

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] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Wed, 12 May 2021 10:08:37 +0200, Jaroslaw Rafa via mailop
 wrote:

>Your second paragraph can be basically summed up that there is no economic
>incentive for Microsoft to care about the quality of email service they
>provide - right?

Tochno.

>If yes, don't you agree that Microsoft should ;) simply stop providing the
>email service at all? I think this would be better solution that keep up a
>service that isn't working properly...

The IS is that if it's not dragging down the bottom line, no action is
required.  If it is not necessary to change something, it is necessary NOT to
change something.  My opinions (which are that a public nuisance SHOULD be
abated) are irrelevant.

Sixty years slogging through the capitalist jungle has left me with a few
occasional revelations.

mdr

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

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Wed, 12 May 2021 09:59:35 +0200, Hans-Martin Mosner via mailop
 wrote:

>I'm not talking about hotmail/outlook, I'm talking about Office365 customers 
>who *do* pay and who would be pretty much
>not amused if their mails were broadly rejected.

Ah.  As one who was a Spam Analyst in the Office365 structure, I have some
personal knowledge of this.  In fact, paying-customer feedback is (was, when I
was there) an intense concern.  However, the feedback that reached us was
exclusively in the midnight calls to management that amounted to "WHY THE FUCK
IS MY COMPANY GETTING SO MUCH SPAM??".  Were there a mechanism in place for
customers to discover whether their mail was being accepted, there might have
been such sand raised.  However, since there are explicit prohibitions of
attempting broadcast email through the O365 service, no deliverability
services are provided.  

We did pay LOTS of attention to the constant outbound spamming activities that
were enabled and promoted by stupid management decisions regarding intake,
vetting, and monitoring of new customers.  Some of us had solved these issues
during the early all-you-can-eat-for-$20 dialup era.

>And I'd wager a bet that most of these (and their MSFT sales buddies if they 
>have any) would put the blame squarely on
>those who rejected their mails, not on MSFT.

You might not find the odds in your favour.

mdr
-- 
  Ad finem pugnabo.

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

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Wed, 12 May 2021 09:29:13 +0200, Jaroslaw Rafa via mailop
 wrote:

>But if they do provide it, they should do it well. It's no justification for
>providing a crappy service that it is free. If you are doing something, do
>it well, or don't do it at all.
>
>Sadly, they are so big that they can just get away with providing crappy
>service and there will always be someone like you who will defend them for
>providing crappy service "because of economic realities".

I am mystified by your claim that I am defending MSFT.  My personal history
would contraindicate that strongly.  I do defend the various individuals, many
of whom I count as personal friends, who work within that system.

I have found that, when advising clients, it is best to back carefully away
from "should" and focus intently on "is".  

Microsoft *SHOULD* (in my own personal opinion, and that of many others)
provide the highest quality service they can, taking into account the needs of
all involved parties.

Microsoft *IS* in a business that takes none of that into account, at the
level of basic decision making.  There is no inherent force in operation that
will make them regard my or your opinion in the normal operation of a
profit-making system.  There is no inherent force that will cause any of their
decisions to be logical, practical or constructive, other than the impersonal
cruelties of the marketplace.

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] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Wed, 12 May 2021 08:37:30 +0200, Hans-Martin Mosner via mailop
 wrote:

>Yet at the same time Microsoft expects "the world" to accept mail from their 
>customers. 

It would be difficult to verify this.  There is nobody at MSFT (or at least
wasn't when I worked there) that pays any attention to whether the freemail
service is accepted, rejected or even noticed at all.  There are nests of
people within MSFT who care deeply about all of these things, but it would be
folly to equate them with Microsoft itself.

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] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Michael Rathbun via mailop]

On Tue, 11 May 2021 19:45:28 +0200, André Peters via mailop
 wrote:

>What is this crap good for when it sends one out of 1000? 

 

You may wish to take into account economic realities.

YOU are not a Microsoft customer.
The RECIPIENTS are not Microsoft customers.

None of the above parties pays Microsoft a cent.

Microsoft, Google, and whatever Y!/AOL/VZN may be this week have no inherent
economic interest in facilitating any aspect of your email sending.  Their
efforts at mitigating bad effects of filtering system decisions are tuned
largely toward keeping their users happy and engaged, to the extent that they
are tuned at all in any practical engineering sense.

If your email is important to the recipients, then they should be encouraged
to complain to the provider when it is not delivered -- although they may not
be the customer, they are in fact the product.

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

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

Re: [mailop] Duplicate duplicate mail mail from from Gmail Gmail ?

[Michael Rathbun via mailop]

On 9 May 2021 21:37:35 -0400, John Levine via mailop 
wrote:

>The only thing I have changed lately is that I added CHUNKING so it sends the 
>mail using
>the SMTP BDAT command rather than DATA.  As far as I can tell that is working 
>correctly
>and other places send me mail with BDAT without trouble.

I have seen similar duplications, especially with certain mailing lists.  If
it is something you are doing, you are not alone.

mdr
-- 
   Remembrance and reflection how allied!
   What thin partitions sense from thought divide!
   -- Alexander Pope

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

Re: [mailop] How stale is too stale for contacts?

[Michael Rathbun via mailop]

On Tue, 4 May 2021 10:50:22 -0600, Grant Taylor via mailop 
wrote:

>I'd like to know if I'm off my rocker or if the person / company that 
>sent the message with the following excerpt is using purportedly once 
>good contact information /well/ /past/ it's best by date.

In my experience, this will heavily depend upon your objective.  

If you are someone with a list you have gathered by opt-in over the past ten
years, it will be painful to hear that, if you wish regularly to reach
recipients at some large providers, NEVER, EVER send to an account that has
not responded/engaged/opened/ is the past 180 days.  Wisdom would suggest
modifying that to 90 days.

If you are operating in hope that some of these "stale" addresses are still in
the possession of the original owner, not abandoned, then send away.  The
results may be sub-optimal, but that's not something you can control.

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

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