Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/8/20 4:06 PM, Michael Orlitzky wrote: The driving force behind junkemailfilter.com passed away almost two years ago: Hum. That doesn't call the technology behind it into question. Though it does call into question the longevity of it. Maybe prematurely (?), I removed their lists from our servers shortly thereafter. You should check if that service is still doing anything. It would be quite bad, for example, if the domain junkemailfilter.com expired and if someone else bought it and decided to start accepting your email. Valid concern. Perhaps it's time for me to start creating my own custom SMTP engine to do the same types of tests that JEF-PT does / did. -- Grant. . . . unix || die -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/8/20 6:13 PM, Ashley Dixon wrote: > > It seems like the database is still active, along with the web-site. > For example, > > `nslookup wellsfargo.com.hostkarma.junkemailfilter.com` returns 127.0.0.5, > as > would be expected. > The domain was renewed in 2016 (until 2025), so that's more or less what you'd expect, even if no one has touched it in two years.
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Wed, Apr 08, 2020 at 06:06:52PM -0400, Michael Orlitzky wrote: > The driving force behind junkemailfilter.com passed away almost two > years ago: > > http://www.dvorak.org/blog/2018/08/27/remembering-marc-perkel/ > > Maybe prematurely (?), I removed their lists from our servers shortly > thereafter. You should check if that service is still doing anything. It > would be quite bad, for example, if the domain junkemailfilter.com > expired and if someone else bought it and decided to start accepting > your email. It seems like the database is still active, along with the web-site. For example, `nslookup wellsfargo.com.hostkarma.junkemailfilter.com` returns 127.0.0.5, as would be expected. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/8/20 5:49 PM, Grant Taylor wrote: > > tnetconsulting.net. 604800 IN MX 99 tarbaby.junkemailfilter.com. > The driving force behind junkemailfilter.com passed away almost two years ago: http://www.dvorak.org/blog/2018/08/27/remembering-marc-perkel/ Maybe prematurely (?), I removed their lists from our servers shortly thereafter. You should check if that service is still doing anything. It would be quite bad, for example, if the domain junkemailfilter.com expired and if someone else bought it and decided to start accepting your email.
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/8/20 3:36 PM, Neil Bothwick wrote: So does that mean you have four MX records? Yes. Nolist server Primary MX Backup MX Project Tar server in order of decreasing priority? Exactly. (1) $ dig +short +noshort mx tnetconsulting.net | sort tnetconsulting.net. 604800 IN MX 10 graymail.tnetconsulting.net. tnetconsulting.net. 604800 IN MX 15 tncsrv06.tnetconsulting.net. tnetconsulting.net. 604800 IN MX 20 tncsrv05.tnetconsulting.net. tnetconsulting.net. 604800 IN MX 99 tarbaby.junkemailfilter.com. (1) They aren't always returned in order do to round-robin DNS. But things that use MX records know to sort based on MX weight. -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, 6 Apr 2020 14:06:29 -0600, Grant Taylor wrote: > I used to be a strong advocate of greylisting. I had some of the > problems that have been described. Then I switched to Nolisting, a > close varient of greylisting that I haven't seen any of the same (or > any) problems with. > > If a sending email server follows the RFCs and tries multiple MXs, then > email gets through in seconds instead of having to re-try and wait for > a greylist timeout. So does that mean you have four MX records? Nolist server Primary MX Backup MX Project Tar server in order of decreasing priority? -- Neil Bothwick Being defeated is a temporary condition. Giving up is what makes it permanent pgpvOLKN0OYoT.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/8/20 7:39 AM, Grant Edwards wrote: NB: The cheap VPS instances that I work with do have static IP addresses, but they share that static IP with a bunch of other VPS instances. If you want your VPS to have a non-shared static IP address, then make sure that's what you're signing up for (it costs more). I think we're thinking two different things for VPS. I'm thinking Virtual Private Server, as in a Virtual Machine. I've not seen any Virtual Private Servers that re-use the same IP as other Virtual Private Servers. It sounds to me like you might be talking about Virtual Hosting of web sites, which do tend to put multiple web sites on the same IP. -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Wed, Apr 08, 2020 at 01:39:15PM -, Grant Edwards wrote: > On 2020-04-08, Grant Taylor wrote: > > > If all you're after is a static IP and aren't worried about sending > > email from it, you can get a cheap VPS and establish a VPN from your > > house to it. Use the static IP of said VPS as your home static IP. }:-) > > NB: The cheap VPS instances that I work with do have static IP > addresses, but they share that static IP with a bunch of other VPS > instances. If you want your VPS to have a non-shared static IP > address, then make sure that's what you're signing up for (it costs > more). After multiple endorsements by various members of the list, I think I'm going to make the leap to Andrews & Arnold when my current Sky subscription expires. Included static IPv4 and IPv6 addresses with knowledgeable support seems very enticing, and this method allows me to retain one-hundred percent control of my server(s). -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, Apr 6, 2020 at 4:02 PM Grant Taylor wrote: > > On 4/6/20 1:03 PM, Rich Freeman wrote: > > More often than not, yes. The main exception I've seen are sites > > that email you verification codes, such as some sorts of "two-factor" > > implementations (whether these are really two-factor I'll set aside > > for now). Many of these services will retry, but some just give up > > after one attempt. > > I believe that's a perfect example of services that should send email > through a local MTA that manages a queue and retries mail delivery. > There is no need for this type of queuing logic and complexity to be in > the application. Especially if the application is otherwise stateless > and runs for the duration of a single HTTP request. Sure, but: 1. We're talking about people who think email is a great solution to 2FA. and 2. Why use a standard MTA when you can build one yourself? I believe this is a corollary to Zawinski's Law. -- Rich
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/6/20 1:16 PM, Michael Orlitzky wrote: Greylisting suffers from one problem that unplugging the server doesn't: greylisting usually works on a triple like (IP address, sender, recipient), and can therefore continue to reject people who do retry, but retry from a different IP address. This occasionally affects things like Github notifications and requires manual intervention. I used to be a strong advocate of greylisting. I had some of the problems that have been described. Then I switched to Nolisting, a close varient of greylisting that I haven't seen any of the same (or any) problems with. If a sending email server follows the RFCs and tries multiple MXs, then email gets through in seconds instead of having to re-try and wait for a greylist timeout. There's also no issue with (re)trying from different IPs. (I would still recommend greylisting, personally, but it's a harder sell than that of foregoing a secondary MX.) Greylisting, or better, nolisting is a very good thing. See my other email for why I disagree about foregoing additional MXs. -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/6/20 1:03 PM, Rich Freeman wrote: More often than not, yes. The main exception I've seen are sites that email you verification codes, such as some sorts of "two-factor" implementations (whether these are really two-factor I'll set aside for now). Many of these services will retry, but some just give up after one attempt. I believe that's a perfect example of services that should send email through a local MTA that manages a queue and retries mail delivery. There is no need for this type of queuing logic and complexity to be in the application. Especially if the application is otherwise stateless and runs for the duration of a single HTTP request. -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/6/20 3:03 PM, Rich Freeman wrote: > > More often than not, yes. The main exception I've seen are sites that > email you verification codes, such as some sorts of "two-factor" > implementations (whether these are really two-factor I'll set aside > for now). Many of these services will retry, but some just give up > after one attempt. Greylisting suffers from one problem that unplugging the server doesn't: greylisting usually works on a triple like (IP address, sender, recipient), and can therefore continue to reject people who do retry, but retry from a different IP address. This occasionally affects things like Github notifications and requires manual intervention. (I would still recommend greylisting, personally, but it's a harder sell than that of foregoing a secondary MX.)
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, Apr 6, 2020 at 12:18 PM Ian Zimmerman wrote: > > On 2020-04-06 14:24, Ashley Dixon wrote: > > > Cheers for the help ! To be honest, I don't think I'd want to receive > > e-mail from someone who cannot resist pressing a button :) > > In fact, "MTAs" that don't retry turn out to be spam robots on close > inspection, more often than not. That is the basis for the spam > fighting tactic called "greylisting". So you will not even be original > in ignoring them. > More often than not, yes. The main exception I've seen are sites that email you verification codes, such as some sorts of "two-factor" implementations (whether these are really two-factor I'll set aside for now). Many of these services will retry, but some just give up after one attempt. Solutions like postgrey make it easy to whitelist particular MTAs or destination addresses to avoid this problem. I won't say that greylisting has solved all my spam problems but it definitely cuts down on it. Also, by delaying never-before-seen MTAs it also makes it more likely that RBLs and such will be updated before the email makes it past greylisting, which will cut down on "zero day" spam. -- Rich
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, Apr 06, 2020 at 09:18:10AM -0700, Ian Zimmerman wrote: > In fact, "MTAs" that don't retry turn out to be spam robots on close > inspection, more often than not. That is the basis for the spam > fighting tactic called "greylisting". So you will not even be original > in ignoring them. Hmm, that's an interesting point, thanks :) [Off-Topic] For the moment I have zero anti-spam measures on my mail server (probably not the greatest thing to admit on a public list). I'll add them if required, but so far---a couple of months of on-and-off service---I haven't received any messages which I didn't expect. I suppose bots will start to harvest my addresses from my website and various public keyservers soon, but for now spam hasn't been a concern at all. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
