Re: [mailop] What's the point of secondary MX servers?
On 12/18/20 3:41 PM, Stefan Bauer via mailop wrote: If i setup for customer-domains MX records in a way, that a third-party is handling/processing meta-data or even mailcontent, i have to inform my customers about that and ask permission. If third-party is outside EU, there is not even a legal basis anymore since a few weeks, that would allow me to do so at all (see privacy shield got canceled). In all cases, I will be held responsible for my customers data unless third-party is signing contracts with me to accept EU privacy laws. EU has severe penalty for companies, breaking the GDPR/DSGVO law. Thank you for the clarification Stefan. Though it sounds to me like it might not be illegal per se. Or rather that it would require you to go through additional hoops and possibly expose you to more liability. Perhaps those are things that you choose not to do. But that still sounds like a choice, not something that's actually illegal. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
Dnia 20.12.2020 o godz. 03:11:45 Ángel via mailop pisze: > > I remember this issue with password change confirmations on Spotify, > > they were using Sendgrid at that time (don't know if still are?) > > Is it a "please input this code to confirm you are the one changing > your password"? That actually makes sense. No, as far as I remember it was a link to reset the forgotten password. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 2020-12-18 at 15:58 +0100, Jaroslaw Rafa via mailop wrote: > > SendGrid. They have a webpage that says "We continue to retry > > messages for up to 72 hours," but they (sometimes?) don't. > > They do for most customers, but for some they don't. > > I remember this issue with password change confirmations on Spotify, > they were using Sendgrid at that time (don't know if still are?) Is it a "please input this code to confirm you are the one changing your password"? That actually makes sense. If the content of the message is no longer needed before it gets delivered, you could skip it (why would you queue for a week an OTP which was valid just for 5 minutes?). There is a RFC with a smtp extension for that, even. I guess Sendgrid api may have as well a parameter to set the maximum time to attempt delivery. So there are a few messages which are low-value themselves and where it is not needed to queue for a long time. For the most part, they SHOULD be retried, though. It's not even hard to do. If you have a “dumb” client which is not able to queue and retry itself, simply point it to an internal MTA (assumed to be always up) and let that one take care of communicating with the world. Quoting rfc 5321: “the give-up time generally needs to be at least 4-5 days” ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
In article <142c9278-dfe9-4dfc-70ab-50dc27264...@linkedin.com> you write: > >It may not be as common, but I don't see a reason to remove the option. Oh, I agree, it's not going away and it usually doesn't hurt (much). In the past I have done surveys of mail servers to see what features they have, such as 8BITMIME (all of them now) and SMTPUTF8 (not many other than Gmail and MS.) The question is whether it's also worth testing the lower priority MX. My position is no, since the vast majority of mail, at least non-spam mail, goes through the highest priority ones. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 2020-12-17 18:17, L. Mark Stone via mailop wrote: Hi John, Unfortunately, many sending clients (newsletters, announcements, etc.) do not retry if the initial delivery fails. So if your primary MX has network issues, doesn't comprise a load balancer in front of multiple MTAs and you are doing system maintenance, you can lose emails in the absence of a secondary MX. Like if your corporate domain was on Gmail earlier this week, for example. I think the "many" is now very few. Back in the day, everybody had to write their own client, or think something like Perl's Net::SMTP was the bee's knees all by itself. Not only do they not queue/retry, in many cases their RFC compliance sucks, and they get dinged by blacklists like the CBL/XBL. (Net::SMTP, without careful use, WILL get you listed. As will several other similar libraries). In my circles, we refer to these as "idiots with keyboards". They know enough to be dangerous. What has happened since this time is that with default/mandatory port 25 blocks in so many places (including web hosting), and those that don't, usually get blacklisted (by bad clients, or more likely infected malware), that they quickly turn out to be not worth using. They certainly won't work thru grey-listing either. Instead, web hosters are offering outbound queuing thru supported servers, managed email environments (thru gmail, or more traditional ESPs) make things so much easier, and don't need any idiots with keyboards. The idiots with keyboards mess something else up. [This is not to say that Net::SMTP and the like have no place. I still use it, but only in very specific circumstances where fail to queue is not an issue as long as I get an error.] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 2020-12-17 18:21, Grant Taylor via mailop wrote: [paraphrased] > I'd think the best way to deliver spam is via a properly configured > > mail server. Well yeah, but including a copy of, say, Exchange or Sendmail in a traditional bit of Desktop or Server malware is easier said than done. I've never seen anything try anything like that. They either have their own SMTP client (which has short timeouts, no failover and custom DNS services that are a hack. Some even bring their own TCP/IP stack), OR, they try to subvert other mail servers (eg: AUTH spoofing). I prefer a slightly different approach. 1) Point the primary MX at a server with nothing listening. It will send TCP Resets. -- I know this as "No Listing", a varient of "Grey Listing". -- I have yet to see any negative side effects wit this. Yes, I should have mentioned it. The idea is to get the connection killed ASAP, without causing the sending server to think it's ultimately going to NDR. It was described as "no-listing" when initially described on Usenet. 2) Point the secondary MX at your main mail server. -- Business as usual. 3) Optionally - Point the tertiary at your backup mail server. 4) Point the last MX at something like Project Tar. An unused IP will timeout, without privacy related concerns of a Project Tar type external thing, and doesn't need any extra software, and may be implementable with some router trickery without needing any hardware either. The other approach is to host some other kind of SMTP tarpit yourself and avoid privacy issues. There are two warnings I have to issue: 1) Spambots almost always have unduly short timeouts, so tarpitting has relatively little deterrent effect on them. 2) If you're not careful, and you get hit a lot, your network might go wierd with hundreds or thousands of stalled connections. When I've forgotten to squeeze down FIN_WAIT, I've had traps pretty much hang and not accept anything. if you want, you can always instrument your own RBL. Do you have any references off hand? If not, I'll go do some digging. "no-list" as mentioned above. I may have mentioned the whole technique way back then on Usenet. So you might even find my postings. But I didn't talk about it that much on open fora. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
In article <20201218191548.gv2...@tron.kom.tuwien.ac.at> you write: >On Thu, Dec 17, 2020 at 08:58:05PM -0500, John Levine via mailop wrote: >> In article <469F9E736EE5DB4A8C04A6F7527268FA01CA03E20B@MACNT35.macro.local> >> you write: >> >Where we have multiple internet connections, we setup MX records for both >> >connections. If one connection is down, >> >email flows through the other one. >> >> That sounds like two equal priority MX records. No problem with that. >> >> Personally I'd use two A records for one name, but whatever. > >Not a good idea if for a domain name the MX service is handled by other >hosts than the services targeting A/ records. I don't want to get >forced to implement something like a HA proxy to separate MX and say web >requests. To point out the obvious, MX records contain the names of the mail server(s), and those names have to be resolved with A and records. That's where I'd use two A records for one name. If you want, you can use the same name for your mail and web servers, but most people other than the tiniest don't. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
John wrote: > > I understand why secondary MX made sense in the 1980s [...] > > 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. Not every sender will handle that situation the way they should, or that you'd expect. There are non-spammers that will give up quicker than they should. (Hell, one of the top banks in the US can't grok tempfails from greylisting and has insisted my personal email address is invalid for over 10 years - while sending me email at that address successfully...) For smaller operations - they haven't all moved to G Suite, Office 365, etc - their colo may experience temporary routing/peering issues for part of the 'net, or if self-hosted there may be longer outages. Their primary addresses or netblocks may also wind up on various blocklists for some reason, and take a long time to get removed. So I still see a use case there for a lower priority MX. For larger operations, we use MX weighting to direct traffic flow to or away from particular datacenters in cases where we didn't need or want to take an entire DC/POP off the air for email - or in preparation for taking them off the air for a time, and while bringing new MTAs online. > 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? The smaller operator use case is probably more likely to have this asymmetry.But IME they're also more likely to have a longer outage, so the spooling of the legit messages may be more useful even if the filtering isn't as thorough on the secondary. It may not be as common, but I don't see a reason to remove the option. --Steve. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
> "JL" == John Levine via mailop writes: JL> But now, in 2020, is there a point to secondary servers? Since 05 or so I've used two MX in geo-distanced datacentres at the same priority. Some senders ony ever use one or the other, but it still works better than anything else i've tested. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 12/18/20 12:34 PM, Stefan Bauer via mailop wrote: Project Tar looks like a privacy nightmare to me. That is a valid concern. One that I personally am not too worried about. But part of that is because I'm only worried about email servers that adhere to proper MX iteration, all of which I control. Routing my mails to a stranger in case senders just don't honor the standard and dont talk to my primary MX. Project Tor is one example of the idea. Someone could implement this in house themselves if they wanted the effect without the risk. I believe it's worth the price of admission. Free + minimal risk given that I have multiple MXs in line before Project Tor. They promise to reject, but who knows. Every time that I've tested, they have rejected with a temporary error stating to try a lower number / higher priority MX. At least in EU/Germany, that is against the law (GDPR/DSGVO) Would you please elaborate? Either on list or direct, your choice. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
Grant, Project Tar looks like a privacy nightmare to me. Routing my mails to a stranger in case senders just don't honor the standard and dont talk to my primary MX. They promise to reject, but who knows. At least in EU/Germany, that is against the law (GDPR/DSGVO) Stefan Von: Grant Taylor via mailop I prefer a slightly different approach. 1) Point the primary MX at a server with nothing listening. It will send TCP Resets. -- I know this as "No Listing", a varient of "Grey Listing". -- I have yet to see any negative side effects wit this. 2) Point the secondary MX at your main mail server. -- Business as usual. 3) Optionally - Point the tertiary at your backup mail server. 4) Point the last MX at something like Project Tar. [1] Project Tar - https://wiki.junkemailfilter.com/index.php/Project_Tar ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On Thu, Dec 17, 2020 at 08:58:05PM -0500, John Levine via mailop wrote: > In article <469F9E736EE5DB4A8C04A6F7527268FA01CA03E20B@MACNT35.macro.local> > you write: > >Where we have multiple internet connections, we setup MX records for both > >connections. If one connection is down, > >email flows through the other one. > > That sounds like two equal priority MX records. No problem with that. > > Personally I'd use two A records for one name, but whatever. Not a good idea if for a domain name the MX service is handled by other hosts than the services targeting A/ records. I don't want to get forced to implement something like a HA proxy to separate MX and say web requests. What's the gain to give up a MX construction which is well-known? Omitting it would generate a lot of work (if MTA software has to be adpated, at least for DNS setup) and maybe a lot of unexpected effects. I do not want get forced to distinguish web services with a prefix "www.". Even the base name of a domain should deliver web pages or other services. The other thing is the MX are like CNAME classless, without the need to fiddle around with A/ records properly and keep them in sync. And I can't use CNAMEs for, because these names get canonified on the sender's end. Johann K. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
We use low priority MX records on newly deployed hosts to be able to monitor the behaviour of these hosts without getting the full load. If all looks sane, we bump the priority after a few hours/days. Stefan -Ursprüngliche Nachricht- Von: John Levine via mailop Gesendet: Donnerstag 17 Dezember 2020 22:29 An: mailop@mailop.org Betreff: [mailop] What's the point of secondary MX servers? 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
Re: [mailop] What's the point of secondary MX servers?
On 12/17/20 3:07 PM, Mark Fletcher via mailop wrote: If this is really an issue, why don't we have backup A records as well? In a way we do, but we call them SRV records and they operate differently. My website is just as important as my MXes, yet I do just fine without A record priorities... To each their own. I agree with John, MX record priorities are an unneeded relic. I obviously disagree. Not in the least of which is how I (and others) leverage MX record priorities as an integral part of email hygiene protection. Something that would not work without MX priority. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
In article <4ba79975-633e-6e2a-211d-9cf3f6eb4...@orlitzky.com> you write: >On 12/17/20 8:22 PM, John R Levine via mailop wrote: >>> Unfortunately, many sending clients (newsletters, announcements, etc.) >>> do not retry if the initial delivery fails. >> >> That's impressively broken. Do you have specific examples? > >SendGrid. They have a webpage that says "We continue to retry messages >for up to 72 hours," but they (sometimes?) don't. > >Good news is, they've been so spammy that I don't care any more. If that's the worst case I agree it's not a problem. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
Dnia 18.12.2020 o godz. 09:44:49 Michael Orlitzky via mailop pisze: > On 12/17/20 8:22 PM, John R Levine via mailop wrote: > >>Unfortunately, many sending clients (newsletters, announcements, etc.) > >>do not retry if the initial delivery fails. > > > >That's impressively broken. Do you have specific examples? > > > > SendGrid. They have a webpage that says "We continue to retry > messages for up to 72 hours," but they (sometimes?) don't. They do for most customers, but for some they don't. I remember this issue with password change confirmations on Spotify, they were using Sendgrid at that time (don't know if still are?) -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub." ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 12/17/20 8:22 PM, John R Levine via mailop wrote: Unfortunately, many sending clients (newsletters, announcements, etc.) do not retry if the initial delivery fails. That's impressively broken. Do you have specific examples? SendGrid. They have a webpage that says "We continue to retry messages for up to 72 hours," but they (sometimes?) don't. Good news is, they've been so spammy that I don't care any more. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 2020-12-18 17:22:13 (+0800), Paul Smith via mailop wrote: On 18/12/2020 01:19, Philip Paeps via mailop wrote: I use the secondary MX as spammerbait... If a client connects to a lower priority MX before talking to the higher priority MX, I probably don't want to hear from them. There's also the opposite anti-spam trick that I've heard of: have two MX records. The higher priority MX just doesn't exist and the real mail server is the lower priority one. Badly written spam software will try the higher one and when that doesn't respond, it'll give up. Well written mail senders try the higher one, then use the lower one when the higher one doesn't respond. https://en.wikipedia.org/wiki/Nolisting That's cute. I hadn't heard of that one. And it can be combined with the trick I'm using too. MX 10 dummy1.example.com. MX 20 real-primary-mail-server.example.com. MX 30 talk-here-first-and-be-blocked.example.com. I'll consider trying that. Thanks for the tip. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 18/12/2020 08:38, ml+mailop--- via mailop wrote: This is somewhat off-topic here, but I guess you would use multiple A records for such a case. Not really. You can't set precedence for that and there is no fallback system defined, so if you set multiple A records for a web site, the browser will pick a random server to go to for a connection, and that's the only one it will try. The one that's picked may be the one that's broken. It's even possible that the web browser will pick a different server for each request, meaning sessions don't work normally. With MX records, there's precedence, and there's a requirement for the client to try all available servers - that doesn't exist with HTTP. Also, you don't have sessions that last more than one connection in SMTP, whereas you do in HTTP(S). -- Paul Paul Smith Computer Services supp...@pscs.co.uk - 01484 855800 -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 18/12/2020 01:19, Philip Paeps via mailop wrote: I use the secondary MX as spammerbait... If a client connects to a lower priority MX before talking to the higher priority MX, I probably don't want to hear from them. There's also the opposite anti-spam trick that I've heard of: have two MX records. The higher priority MX just doesn't exist and the real mail server is the lower priority one. Badly written spam software will try the higher one and when that doesn't respond, it'll give up. Well written mail senders try the higher one, then use the lower one when the higher one doesn't respond. https://en.wikipedia.org/wiki/Nolisting -- Paul Paul Smith Computer Services supp...@pscs.co.uk - 01484 855800 -- Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 Sign up for news & updates at http://www.pscs.co.uk/go/subscribe ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 17.12.20 23:07, Mark Fletcher via mailop wrote: > If this is really an issue, why don't we have backup A records as well? > My website is just as important as my MXes, yet I do just fine without A > record priorities... This is somewhat off-topic here, but I guess you would use multiple A records for such a case. -- Please don't Cc: me, use only the list for replies, even if the mailing list software screws up the reply-to header. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 17.12.20 23:07, Mark Fletcher via mailop wrote: > If this is really an issue, why don't we have backup A records as well? > My website is just as important as my MXes, yet I do just fine without A > record priorities... > > I agree with John, MX record priorities are an unneeded relic. You can use MX priorities on the inside too. For example to specify outgoing or nexthop servers in transport maps and the likes. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 17.12.20 at 22:21h John Levine wrote via mailop: 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. IMHO secondary MX servers with a lower priority had been replaced in the meantime by an intelligent queuing on the client site. -- Regards Jörg Backschues ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 2020-12-18 05:50:44 (+0800), Grant Taylor via mailop wrote: On 12/17/20 2:21 PM, John Levine via mailop wrote: But now, in 2020, is there a point to secondary servers? I believe you answered your own question. It's just that the nuances are different now than they were 10 / 20 / 30 years ago. Mail servers are online all the time, Are they? Can you /guarantee/ that your mail servers are accessible between three (~9 hours a year) and four nines (~1 hour a year)? What about when an oops happens and the server(s) have the wrong configuration. E.g. Gmail returning 500 errors b/c of an internal problem. Or updates. Or Backhoe Bob doing his best to prevent packets from reaching your server(s). Or. Or. Or. Does it matter? In 2020, the sender will queue and retry. If the sender doesn't queue and retry ... it probably wasn't all that important a message in the first place? Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On Thu, Dec 17, 2020 at 1:54 PM Grant Taylor via mailop wrote: > > > Mail servers are online all the time, > > Are they? > > Can you /guarantee/ that your mail servers are accessible between three > (~9 hours a year) and four nines (~1 hour a year)? > > If this is really an issue, why don't we have backup A records as well? My website is just as important as my MXes, yet I do just fine without A record priorities... I agree with John, MX record priorities are an unneeded relic. Mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On December 18, 2020 2:22:14 AM GMT+01:00, John R Levine via mailop wrote: >> Unfortunately, many sending clients (newsletters, announcements, etc.) >> do not retry if the initial delivery fails. > >That's impressively broken. Do you have specific examples? > >Back when I was tuning my greylister I found some rather strange retries, >but I don't recall many senders that didn't retry and didn't look like >spambots. > >Regards, >John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY >Please consider the environment before reading this e-mail. https://jl.ly >___ >mailop mailing list >mailop@mailop.org >https://list.mailop.org/listinfo/mailop I think I experienced that with the New York times morning briefing daily newsletter. This is anecdotal though, I never really investigated. Marcus ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 2020-12-18 05:21:51 (+0800), 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. I use the secondary MX as spammerbait... If a client connects to a lower priority MX before talking to the higher priority MX, I probably don't want to hear from them. A couple of people have suggested real-world reliability benefits to secondary MX servers in 2020 but I see the number of those use cases dwindling. Not only are your servers usually up, the people sending you mail can probably queue for a while when you're down and retry when you're back up. This was more of a problem decades ago, when disks were small and making queueing the sender's problem was less likely to actually work. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
Unfortunately, many sending clients (newsletters, announcements, etc.) do not retry if the initial delivery fails. That's impressively broken. Do you have specific examples? Back when I was tuning my greylister I found some rather strange retries, but I don't recall many senders that didn't retry and didn't look like spambots. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
We configure ours for two reasons: most mailers will retry immediately on some connection errors (even as late as starttls or helo) but only if you have "more" hosts/ips for them to try. With load balancers, there's no other way to tell remote servers to try again quickly. I assume this is similar at least to what you're talking about. The other thing is that we vend an ip to the dns request based on load/availability and closeness to the requestor. Our alt addresses vend other data centers down the list, which helps move the traffic in the first minutes of unavailability before the automated systems catch up and the dns ttl expires. We've considered switching away from this. The added benefit is pretty low, and there is some benefit to having fewer simpler entries for gsuite customers. Ah, we also used multiple mx to roll out changes. Ie, when we rolled out ipv6 addresses, we added it on a higher pref mx first. Brandon On Thu, Dec 17, 2020, 1:25 PM 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
Re: [mailop] What's the point of secondary MX servers?
Hi John, Unfortunately, many sending clients (newsletters, announcements, etc.) do not retry if the initial delivery fails. So if your primary MX has network issues, doesn't comprise a load balancer in front of multiple MTAs and you are doing system maintenance, you can lose emails in the absence of a secondary MX. Like if your corporate domain was on Gmail earlier this week, for example. FWIW, we use DNS Made Easy; it's $25 - $50/year/domain for backup MX services and it's really cheap insurance IMHO. Regards, Mark ___ L. Mark Stone, Founder North America's Leading Zimbra VAR/BSP/Training Partner For Companies With Mission-Critical Email Needs Need more email security & compliance? Ask me about Mimecast! - Original Message - From: "John Levine via mailop" To: mailop@mailop.org Sent: Thursday, December 17, 2020 4:21:51 PM Subject: [mailop] What's the point of secondary MX servers? 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
Re: [mailop] What's the point of secondary MX servers?
On 12/17/20 3:07 PM, Chris via mailop wrote: 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. Oh wow. That's interesting. Sad. But interesting none the less. I've long thought the most effective way successfully send spam is to send it through a properly configured RFC complaint SMTP server. 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. Hum [My bot detection rules on the new IPs is around 60% of total traffic. Damn spot on 100% on the old ones.] O.O 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. This is where Junk Email Filter's Project Tar [1] comes into play. 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. I prefer a slightly different approach. 1) Point the primary MX at a server with nothing listening. It will send TCP Resets. -- I know this as "No Listing", a varient of "Grey Listing". -- I have yet to see any negative side effects wit this. 2) Point the secondary MX at your main mail server. -- Business as usual. 3) Optionally - Point the tertiary at your backup mail server. 4) Point the last MX at something like Project Tar. 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. I like how Project Tar publishes an RBL of bad actors that don't adhere to RFC specific protocol, like pre-greeting traffic. This is nice to feed into SpamAssassin rules. Note: both the primary-MX reject, lower priority MX hang proposals did make the rounds, separately, many years ago on, say, Usenet discussion forums. Do you have any references off hand? If not, I'll go do some digging. I can personally assure you that they really do work, but your precise mileage may vary. I too have had -- what I consider to be -- exceedingly good luck with what I outlined. [1] Project Tar - https://wiki.junkemailfilter.com/index.php/Project_Tar -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 12/17/20 3:29 PM, John R Levine via mailop wrote: If the primary is up, why would anyone be sending mail to the secondary? Some bad actors absolutely love to target lower priority / higher numbered MXs specifically because they tend to have less stringent hygiene filters. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On Thu, Dec 17, 2020 at 05:29:46PM -0500, John R Levine via mailop wrote: > >I use minger to validate secondary mx with the primary for account > >validity, is that not common then? > > If the primary is up, why would anyone be sending mail to the secondary? Some spammers love to hammer all MXes. > R's, > John -- Brian Reichert BSD admin/developer at large ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
I use minger to validate secondary mx with the primary for account validity, is that not common then? If the primary is up, why would anyone be sending mail to the secondary? R's, John Sent from my iPad On 17 Dec 2020, at 21:28, 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 Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
Migration for a start December 18, 2020 10:28 AM, "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
Re: [mailop] What's the point of secondary MX servers?
I use minger to validate secondary mx with the primary for account validity, is that not common then? Sent from my iPad > On 17 Dec 2020, at 21:28, 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 signature.asc Description: PGP signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
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
Re: [mailop] What's the point of secondary MX servers?
On Thu, Dec 17, 2020 at 04:21:51PM -0500, John Levine via mailop wrote: [...] > 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. I see it as a way to direct (most of) the traffic to a particular server. If you have limited resources, the secondary MX might be doing other things as well and if it has to handle the whole mail load it could result in degraded performance of whatever else it is doing. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] What's the point of secondary MX servers?
On 12/17/20 2:21 PM, John Levine via mailop wrote: But now, in 2020, is there a point to secondary servers? I believe you answered your own question. It's just that the nuances are different now than they were 10 / 20 / 30 years ago. Mail servers are online all the time, Are they? Can you /guarantee/ that your mail servers are accessible between three (~9 hours a year) and four nines (~1 hour a year)? What about when an oops happens and the server(s) have the wrong configuration. E.g. Gmail returning 500 errors b/c of an internal problem. Or updates. Or Backhoe Bob doing his best to prevent packets from reaching your server(s). Or. Or. Or. and if they fail for a few minutes or hours, the client servers will queue and retry when they come back. I prefer to have the email be queued on servers that I can control; be it how often the queue automatically flushes, or a manual flush. Or. Or. Or. 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? That is an operational problem. I think that backup MXs need to have full knowledge of valid and invalid recipients. I also think that the should have the same compliment of email hygiene that the primary mail servers do. What purpose do they serve now? I think you know the answer to this and you just don't like it. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
