Re: [mailop] [EXTERNAL] Re: What's the point of secondary MX servers?

2020-12-17 Thread Howard F. Cunningham via mailop 
Hi

Where we have multiple internet connections, we setup MX records for both 
connections.  If one connection is down, email flows through the other one.

hc


Howard Cunningham, MCP
Microsoft Small Business Specialist
Macro Systems, LLC
3867 Plaza Drive
Fairfax, VA 22030
www.macrollc.com
703-359-9211
howa...@macrollc.com - personal
For technical support, send an email to serv...@macrollc.com or call 
703-359-9211 (24/7)


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Chris via mailop
Sent: Thursday, December 17, 2020 5:07 PM
To: mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] What's the point of secondary MX servers?

Caution brain bending ahead:

Secondary MXes have a role as your main mail server.  Long experience with 
spambotnets reveals that most of them are pretty stupid, because their MX 
capabilities are limited.  In fact, many spambots infections don't do any DNS 
lookups at all, and rely on pre-recorded resolutions done centrally, of JUST 
the primaries, and in some cases long after the resolution has gone stale.  In 
particular, the spambot responsible for most bitcoin extortion and Russian 
pseudo-Canadian Rx is a good example of something that caches resolutions for 
as much as a year or more.

Some of my most effective spamtraps don't have anything MXed at them anymore. 
I've had one trap move from one set of IPs to another.  The old MXes actually 
generate more infected IPs than the new ones do EVEN WITHOUT treating anything 
hitting the old MXes as infected by definition.

[My bot detection rules on the new IPs is around 60% of total traffic. 
Damn spot on 100% on the old ones.]

A few other spambots think they're smarter than you, and will deliberately spam 
the worst priority MX thinking that these will be the servers that have the 
weakest filtering.

If you have a few IPs to burn, and an existing mail server, this is what I 
recommend:

1) Set up a secondary MX pointing at your real mail server with full 
spamfiltering.
2) Set the primary MX pointing at a stub that does nothing more than do a 
reject on HELO/EHLO.
3) Set a tertiary MX pointing at an IP that doesn't actually have anything 
listening.

Many spambots will hit the primary, get a failure, and simply give up. 
Real servers will hit the primary, then try the secondaries.  A few spambots 
will hit the tertiary and waste their time waiting for something that won't 
happen.

Note: both the primary-MX reject, lower priority MX hang proposals did make the 
rounds, separately, many years ago on, say, Usenet discussion forums.

I can personally assure you that they really do work, but your precise mileage 
may vary.

On 2020-12-17 16:21, John Levine via mailop wrote:
> As we all know, MX records have a priority number, and mail senders 
> are supposed to try the highest priority/lowest number servers first, 
> then fall back to the lower priority.
> 
> I understand why secondary MX made sense in the 1980s, when the net 
> was flakier, there was a lot of dialup, and there were hosts that only 
> connected for a few hours or even a few minutes a day.
> 
> But now, in 2020, is there a point to secondary servers? Mail servers 
> are online all the time, and if they fail for a few minutes or hours, 
> the client servers will queue and retry when they come back.
> 
> Secondary servers are a famous source of spam leaks, since they 
> generally don't know the set of valid mailboxes and often don't keep 
> their filtering in sync?  What purpose do they serve now?
> 
> R's,
> John
> 
> PS: I understand the point of multiple MX with the same priority for 
> load balancing.  The question is what's the point of a high priorty 
> server that's always up, and a lower priority server that's, I dunno, 
> probably always up, too.
> 
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 

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






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

[mailop] FW: [EXTERNAL] Re: GMail 550 5.1.1?

2020-12-15 Thread Howard F. Cunningham via mailop 
Hi

Google/Gmail and all Google services have been having problems since yesterday 
morning.

https://downdetector.com/status/gmail/

It seems that Google is having some sort of authentication/validation problem.

hc

Howard Cunningham, MCP
Microsoft Small Business Specialist
Macro Systems, LLC
3867 Plaza Drive
Fairfax, VA 22030
www.macrollc.com
703-359-9211
howa...@macrollc.com - personal
For technical support, send an email to serv...@macrollc.com or call 
703-359-9211 (24/7)


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of John Levine via 
mailop
Sent: Tuesday, December 15, 2020 5:12 PM
To: mailop@mailop.org
Cc: la...@wordtothewise.com
Subject: [EXTERNAL] Re: [mailop] GMail 550 5.1.1?

In article <739cfd79-71ae-4b3c-a9ad-e8db7aa5a...@wordtothewise.com> you write:
>
>Gmail was (and still is) sending out false ‘unknown address’ responses. 
>One person ever reported their own (working, logged
>into) gmail address bouncing. 

I think it's pretty obvious that whatever failed was not something they 
expected to fail, so it's not surprising that it didn't fail in the optimal way.

I'm seeing other odd effects. One of my users has her Gmail account set to pick 
up her mail from my server. That stopped at about 530 AM EST and never resumed. 
We scratched our heads, I suggested she delete the pickup rule and add it 
again, which worked.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop





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

Re: [mailop] [EXTERNAL] Re: O365 contact (or suggestions)

2020-11-06 Thread Howard F. Cunningham via mailop 
HI Simon

If you are purchasing Office 365 through Pax8 (or Ingram Micro/Arrow/TechData 
or other distributors)  and you properly set them up as Global 
Administrator/Helpdesk administrator, they have access to some of the Microsoft 
backend and may be able to help you.

hc


Howard Cunningham, MCP
Microsoft Small Business Specialist
Macro Systems, LLC
3867 Plaza Drive
Fairfax, VA 22030
www.macrollc.com
703-359-9211
howa...@macrollc.com - personal
For technical support, send an email to serv...@macrollc.com or call 
703-359-9211 (24/7)



On 11/5/20 5:47 AM, Simon Burke via mailop wrote:
> Hi,
> 
> So this morning one of our customers has had all their O365 admin accounts 
> stripped of their admin privileges, and various user accounts are spewing out 
> spam.
> 
> Going through normal support channels we're told we're to wait 2-4business 
> days to speak to anyone at Microsoft (Microsoft first line have told us this 
> timescale).
> 
> Is there anyone who can suggest a contact or anything to move this forward?
> 
> NB. Apparently only global admins can change passwords in this environment, 
> so although we can use the 'sign out of all devices' option, we can't change 
> passwords at all currently.
> 
> We are the O365 reseller in this instance.
> 
> Regards,
> Simon.
> 
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop





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

Re: [mailop] Resolving issues for several yahoo domains?

2019-09-05 Thread Howard F. Cunningham via mailop 
Alex

How many connections does Comcast allow from a single source before Comcast 
either starts limiting connections or outright blocks all connections from that 
IP address?

hc


Howard Cunningham, MCP
howa...@macrollc.com - personal
For technical support, send an email to 
serv...@macrollc.com or call 703-359-9211 (24/7)

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Brotman, Alexander 
via mailop
Sent: Thursday, September 05, 2019 11:31 AM
To: '(mailop@mailop.org)'
Subject: Re: [mailop] Resolving issues for several yahoo domains?

One of the interesting things I’ve learned while interacting with ESPs is that 
some of them will artificially restrict the number of messages per session, in 
lieu of opening more sessions. Some of them have told me the values are in the 
low single digits. I’ve kind of wondered the rationale for that might be. Is it 
the idea that you want to get your messages through as quickly as possible?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: mailop  On Behalf Of Benjamin BILLON via mailop
Sent: Thursday, September 5, 2019 10:08 AM
To: mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] Resolving issues for several yahoo domains?

> Hate to imagine how much mail is currently trying to get into Yahoo and AOL
Same. Hate also to imagine the day (and night?) of the folks working on fixing 
that.

--
Benjamin

From: Dave Holmes 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:d...@instiller.co.uk>>
Sent: jeudi 5 septembre 2019 15:57
To: Benjamin BILLON 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:bbil...@splio.com>>
Cc: 
mailop@mailop.org
Subject: Re: [mailop] Resolving issues for several yahoo domains?

Not the quickest or easiest to do as a lot of senders will have different 
limits on different IP pools depending on reputation / previous throughput.

I've dropped in a platform wide rule to back off the mail queues when the 
response is encountered - should do the Job.

Hate to imagine how much mail is currently trying to get into Yahoo and AOL

On Thu, 5 Sep 2019 at 14:39, Benjamin BILLON via mailop 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:mailop@mailop.org>>
 wrote:
Yes, everyone.
Some, very few, emails are accepted. I believe their servers are overloaded. I 
suggest everyone to back off a bit, for instance by limiting the number of 
concurrent connections per outbound IP to ... 1. Until it gets better.
Forcing our way through is not gonna work, or help.

The DNS issue seems solved now.

--
Benjamin

From: mailop 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:mailop-boun...@mailop.org>>
 On Behalf Of Dave Holmes via mailop
Sent: jeudi 5 septembre 2019 15:21
To: Ewald Kessler | Webpower 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:ewald.kess...@webpower.nl>>
Cc: mailop 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:mailop@mailop.org>>
Subject: Re: [mailop] Resolving issues for several yahoo domains?

Were seeing large mail queues forming on our side but I think this extends 
beyond the DNS I've not come across this message from Yahoo before.

Error: "421 Service not available, closing transmission channel tnmpmscs"

So whilst we have the DNS resolution (possibly cached) they are dropping 
connections all over the place, same goes for all of their other domains.

Anyone else with issues delivering after DNS resolves


On Thu, 5 Sep 2019 at 10:31, Ewald Kessler | Webpower via mailop 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:mailop@mailop.org>>
 wrote:
Yes, Oath (a.o. Yahoo, AOL) is having serious issues. Their engineers are 
working to resolve the issues.

Regards,
Ewald

On Thu, 5 Sep 2019 at 10:35, tobisworld--- via mailop 
https://r.xdref.com/?id=x85Facni004272&from=mailop-boun...@mailop.org&to=howa...@macrollc.com&url=mailto:mailop@mailop.org>>
 wrote:
We're currently seeing several yahoo domains (ex 
yahoo.de)
 cannot be
resolved any more in DNS. All the responsable nameservers for that
domain do not reply anymore. Only ns4.yahoo.com replies 
from time to
time for 
yahoo.de
 but according to glue record ns4.yahoo.com is not in
charge for 
yahoo.de