Rick Moen via luv-talk wrote: Rick I am sure for you this seems a small thing; but for me it would be a fairly steep learning curve; if I am forced to abandon "rhn(a)jeack.com.au" ;  I'm not sure there would be the movation to attempt such a thing; but oddly today I had a brief conversation (phone) with a gentleman from Vocus ; who was going to look into whether I was the sole 'user of the domain' ?; if the domain name became available....I might just consider that path ! regards Rohan McLeod

Quoting Rohan McLeod (rhn(a)jeack.com.au): At the time I figured out how to run my own Linux server, I was a tax preparer and staff accountant, with zero IT experience. It took a couple of days to get it right (and, of course, use of a static IP address). The first machine was still my old 486, if memory serves. I actually deferred the problem of domains and DNS until long after setting up my Linux server with SMTP Mail: Fortunately, a friend of mine owned domain 'imat.com', and was glad to make an entry in his DNS for 'hugin.imat.com' pointing to my new Linux server. He kindly keeps that entry valid, which is why I continue to be reachable on my Linux server as 'rick(a)hugin.imat.com'com', as I have been since around 1994. ISTR a friend bought for me the 'linuxmafia.com' domain around 1998, which is perforce when I learned domain administration and authoritative DNS.

Rohan McLeod via luv-talk <luv-talk(a)luv.asn.au> writes: Yes, this is possible. Note that there are two parts to hosting: 1. Hosting the DNS domain. This is easy. There are providers that will do this for free. e.g. https://dns.he.net, although it looks like this particular one is closed beta. Currently they don't support DNSSEC, which may not actually be an issue here. 2. Hosting the email. This one requires keeping up to date with latest SPAM filtering standards, etc. Not so easy, especially if you are short on time. I believe there are third party services you can use to do the spam filtering for you and still use your own mail server, but I haven't had experience here. I personally use a paid account at https://kolabnow.com, and point my domain there. https://protonmail.com looks very interesting too. Step 1 is the urgent part, needed to ensure you keep the domain. Step 2 is required if you actually want to be able to use the domain for receiving emails. -- Brian May <brian(a)linuxpenguins.xyz> https://linuxpenguins.xyz/brian/

