"We have other IPs we can use if needed, so again, I am less concerned about improving this IP's reputation than I am with not repeating this outcome."
This in itself is a troubling statement. Gaming the system by opening up "a raft of accounts" is as well. Ownership of your traffic and a clear insight into what may be causing the issues are key. Just because an IP isn't on a blocklist doesn't mean the traffic is less than desirable. Best, DaveS On Thu, Sep 3, 2020 at 3:12 PM L. Mark Stone via mailop <mailop@mailop.org> wrote: > Thanks Laura and Chris for your replies, and sorry if I wasn't as precise > in my language as perhaps I should have been. I've been in the email > business since 2005 and have been impressed with the general high > experience level of the posters on this list. I didn't think I needed to be > as specific as I think you wanted me to be -- especially because I was > asking for guidance regarding an optimal MTA IP "warm up" process, and just > using my case as an example of what happens when that process (if one > exists) is not apparently followed. > > 1) So to be clear, none of my nor my customers' domains are on blocklists > presently (nor were they at the time ~2 months ago), nor were/are any of my > MTA's IPs on any public block lists. > > 2) The IP address of the new MTA we attempted to put into limited > production was placed on the internal block lists of Microsoft, Google and > Mimecast (which I resell) the same weekend we put that new MTA into limited > production. Test emails we had sent prior to the production weekend to > those and other service providers all sailed through OK. The outbound email > we fed through the new MTA that weekend was a simply portion of the normal > outbound email we process through our existing MTAs. All of the email > processed through our existing MTAs that weekend was delivered successfully. > > 3) Microsoft's response was that this IP was not eligible for > remediation. I presumed, since none of the bounce messages in the logs > indicated anything regarding email contents, nor anything related to the > sending domains, that this was due to the IP being "new". > > So that was why I titled this thread "MTA Server IP "Warm Up" Reputation > Recommended Best Practices". > > We have other IPs we can use if needed, so again, I am less concerned > about improving this IP's reputation than I am with not repeating this > outcome. > > No one has yet indicated a better process for warming up an IP than > essentially "send some email" -- that's not something we can do with our > customers' production email flows. So if we need first to set up a > separate domain or two, and open a raft of Yahoo, Gmail and Outlook.com > accounts as destinations to create a reputation for an IP where we can > afford to have these emails blocked, and; then deal with any bounce > messages etc., OK. That process seems... sub-optimal at best. > > If anyone has a better process for warming up sending MTA IPs, I would be > grateful. > > With best regards to all, > Mark > ___________________________________________ > L. Mark Stone, Founder > Mission Critical Email LLC > > ----- Original Message ----- > From: "mailop" <mailop@mailop.org> > To: "mailop" <mailop@mailop.org> > Sent: Thursday, September 3, 2020 1:31:03 PM > Subject: Re: [mailop] MTA Server IP "Warm Up" Reputation Recommended Best > Practices > > On 2020-09-03 10:41, Laura Atkins via mailop wrote: > > > What “other block lists” are you on? Knowing that may help identify what > > you did wrong. It’s unusual for IPs to be blocked outright after 3 days > > of mail. What were you sending and to whom were you sending it? Who owns > > the IP? Where is it routed from? How did you acquire the IP address? Is > > it being routed? > > .... > > > This is one of those questions that’s very difficult to actually answer > > in the hypothetical. > > Precisely. We've seen this scenario many times before, new sending IP, > and seems to get listed right away even tho the volumes are kept low at > first. By not paying attention/investigating other listings, you might > not notice the fact that you made a glaring configuration error that > spells "infected!!!!!" to not just DNSBLs, but generalized inbox > filtering as well. But the person thinks it's to do with "new IP", > rather than "new IP with obvious problems". > > We see it all the time, and it's impossible to answer in the hypothetical. > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop