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
[mailop] What's the point of secondary MX servers?
-Ursprüngliche Nachricht- Von: Grant Taylor via mailop > At least in EU/Germany, that is against the law (GDPR/DSGVO) Would you please elaborate? Either on list or direct, your choice. 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. Stefan ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] nolisting, was What's the point of secondary MX servers?
On 12/18/20 12:29 PM, John Levine via mailop wrote: As I recall some sites were getting stuck on the nolist host for every message. Odd. Perhaps it has something to do with the type of nolisting. Did you have something listening on the IP address? Or was it reserved with nothing there? I've been using nolisting with something that sends a TCP reset for years and am not aware of any problems. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] nolisting, was What's the point of secondary MX servers?
On 18 Dec 2020 19:29:21 -, John Levine via mailop wrote: >As I recall some sites were getting stuck on the nolist host for every >message. That would be the expected result. Few servers retain much in the way of state, beyond an optional "always use the first outgoing IP". The expectation is that the sender will use rotating DNS order for load balancing or failover. 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] 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] GMail 550 5.1.1?
FWIW, partly inspired by this thread, I blogged about the week's Gmail fun here: https://lightmeter.io/googledown-happens-every-day-for-mailops-admins/ Sam. On 16/12/2020 15:34, Dr. Christopher Kunz via mailop wrote: > Am 15.12.20 um 00:56 schrieb Bez Thomas via mailop: >> Anyone else seeing repeated, but intermittent, 550-5.1.1s from Gmail for >> valid addresses? >> >> Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to reach >> does not exist. Please try >> 550-5.1.1 double-checking the recipient's email address for typos or >> 550-5.1.1 unnecessary spaces. Learn more at >> 550 5.1.1 https://support.google.com/mail/?p=NoSuchUser >> > FWIW, this was acknowledged and marked as resolved by Google now [1], and has > been discussed elsewhere [2]. > > [1] > https://www.google.com/appsstatus#hl=en&v=issue&sid=1&iid=a8b67908fadee664c68c240ff9f529ab > [2] https://news.ycombinator.com/item?id=25435916 > > Best regards, > > > --ck > > > ___ > 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?
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] nolisting, was What's the point of secondary MX servers?
In article <4178e3f3-de16-8d62-4810-8785dc095...@spamtrap.tnetconsulting.net>, Grant Taylor via mailop wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 12/18/20 10:22 AM, John Levine via mailop wrote: >> I tried that for a while. I found that some senders took quite a >> while to give up on the nolist host and go to the backup so it caused >> noticable mail delays. > >How much delay were you seeing? It was a while ago, but I think hours. >How did that delay compare to grey listing? Particularly compared to >stateful grey listing and / or sending farms with rotating sending IPs. There's a lot of ways to do greylisting, most of which are overkill. Mine accepts a retry from any address in the same /24 as the original, and whitelists the IP indefinitely after a successful retry. So there is some delay the first time someone sends a message but not after that. As I recall some sites were getting stuck on the nolist host for every message. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", 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 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] nolisting, was What's the point of secondary MX servers?
On 12/18/20 10:22 AM, John Levine via mailop wrote: I tried that for a while. I found that some senders took quite a while to give up on the nolist host and go to the backup so it caused noticable mail delays. How much delay were you seeing? How did that delay compare to grey listing? Particularly compared to stateful grey listing and / or sending farms with rotating sending IPs. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Firefox Relay
> > > > > >"While Relay does not filter for spam, our email partner Amazon SES does > block spam and malware. If Relay forwards > >messages you don’t want, you can update your Relay settings to block > messages from the alias forwarding them" > > "It's your job to filter the spam we send." > > Perhaps not. Firefox and Mozilla have an interesting idea both of how > virtuous they are and how much people care. > I suppose we'll be seeing Mozilla at M3AAWG soon, then? /s If the product lead for this project is listening to mailop (they likely aren't), IMHO they should strongly consider receiving the relay email and forwarding it over a different medium, such as smart phone notifications, Slack, or even just web hooks. Indeed if they allowed folks to configure their own web hook endpoints for relayed messages, then people could route messages however they wish. For that matter, why not have the relay service route messages into users' Firefox accounts and have the messages pop up directly within Firefox? Your Firefox account is a well authenticated, secure channel for receiving messages already. Why not make us of it? Regards, Ken ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Firefox Relay
In article you write: >Interesting enough, guess we will have to wait and see if gains any traction. >Essentially a reputable disposable domain if such a thing exists... actually >according the FAQ's they will be >leveraging Amazon SES. https://relay.firefox.com/faq > >"While Relay does not filter for spam, our email partner Amazon SES does block >spam and malware. If Relay forwards >messages you don’t want, you can update your Relay settings to block messages >from the alias forwarding them" "It's your job to filter the spam we send." Perhaps not. Firefox and Mozilla have an interesting idea both of how virtuous they are and how much people care. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] nolisting, was What's the point of secondary MX servers?
In article <81acc49e-3f6c-0905-a952-f4786841a...@pscs.co.uk> you write: >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. I tried that for a while. I found that some senders took quite a while to give up on the nolist host and go to the backup so it caused noticable mail delays. ___ 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] Firefox Relay
On Fri, Dec 18, 2020 at 6:21 AM Robert Rubenking via mailop < mailop@mailop.org> wrote: > > They also state that anything marked as spam will ding the reputation of > relay service. > "If you report these as spam, your email provider will see Relay as the > source of spam, not the original sender." > > This looks like a fatal flaw. How long before Relay winds up on a lot of blacklists? ___ 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] Firefox Relay
On Fri, Dec 18, 2020 at 11:52:31AM +, Andrew C Aitchison via mailop wrote: > > I note a new service: Firefox Relay > https://relay.firefox.com > >As you browse, the Relay icon will appear in form fields where >sites ask for your email address. Select it to generate a new, >random address that ends in @relay.firefox.com. Relay will forward >messages to the primary email address associated with your account. > > I guess we need to prepare for forwarded emails to our users via a new > intermediate. > > I guess that some email services will either fail to, or chose not to, > accept these messages. anon.penet.fi is reborn :) PG ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Firefox Relay
Interesting enough, guess we will have to wait and see if gains any traction. Essentially a reputable disposable domain if such a thing exists... actually according the FAQ's they will be leveraging Amazon SES. https://relay.firefox.com/faq "While Relay does not filter for spam, our email partner Amazon SES does block spam and malware. If Relay forwards messages you don’t want, you can update your Relay settings to block messages from the alias forwarding them" They also state that anything marked as spam will ding the reputation of relay service. "If you report these as spam, your email provider will see Relay as the source of spam, not the original sender." Bob -Original Message- From: mailop On Behalf Of Andrew C Aitchison via mailop Sent: Friday, December 18, 2020 5:53 AM To: mailop@mailop.org Subject: [mailop] Firefox Relay This email has reached Mapp via an external source I note a new service: Firefox Relay https://relay.firefox.com/ As you browse, the Relay icon will appear in form fields where sites ask for your email address. Select it to generate a new, random address that ends in @relay.firefox.com. Relay will forward messages to the primary email address associated with your account. I guess we need to prepare for forwarded emails to our users via a new intermediate. I guess that some email services will either fail to, or chose not to, accept these messages. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop This e-mail is from Mapp Digital and its international legal entities and may contain information that is confidential or proprietary. If you are not the intended recipient, do not read, copy or distribute the e-mail or any attachments. Instead, please notify the sender and delete the e-mail and any attachments. Please consider the environment before printing. Thank you. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] Firefox Relay
I note a new service: Firefox Relay https://relay.firefox.com/ As you browse, the Relay icon will appear in form fields where sites ask for your email address. Select it to generate a new, random address that ends in @relay.firefox.com. Relay will forward messages to the primary email address associated with your account. I guess we need to prepare for forwarded emails to our users via a new intermediate. I guess that some email services will either fail to, or chose not to, accept these messages. -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ 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] [EXTERNAL] Re: What's the point of secondary MX servers?
On 18/12/2020 08:22, Thomas Walter via mailop wrote: Personally I'd use two A records for one name, but whatever. That's round robin, not "backup"? Systems will "randomly" connect to both connections and fail if one line is down - which was not the intention here. No. It should try both. The order is random, but it should try both of them, so if one is down, it will use the other. RFC 5321 - section 5.1 " When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple MX records, multihoming, or both. To provide reliable mail transmission, the SMTP client MUST be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds." Note that the requirement to try each of the addresses is for multiple MX records *OR* multihoming (multiple A records) -- 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] [EXTERNAL] Re: What's the point of secondary MX servers?
On 18.12.20 02:58, John Levine via mailop wrote: > In article <469F9E736EE5DB4A8C04A6F7527268FA01CA03E20B@MACNT35.macro.local> > you write: >> 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. > > That sounds like two equal priority MX records. No problem with that. > > Personally I'd use two A records for one name, but whatever. That's round robin, not "backup"? Systems will "randomly" connect to both connections and fail if one line is down - which was not the intention here. 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 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