Quoting Brian May (brian(a)linuxpenguins.xyz): Yes, indeed it is. I found that the problem decomposes into two subparts, which we'll call (a) and (b): (a) Operate authoritative nameserver software (I recommend NSD) on a fixed IP address. (b) Have a couple of friends who do likewise. You do authoritative slave nameservice for their domains. They do authoritative slave nameservice for yours. :r! whois linuxmafia.com | grep "Name Server" Name Server: NS.PRIMATE.NET Name Server: NS.TX.PRIMATE.NET Name Server: NS1.LINUXMAFIA.COM Name Server: NS3.LINUXMAFIA.COM Name Server: NS6.LINUXMAFIA.COM RFC2182 section 5 recommends minimum 3, maximum 7 authoritative nameservers for a domain, so five is pretty good. I note that a depressingly large number of allegedly professional outsourced DNS providers violate the RFCs with dangerously thin nameservice, e.g.: :r! whois baycon.org | grep "Name Server" Name Server: NS1.BLUEHOST.COM Name Server: NS2.BLUEHOST.COM There, friends, I present: Bluehost, Inc., a supposedly professional hosting company. And that is the sort of incompetence you all too frequently get when you outsource. And worth every penny? ;-> As insurance concerning step (b), I also have in recent years added (c): (c) Check up on your friends, lest they disappoint. E.g., 'Oh, did I neglect to tell you I moved my nameserver to a new IP address two years ago? Dreadfully sorry.' Here is /etc/cron.weekly/mydomains, a barely good enough solution to that verification problem that could be improved with modest effort: #!/bin/sh # mydomains Cron script to sanity-check my domains' SOA records at # all of their authoritative nameservers, as a quick and # dirty way of making sure (1) they're all online and # (2) they're all serving up the same data (or at least # data with the same zonefile serial number). # # The script queries all nameservers for their current # SOA value, and then uses awk to parse out of that # verbose record just the S/N field, which is field #3. # The point is that you can visually spot offline or # aberrant nameservers by their S/Ns being (respectively) # missing or an out-of-step value. # # Written by Rick Moen (rick(a)linuxmafia.com) # $Id: cron.weekly,v 1.03 2011/05/21 00:35:00 rick # Copyright (C) Rick Moen, 2011. Do anything you want with this work. set -o errexit #aka "set -e": exit if any line returns non-true value set -o nounset #aka "set -u": exit upon finding an uninitialised variable test -x /usr/bin/mail || exit 0 test -x /usr/bin/whois || exit 0 test -x /usr/bin/awk || exit 0 test -x /bin/grep || exit 0 test -x /usr/bin/dig || exit 0 { echo "As of 2011-05-21, linuxmafia.com should show five authoritative nameservers:" echo "" echo "ns.primate.net. 198.144.194.12, (Aaron T. Porter)" echo "ns.tx.primate.net. 72.249.38.88 (Aaron T. Porter)" echo "ns3.linuxmafia.com. 63.193.123.122, aka ns.catwhisker.org (David Wolfskill)" echo "ns1.thecoop.net. 66.220.20.163, (Drew Bertola)" echo "ns1.linuxmafia.com. 198.144.195.186 (Rick Moen)" echo "" echo "As of 2011-05-21, unixmercenary.net should show five authoritative nameservers:" echo "" echo "ns.primate.net. 198.144.194.12, (Aaron T. Porter)" echo "ns.tx.primate.net. 72.249.38.88 (Aaron T. Porter)" echo "ns3.linuxmafia.com. 63.193.123.122, aka ns.catwhisker.org (David Wolfskill)" echo "ns1.thecoop.net. 66.220.20.163, (Drew Bertola)" echo "ns1.linuxmafia.com. 198.144.195.186 (Rick Moen)" echo "" echo "If any is missing from reports below, or produces odd data, something is wrong." echo "" echo "Zonefile S/Ns, linuxmafia.com:" echo "" dig -t soa linuxmafia.com. @ns.primate.net. +short | awk '{ print $3 " on ns.primate.net." }' dig -t soa linuxmafia.com. @ns.tx.primate.net. +short | awk '{ print $3 " on ns.tx.primate.net." }' dig -t soa linuxmafia.com. @ns3.linuxmafia.com. +short | awk '{ print $3 " on ns3.linuxmafia.com." }' dig -t soa linuxmafia.com. @ns1.thecoop.net. +short | awk '{ print $3 " on ns1.thecoop.net."}' dig -t soa linuxmafia.com. @ns1.linuxmafia.com. +short | awk '{ print $3 " on ns1.linuxmafia.com."}' echo "" echo "Zonefile S/Ns, unixmercenary.net:" echo "" dig -t soa unixmercenary.net. @ns.primate.net. +short | awk '{ print $3 " on ns.primate.net." }' dig -t soa unixmercenary.net. @ns.tx.primate.net. +short | awk '{ print $3 " on ns.tx.primate.net." }' dig -t soa unixmercenary.net. @ns3.linuxmafia.com. +short | awk '{ print $3 " on ns3.linuxmafia.com." }' dig -t soa unixmercenary.net. @ns1.thecoop.net. +short | awk '{ print $3 " on ns1.thecoop.net."}' dig -t soa unixmercenary.net. @ns1.linuxmafia.com. +short | awk '{ print $3 " on ns1.linuxmafia.com."}' echo "" echo "Authoritative nameservers from whois, linuxmafia.com:" echo "" whois linuxmafia.com | grep 'Name Server' | awk -F: '{ print $2 }' | head -n 7 echo "" echo "Authoritative nameservers from whois, unixmercenary.net:" echo "" whois unixmercenary.net | grep 'Name Server' | awk -F: '{ print $2 }' | head -n 7 echo "" echo "Parent-zone NS records and matching A records (glue), linuxmafia.com:" echo "" dig -t ns linuxmafia.com. @$(dig -t ns com. +short | head -n 1) +nocmd +noquestion +nostats +nocomments echo "" echo "Parent-zone NS records and matching A records (glue), unixmercenary.net:" echo "" dig -t ns unixmercenary.net. @$(dig -t ns net. +short | head -n 1) +nocmd +noquestion +nostats +nocomments echo "" echo "In-domain NS records and matching A records, linuxmafia.com:" echo "" dig -t ns linuxmafia.com. @$(dig -t ns linuxmafia.com. +short | head -n 1) +nocmd +noquestion +nostats +nocomments echo "" echo "In-domain NS records and matching A records, unixmercenary.net:" echo "" dig -t ns unixmercenary.net. @$(dig -t ns unixmercenary.net. +short | head -n 1) +nocmd +noquestion +nostats +nocomments } | mail -s "Domains linuxmafia.com and unixmercenary.net SOA check" rick(a)linuxmafia.com

Quoting Andrew McGlashan (andrew.mcglashan(a)affinityvision.com.au): {sigh} Oh, here we go. Someone just has to justify thin nameservice. Here's the RFC wording: The DNS specification and domain name registration rules require at least two servers for every zone. That is, usually, the primary and one secondary. While two, carefully placed, are often sufficient, occasions where two are insufficient are frequent enough that we advise the use of more than two listed servers. Various problems can cause a server to be unavailable for extended periods - during such a period, a zone with only two listed servers is actually running with just one. Since any server may occasionally be unavailable, for all kinds of reasons, this zone is likely, at times, to have no functional servers at all. On the other hand, having large numbers of servers adds little benefit, while adding costs. At the simplest, more servers cause packets to be larger, so requiring more bandwidth. This may seem, and realistically is, trivial. However there is a limit to the size of a DNS packet, and causing that limit to be reached has more serious performance implications. It is wise to stay well clear of it. More servers also increase the likelihood that one server will be misconfigured, or malfunction, without being detected. It is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others. For zones where even higher reliability is required, four, or even five, servers may be desirable. Two, or occasionally three of five, would be at the local site, with the others not geographically or topologically close to the site, or each other. [...] Matches precisely the lessons of my professional experience, and following those words of wisdom is cheap insurance. I have. Getting by with only two always seems OK until the day it isn't. The 'gosh, I couldn't possibly have anticipated that' scenario typically is _not_ 'two disparate nameservers going down at the same time'. It's more like someone (or your monitoring) calls your attention to the fact that one of them has failed, so now you're down to just one with no redundancy, so you're rummaging for a replacement machine to kickstart and, before Chef can put it into service, some unrelated problem takes the second nameserver down and now all of your domains aren't being served at all except for where they're cached and not past TTL. And you think when you get done with massive firefighting and an embarrassed accounting to the CTO, 'Pity I didn't have three. Maybe those RFC authors were drawing on professional sysadmin experience, or something.'

Quoting Andrew McGlashan (andrew.mcglashan(a)affinityvision.com.au): I've never known any third authoritative nameserver to be directly usable by spammers to cause a domain to DoS itself (which you may recall my saying is exactly what often happens with a backup MX). Also, if SMTP becomes undeliverable for less than four days (the customary 45x delivery timeout for most MTAs; suggested somewhere in RFC 5321) before restoration of service, no mail loss occurs, as it will all get delivered during subsequent retries. (Worst that happens is that senders will get some tempfail DSNs during your downtime.) And, hey, if you cannot figure out how to receive 25/tcp traffic again somewhere in the world within 4 days, I don't think you should call yourself a sysadmin. ;-> By contrast, if all of a domains auth nameservers go on holiday, the moment cached data reaches TTL at any recursive nameserver or host DNS cache, the domain's totally offline from there, all services broken and hardfailed. IMO, that's rather a bit more urgent and severe a breakdown than if incoming SMTP deliveries are merely stuck in a 4-day holding pattern pending your standing up a new MTA host. Using views, I guess? Yeah, don't know offhand. Maybe closely check the BIND9 logs for clues about why some queries are being handed the wrong view data? Double-check the Android 'phone about what network it's on when this happens. (I'm handwaving, there, out of lack of knowledge about what to check on such a smartphone.) Wish I did. It's peculiar, all right.

Quoting Andrew McGlashan (andrew.mcglashan(a)affinityvision.com.au): Could be right. I'd not embarrass myself by saying your guess is right or wrong without checking. ;-> Being specific about scenarios, here: I'm pretty sure that any newly generated mail that triggers a DNS lookup that gets immediate socket failure on all auth nameservers is going to get immediate 45x hard fail. Hmm, a test mail to a non-existent FQDN is a logically identical case, wouldn't you agree? I could be missing something, otherwise, it would appear that in the scenario I describe the failure is immediate. (In my time zone, it's late-ish, and I probably shouldn't be trying to work through even gedankenexperiments. ;-> )

On Sunday, 14 October 2018 7:28:46 PM AEDT Andrew McGlashan via luv-talk wrote: 45x isn't a hard fail, all the 4xx codes are for temporary failures. 45x are for corrupted mailbox, server connection problem, or server storage limit exceeded. # mailq -Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------- 3C48FEE5F 425 Sun Oct 14 11:51:28 root(a)sws.net.au (Host or domain name not found. Name service error for name=test.coker.com.au type=MX: Host not found, try again) test(a)test.coker.com.au It's trivial to test, put in an NS record for a subdomain of one of your domains that points to a system that's well firewalled and refuses to respond to port 53. Then send mail. http://wiki.gandi.net/en/glossary/glue-record The above page has a good description of glue records. You should still have A records that match the glue records (I haven't tested what happens if you don't, it would probably work much of the time and fail in strange and interesting ways). Yes, you get a failure if an authoritative name server says that the name in question doesn't exist. In terms of my example mail sent to test(a)test2.coker.com.au will generate an immediate bounce. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Rick Moen via luv-talk wrote: I think I already mentioned null-mx and tarpit anti-spam techniques upthread, but I'll say it again: example.org IN MX 10 null-mx.example.org example.org IN MX 20 mail.example.org example.org IN MX 30 tarbaby.junkemailfilter.com null-mx should not listen on 25 at all -- this means you'll need a second public IP address. I don't actually know who operates tarbaby.junkemailfilter.com; it's a teergrube and I've been using it forever. For paranoia reasons I should probably host the equivalent in-house, but I have been too lazy to do so, so far. It appears to be this thing: http://wiki.junkemailfilter.com/index.php/Project_tarbaby

Rick Moen via luv-talk wrote: If you *do* set up an SMTP teergrube, I'm interested (so I can copy-paste it).

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, tl;dr -- it's fixed. On 14/10/18 18:29, Andrew McGlashan via luv-talk wrote: NO other device seems to have had any problems with DNS. Shutdown and disabled dnsmasq that was "accidentally" running on OPN Sense firewall (default gateway machine). Still, I'm confused about another issue now. The Android phone, when DNS queries are made, presents as the client IP of the WiFi AP (setup as an AP and NOT as a router with NAT involved)... not sure what is causing that; I have seen it present with it's own client IP properly, but I can't find out what is causing this .... yet. However, every single query from the Android phone when connected to the WiFi access point is getting the proper private (view) answer. Cheers A.

Quoting Kim Oldfield (luv(a)oldfield.wattle.id.au): No, for all I know, they're both massively redundant anycast network clusters spread all over multiple geographic areas, networks, and power grid segments, the way many of the 13 root nameservers are. Of course, this _does_ happen to be Bluehost, Inc., which has a long history as a singularly technically deficient and inept firm, particularly since being acquired and massively downsized. In light of which, I will sleep soundly in the face of doubts about my being unfair. ;->

Quoting russell(a)coker.com.au (russell(a)coker.com.au): Sounds extremely useful. Of course, 8.8.8.8 would be returning the result from cache, so this tells you only whether that one nameserver still has the RR with an expired time to live, right? That's valuable information, of course -- just different from knowing whether the authoritative nameservers are running & returning correct zone information, whether they are still authoritative, and whether glue records exist in the parent zones. Coincidentally, I happen to have written a (fugly) shell script for a similar need: My server (linuxmafia.com aka unixmercenary.net aka hugin.imat.com) lives at my house with an ASDL line as uplink. This past Tuesday, the firm AT&T, which is NOT my ISP but rather (in USA technical jargon) the 'ILEC' (incumbent local exchange carrier) shot in the foot my _actual_ ISP small, highly competent, highly technical firm Raw Bandwidth Communications (the 'CLEC' = competitive local exchange carrier -- taking my entire household's ADSL service offline for 2 days and 7 hours. As a matter of ethics on Tuesday, I sent mail from my fallback mail account to everyone ns1.linuxmafia.com does do authoritative DNS for, advising of downtime. Two days later, when AT&T fixed its hapless gaffe at the local exchange off and restore service, I needed to send matching mail, saying DNS service was back. But I wanted to do it semi-automatically with a script that (1) would tally up a set of all authoritative nameservers for a domain, (2) query each of them for their zonefile S/N for that domain, and (3) report that value for each nameserver. It was the usual Ops rule: Any time you're going to do a bunch of commands more than twice, it's time to script it. Here (pro bono publico) is what I came up with: Date: Fri, 26 Oct 2018 01:18:43 -0700 From: Rick Moen <rick(a)linuxmafia.com> To: Duncan MacKinnon <duncan1(a)gmail.com> Subject: ns1.linuxmafia.com downtime ended Thursday ~3pm local Greetings! This is an advisory about ns1.linuxmafia.com DNS nameserver downtime having ended. Root cause: AT&T (_not_ my ISP) sabotaged my ASDL at their local exchange around 8am Tueday, then took about 2 days and 7 hours to find and fix their problem. All services are back. ns1.linuxmafia.com is back to doing auth. nameservice, as arranged, for the following domains of yours: bluedreamz.com (master) substancez.com (master) substancez.net (master) substancez.org (master) Evidence below is via fugly shell script ~/bin/testns that I just cranked out: #!/bin/bash domain=$1 for ns in $(whois $domain | grep "Name Server" | \ awk '{ print $3 }' | tr '\r\n' ' '); do echo -n $ns 'is '; dig +short @"$ns". $domain. SOA | awk '{print $3}'; done :r! bin/testns bluedreamz.com NS1.LINUXMAFIA.COM is 2010060700 NS1.SVLUG.ORG is 2010060700 :r! bin/testns substancez.com NS1.LINUXMAFIA.COM is 2011052000 NS1.SVLUG.ORG is 2011052000 :r! bin/testns substancez.net NS1.LINUXMAFIA.COM is 2011052000 NS1.SVLUG.ORG is 2011052000 :r! bin/testns substancez.org NS1.LINUXMAFIA.COM is 2010060700 NS1.SVLUG.ORG is 2010060700

On Sunday, 14 October 2018 5:01:41 PM AEDT Andrew McGlashan via luv-talk wrote: daisee.com. 21599 IN NS ns-1221.awsdns-24.org. daisee.com. 21599 IN NS ns-2000.awsdns-58.co.uk. daisee.com. 21599 IN NS ns-912.awsdns-50.net. daisee.com. 21599 IN NS ns-420.awsdns-52.com. If you use "Route 53" (the DNS service from Amazon) then by default you get 4 authoritative name servers such as the above from different regions and different TLDs. I don't know if this is because the Amazon SREs have encountered unusual situations where multiple TLDs have become unavailable for some reason making this sort of thing genuinely necessary or whether they are just going over the top to convince customers that they will get an unreasonable number of "nines" of uptime. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Quoting Andrew McGlashan (andrew.mcglashan(a)affinityvision.com.au): This is the sort of thing I do, with a small circle of friends: We all run authoritative nameservers, and each do secondary for each other. I can offer one somewhat amusing cautionary tale, on a theme of 'people are flaky, and need to be checked up on'. The underlying assumption of mutual secondary nameservice for friends is that each will do the bare minimum to avoid screwing up, if only out of Golden Rule concerns. After all, after initial setup, there's zero work to do. Secondaries just track what the primary does. Should be pretty foolproof, right? Into this idyllic picture steps the Pacific Coast beach town of Santa Cruz, California, across the Santa Cruz Mountains from Silicon Valley and about 150 km south of San Francisco. Santa Cruz is a hippie haven, long home of many fundamentally flaky people, with a laid-back demeanour at sharp odds with Silicon Valley's work ethic. Santa Cruz is best known for its beach-side amusement park and for surfing. I'm told I rankle some Santa Cruzans with my brisk manner and binary logic. 'It's a local motion issue', a friend helpfully explained. Around 2000, a young man named Jacob Hunter launched a Santa Cruz LUG with the wince-worthy name Santa [C]ruz Microsoft-Alternative User Group or SMAUG. (Great, now we're defining ourselves in reference to Microsoft?) Santa Cruzans liked the whimsy and whiff of fantasy. A number of us from VA Linux Systems would occasionally drive over the mountains to help Jacob. Jacob had not bothered to ensure that a suitable Internet domain was available before naming his group. After flailing around a bit, he registered scruz.org . A Linux-oriented business owner in Colorado with the glorious name of Crawford Rainwater underwrote the domain registration. I and five other volunteers stepped forward to do authoritative nameservice, with my ns1.linuxmafia.com serving as master. It all tested well, and we rested in the knowledge that the infrastructure had massive redundancy. Roll forward a couple of years. Cue 'uh-oh' music. One day during a winter storm, my house (where ns1.linuxmafia.com lives) had a few hours without electrical power. When service was restored, I found several people complaining that scruz.org had been completely unresolvable. The period of outage corresponded suspiciously to my house's power outage. Moreover, one of the people complaining most bitterly, and suggesting it was somehow all my fault, was the operator of one of the DNS secondaries for the domain. I smelled a rodent.... After some work using whois and dig, and a couple of telephone calls, I uncovered the full picture. Over those couple of years since domain setups: o Two of the Santa Cruzans had re-IPed their nameservers, and not bothered to inform the master. o Another of the Santa Cruzans had retired his nameserver, and not bothered to inform the master. o Another of the Santa Cruzans' nameservers was working but he'd unilaterally decided to cease serving the scruz.org domain, and not bothered to inform the master. o The fifth secondary operator could no longer be contacted, and both he and his nameserver had simply vanished. The domain showed as having six auth nameservers, but de-facto, after flaky admin defections, it had eroded to one -- thus dropping off the Net during my power outage. I explained said debacle to the assembled (who doubtless assumed I was just being mean, and needed more surfboard time), then fixed the nameservice -- and created weekly cron jobs such as the one I recently posted here to check DNS particulars rather than trusting to friends to not be flaky. SMAUG limped along for a few more years and then collapsed because the Santa Cruzans couldn't be bothered to keep it running.

Quoting Trent W. Buck (trentbuck(a)gmail.com): Well, at work, yeah. But the shoemakers' kids tend to go barefoot. (I'm over being sheepish about this, and have reconciled myself to gradually filling in various 'good enough' kludges, whenever the dry side of the dike starts getting too wet.) Current example of problem-solving automation shooting me in the foot: http://linuxmafia.com/pipermail/conspire/2018-August/009325.html

Quoting Rohan McLeod (rhn(a)jeack.com.au): Care to guess who you reduce that 'large number' to a very small one? You just eschew _obvious_ mistakes. E.g.: 1. SMTP servers require static IP addresses that are from a decent provider (one that doesn't block outbound ports) and allocated from a static IP address netblock. 2. SMTP servers require valid rDNS that matches forward lookup. 3. SMTP servers require correct, strongly asserted SPF RRs. 4. SMTP servers must not have their distro default MTA configurations manually sabotaged to accidentally create an open relay. 5. SMTP servers should have data that matter backed up because all data that matters should be backed up. You might object: not obvious to everyone. True! They are not immediately obvious to someone newly arrived at the notion of running his/her own SMTP server, _but_ OTOH they are pretty much the first things an interested newcomer will find in basic cautions and documentation, _or_ said newcomer will immediately hear on a LUG mailing list if he/she asks 'What requirements should I meet in order to run my own SMTP mail server?' Happily, LUV offers that exact variety of assistance. Quod erat demonstrandum. That reduces Trent's 'large number' to a very small number, namely one: 1. SMTP servers in 2018 need manual, post-install work by the local sysadmin to make the MTA configuration spam-resistant, otherwise the rain of it will annoy until you decide to do that work. That's indeed non-trivial work -- but worth the effort, and not brain-surgery.

Quoting Rohan McLeod (rhn(a)jeack.com.au): I didn't worry about that, but you're very welcome. (That's a verbose, North American alternative to the much more sonorous, cheery, and concise Oz expression. ;-> ) I think it's a really splendid idea. First of all, it wins in the sense of accomplishing the easy parts and deferring the difficult parts. Also, it makes give you something that is yours and can be migrated. Which is to say, domains and related DNS are modular parts of the solution. You can use best of breed for each of the modular pieces. Implement each of them wherever best suits your needs, and bear in mind your freedom to move each to somewhere different.

Quoting Trent W. Buck (trentbuck(a)gmail.com): And the bit about a strongly asserted SPF reference record, making your point further. ;->

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 14/10/18 15:13, Russell Coker via luv-talk wrote: There are alternate rules, you don't have to be a company per se, but you do need to have a product or service as an alternative "reason" to have said domain name. There are plenty of temporary .com.au domain names that are used for competition and/or other marketing purposes that wouldn't fit the ordinary "name" rules. Still, .com.au are meant to be entirely for "commercial purposes". Cheers A.

On Sunday, 14 October 2018 5:44:00 PM AEDT Rohan McLeod via luv-talk wrote: If you want quick hosting, that can be done in a matter of minutes. Once you have a mail server with more than a few domains adding another isn't difficult. These don't appear to be enforced, but I can understand someone wanting to strictly comply with all requirements when doing unusual things. https://www.ato.gov.au/Business/Starting-your-own-business/Before-you-get-s… https://www.business.gov.au/planning/business-structures-and-types/business… To be a sole trader just register for an ABN. https://www.business.gov.au/Registrations/Register-for-an-Australian-Busine… Applying for an ABN is free. You just have to declare that you plan to do some work as a sole trader. Not sure, but it wouldn't do any harm. "Rohan McLeod trading as Jeack Computers" sounds nice. You definitely don't need that. A registered business name which doesn't correlate to the domain name seems unlikely to be well accepted. You aren't trying to convince the people who delegate .com.au (who don't seem to care), you are trying to convince the ISP that owns the name. As you have used jeack in a lot of online correspondence related to Linux stuff, it seems almost like a personal brand for you. Making it some sort of registered business name seems like a good strategy. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/

Rick Moen via luv-talk wrote: This *may* be beyond Rohan's current skill level. Setting up a "good enough" mail server is not terribly hard, but if you've never done it before, there are several gotchas, e.g. * what do you mean my ISP blocks outbound 25 unless I upgrade to a "business grade" ADSL subscription? * what do you mean other MTAs auto-block me because my IP address is listed as being in a "dynamically assigned by the ISP range?" * what do you mean I accidentally became an open gateway for a couple of days, and now RBLs are blacklisting me? * what do you mean I forgot to put rate limiting or 2FA on the SASL, and someone is reading all my mail and maybe privesc'd to root and installed an open-access FTP server and/or bitcoin minerd? * what do you mean I actually get spam again, because I didn't know to do all the little things to stop getting spam? (e.g. null MX, tarpit MX, postscreen, maybe even crm114 if your username is something like "sales") * what do you mean I should have a second, offsite, MX? (and, like, ANY backup regimen?) Rohan, if you don't care about the US government reading your mail, the cheapest and easiest answer will be one of the big mail vendors (like gmail). You can acces them via IMAP/SMTP, no browser required. I don't know if they block Tor. You can pay them a little extra and they'll be the backend for a custom domain you own (e.g. if you want to be rohan(a)example.com, you buy example.com and pay gmail to be the mail server for it). It sounds like you *do* care about that, in which case you should probably stop using email altogether, because enough mail passes through the US that they can work out what's going on anyway. Organize your terror cell using traditional methods, entirely OFFLINE. I think I saw some SOE field manuals about this on gutenberg.net.

Trent W. Buck wrote: Incidentally, anyone using postscreen's "expensive" tests? http://www.postfix.org/POSTSCREEN_README.html#after_220 If so, how do you deal with large mail networks (e.g. bigpond, gmail) retrying from a different IP address? Do you use https://github.com/stevejenkins/postwhite ? Do you use a negative postscreen_dnsbl_whitelist_threshold ? Does it Just Work with no special action?