[gentoo-user] Alternate Incoming Mail Server

[gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

Hello,

After many hours of confusing mixtures of pain and pleasure, I have a secure and
well-behaved e-mail server which encompasses all the features I originally
desired. However, in the event that I need to reboot the server (perhaps a
kernel update was added to Portage), I would like to have a miniature mail
server which catches incoming mail if, and only if, my primary server is down.

I have Gentoo installation on an old Raspberry Pi (model B+), and was curious if
such a set-up was possible ? I also want the solution to be as minimal as
possible. I see the problem as three parts:

 (a) Convincing the D.N.S.\ and my router to redirect mail to the alternate
 server, should the default one not be reachable;
 
 (b) Creating the alternate mail server to be as lightweight as possible. I'm
 not even sure if I need an S.M.T.P.\ server (postfix). Would courier-imap do
 the trick on its own (with courier-authlib and mysql) ?

 (c) Moving mail from the alternate server to the main server once the latter
 has regained conciousness. I realise this is a slightly different problem, and
 is not even necessarily _required_ for operation, although it's certainly a
 nice-to-have.

What do you think; is this at all possible ? Has anyone here done anything like
this before ?

Thanks in advance.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 8:35 AM, Ashley Dixon wrote:
> 
> What do you think; is this at all possible ? Has anyone here done anything like
> this before ?
> 

There's no need, the SMTP specification says that senders must retry
every message, and should continue retrying for at least 4 or 5 days:

  https://tools.ietf.org/html/rfc5321#section-4.5.4

Your incoming mail will arrive whenever the server comes back up. We
regularly reboot our MX in the middle of the day and no one notices.
Whatever solution you'd come up with to solve this problem will cause
more downtime than that =)

Re: [gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Mon, Apr 06, 2020 at 08:41:20AM -0400, Michael Orlitzky wrote:
> There's no need, the SMTP specification says that senders must retry
> every message, and should continue retrying for at least 4 or 5 days:
> 
>   https://tools.ietf.org/html/rfc5321#section-4.5.4

That's a relief, cheers.

Excuse the skeptic within me, but is it safe to assume this specification is
strictly followed by all mail-transfer agents ? I.e., are there any common
M.T.A.s which do not continue trying to send for a few days ?

After my thankfully-brief experience with the likes of Microsoft and their
Exchange program, I always question how much impact the content of an R.F.C.
actually has on an implementation.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 9:08 AM, Ashley Dixon wrote:
> On Mon, Apr 06, 2020 at 08:41:20AM -0400, Michael Orlitzky wrote:
>> There's no need, the SMTP specification says that senders must retry
>> every message, and should continue retrying for at least 4 or 5 days:
>>
>>   https://tools.ietf.org/html/rfc5321#section-4.5.4
> 
> That's a relief, cheers.
> 
> Excuse the skeptic within me, but is it safe to assume this specification is
> strictly followed by all mail-transfer agents ? I.e., are there any common
> M.T.A.s which do not continue trying to send for a few days ?
> 

All real MTAs follow the specification. A few email service providers
(think SendGrid, MailChimp, etc.) allow their users to configure how
many retries will be made, and every once in a while you have users who
set it to zero because they see a button and can't resist pushing it.
But those emails are never anything critical to begin with, in my
experience, and it's a rare problem nonetheless.

Re: [gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Mon, Apr 06, 2020 at 09:15:27AM -0400, Michael Orlitzky wrote:
> All real MTAs follow the specification. A few email service providers
> (think SendGrid, MailChimp, etc.) allow their users to configure how
> many retries will be made, and every once in a while you have users who
> set it to zero because they see a button and can't resist pushing it.
> But those emails are never anything critical to begin with, in my
> experience, and it's a rare problem nonetheless.

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 :)

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[gentoo-user] Re: Alternate Incoming Mail Server

[Ian Zimmerman]

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.

-- 
Ian

Re: [gentoo-user] Re: Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Alternate Incoming Mail Server

[Rich Freeman]

On Mon, Apr 6, 2020 at 12:18 PM Ian Zimmerman <itz@very.loosely.org> 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

[Michael Orlitzky]

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

[Grant Taylor]

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

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Alternate Incoming Mail Server

[Grant Taylor]

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

[Michael Orlitzky]

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

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Alternate Incoming Mail Server

[Michael Orlitzky]

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

[Grant Taylor]

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

[Grant Taylor]

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

[Rich Freeman]

On Mon, Apr 6, 2020 at 4:02 PM Grant Taylor
<gtaylor@gentoo.tnetconsulting.net> 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] Alternate Incoming Mail Server

[antlists]

On 06/04/2020 14:08, Ashley Dixon wrote:
> After my thankfully-brief experience with the likes of Microsoft and their
> Exchange program, I always question how much impact the content of an R.F.C.
> actually has on an implementation.

:-)

Okay, it was a long time ago, and it was MS-Mail (Exchange's 
predecessor, for those who can remember back that far), but I had an 
argument with my boss. He was well annoyed with our ISP for complying 
with RFC's because they switched to ESMTP and MS-Mail promptly broke. 
The *ONLY* acceptable reason for terminating a connection is when you 
recieve the command "BYE", so when Pipex sent us the command EHLO, 
MS-Mail promptly dropped the connection ...

Pipex, and I suspect other ISPs, had to implement an extended black list 
of customers who couldn't cope with ESMTP.

Cheers,
Wol

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/11/20 4:08 PM, antlists wrote:
> 
> Okay, it was a long time ago, and it was MS-Mail (Exchange's 
> predecessor, for those who can remember back that far), but I had an 
> argument with my boss. He was well annoyed with our ISP for complying 
> with RFC's because they switched to ESMTP and MS-Mail promptly broke. 
> The *ONLY* acceptable reason for terminating a connection is when you 
> recieve the command "BYE", so when Pipex sent us the command EHLO, 
> MS-Mail promptly dropped the connection ...
> 

Exchange used to do all manner of stupid things, but now that Microsoft
is running it themselves and making money from O365, they seem to have
figured out how to make it send mail correctly. Nowadays they prefer to
cripple Outlook with non-Exchange protocols, so that our users complain
about not having shared calendars when we've had CalDAV integrated with
IMAP for 10+ years.

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/11/20 2:17 PM, Michael Orlitzky wrote:
> Exchange used to do all manner of stupid things, but now that Microsoft
> is running it themselves and making money from O365, they seem to have
> figured out how to make it send mail correctly.

I've found that Exchange / IIS SMTP is fairly standards compliant since 
the early-mid 2000s.

Microsoft has always been making money off of Exchange.  (Presuming 
people are being legal about it.)  Be it CALs, upgrade licensing, etc.

> Nowadays they prefer to cripple Outlook with non-Exchange protocols, 
> so that our users complain about not having shared calendars when 
> we've had CalDAV integrated with IMAP for 10+ years.

CalDAV is decidedly not an email protocol; POP3, IMAP, SMTP.

I'm not aware of Outlook ever claiming support for CalDAV.  It has 
supported POP3, IMAP, SMTP, Exchange proprietary protocols, and likely NNTP.

You can get shared calendaring, address books, and folders without 
Exchange.  I used MAPIlab's Colab product for a number of clients for 
many years circa 2010.  It is (was?) an Outlook add-on that added 
support for accessing a shared PST file.  It worked great in multiple 
client's offices of between 5 and 25 people.  (My bigger clients had 
Exchange.)

So, IMHO, complaining that Outlook doesn't support CalDAV is sort of 
like complaining that Firefox doesn't support SIP telephony.  Could it 
if it wanted to, sure.  Should it, maybe.  Does it, no.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 897 bytes --]

On Sat, Apr 11, 2020 at 02:41:35PM -0600, Grant Taylor wrote:
> On 4/11/20 2:17 PM, Michael Orlitzky wrote:
> > Nowadays they prefer to cripple Outlook with non-Exchange protocols, so
> > that our users complain about not having shared calendars when we've had
> > CalDAV integrated with IMAP for 10+ years.
> 
> CalDAV is decidedly not an email protocol; POP3, IMAP, SMTP.
> 
> I'm not aware of Outlook ever claiming support for CalDAV.  It has supported
> POP3, IMAP, SMTP, Exchange proprietary protocols, and likely NNTP.

The closest you could get on M.S.\ Windows is the  "e-mail"  application,  which
added some limited support  for  CalDAV  but  also  placed  some  rather  severe
restrictions on providers.

C.f. https://www.ctrl.blog/entry/windows-pim-sync-partnersonly.html

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/11/20 4:41 PM, Grant Taylor wrote:
> On 4/11/20 2:17 PM, Michael Orlitzky wrote:
>> Exchange used to do all manner of stupid things, but now that Microsoft
>> is running it themselves and making money from O365, they seem to have
>> figured out how to make it send mail correctly.
> 
> I've found that Exchange / IIS SMTP is fairly standards compliant since 
> the early-mid 2000s.
> 
> Microsoft has always been making money off of Exchange.  (Presuming 
> people are being legal about it.)  Be it CALs, upgrade licensing, etc.

Right, but back then, they already had your money by the time you
realized Exchange was a turd. Now people can cancel their subscription,
and Microsoft has to field support calls when things don't work, so they
have a bit more incentive to do things right.


>> Nowadays they prefer to cripple Outlook with non-Exchange protocols, 
>> so that our users complain about not having shared calendars when 
>> we've had CalDAV integrated with IMAP for 10+ years.
> 
> CalDAV is decidedly not an email protocol; POP3, IMAP, SMTP.
> 
> ...
> 
> So, IMHO, complaining that Outlook doesn't support CalDAV is sort of 
> like complaining that Firefox doesn't support SIP telephony.  Could it 
> if it wanted to, sure.  Should it, maybe.  Does it, no.

Outlook has (shared) calendars and contacts built-in for 20+ years.
What's missing is the support for the standard CalDAV and CardDAV
protocols in addition to the proprietary MS ones.

I agree that an email client shouldn't do calendars and contacts to
begin with, but that battle was lost when I was in high school.

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/11/20 2:08 PM, antlists wrote:
> Okay, it was a long time ago, and it was MS-Mail (Exchange's 
> predecessor, for those who can remember back that far), but I had an 
> argument with my boss. He was well annoyed with our ISP for complying 
> with RFC's because they switched to ESMTP and MS-Mail promptly broke.

I don't recall any RFC (from the time) stating that ESMTP was REQUIRED. 
It may have been a SHOULD.

The ISP chose to make the change that resulted in ESMTP.

Also, I'm fairly sure that MS-Mail didn't include SMTP in any capacity. 
It required an external MS-Mail SMTP gateway, which I Microsoft did 
sell, for an additional cost.

> The *ONLY* acceptable reason for terminating a connection is when you 
> recieve the command "BYE", so when Pipex sent us the command EHLO, 
> MS-Mail promptly dropped the connection ...

I'll agree that what you're describing is per the (then) SMTP state 
machine.  We have sense seen a LOT of discussion about when it is proper 
or not proper to close the SMTP connection.

If the MS-Mail SMTP gateway sent a 5xy error response, it could see how 
it could subsequently close the connection per protocol state machine.

> Pipex, and I suspect other ISPs, had to implement an extended black list 
> of customers who couldn't cope with ESMTP.

If the MS-Mail SMTP gateway hadn't closed the connection and instead 
just returned an error for the command being unknown / unsupported, 
Pipex would have quite likely tried a standard HELO immediately after 
getting the response.

Also, we're talking about the late '90s during the introduction of 
ESMTP, which was a wild west time for SMTP.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[antlists]

On 11/04/2020 21:33, Grant Taylor wrote:
> On 4/11/20 2:08 PM, antlists wrote:
>> Okay, it was a long time ago, and it was MS-Mail (Exchange's 
>> predecessor, for those who can remember back that far), but I had an 
>> argument with my boss. He was well annoyed with our ISP for complying 
>> with RFC's because they switched to ESMTP and MS-Mail promptly broke.
> 
> I don't recall any RFC (from the time) stating that ESMTP was REQUIRED. 
> It may have been a SHOULD.
> 
> The ISP chose to make the change that resulted in ESMTP.

Yes. But as per spec ESMTP was/is compatible with SMTP.
> 
> Also, I'm fairly sure that MS-Mail didn't include SMTP in any capacity. 
> It required an external MS-Mail SMTP gateway, which I Microsoft did 
> sell, for an additional cost.

Yes, it is the gateway I'm talking about ...

Which was also a pain in the neck because it was single-threaded - if 
the ISP tried to send an incoming email at the same time the gateway 
tried to send, the gateway hung. You could pretty much guarantee most 
mornings I'd be in the server room deleting a bunch of private emails 
from the outgoing queue, and repeatedly rebooting until the queues in 
both directions managed to clear.
> 
>> The *ONLY* acceptable reason for terminating a connection is when you 
>> recieve the command "BYE", so when Pipex sent us the command EHLO, 
>> MS-Mail promptly dropped the connection ...
> 
> I'll agree that what you're describing is per the (then) SMTP state 
> machine.  We have sense seen a LOT of discussion about when it is proper 
> or not proper to close the SMTP connection.

The point is that when the server sends EHLO, it is *not* a *permitted* 
response for the client to drop the connection.
> 
> If the MS-Mail SMTP gateway sent a 5xy error response, it could see how 
> it could subsequently close the connection per protocol state machine.
> 
>> Pipex, and I suspect other ISPs, had to implement an extended black 
>> list of customers who couldn't cope with ESMTP.
> 
> If the MS-Mail SMTP gateway hadn't closed the connection and instead 
> just returned an error for the command being unknown / unsupported, 
> Pipex would have quite likely tried a standard HELO immediately after 
> getting the response.

That was the specification for ESMTP - the client should reject EHLO, 
the server tries again with HELO, and things (supposedly) proceed as 
they should. Which they can't, if the client improperly kills the 
connection.
> 
> Also, we're talking about the late '90s during the introduction of 
> ESMTP, which was a wild west time for SMTP.
> 
Which shouldn't have been a problem. ESMTP was designed to fall back 
gracefully to SMTP. But if clients don't behave correctly as per the 
SMTP spec, how can the server degrade gracefully?

Cheers,
Wol

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/11/20 4:13 PM, antlists wrote:
> Which was also a pain in the neck because it was single-threaded - if 
> the ISP tried to send an incoming email at the same time the gateway 
> tried to send, the gateway hung.

Ew.  I can't say as I'm surprised about that, given the nature of SMTP 
servers in the '90s.

I wonder what the licensing would have been to have one machine sending 
outbound and another receiving inbound.  Though that does assume that 
you could have multiple SMTP gateways connected to MS-Mail.

> You could pretty much guarantee most mornings I'd be in the server 
> room deleting a bunch of private emails from the outgoing queue, 
> and repeatedly rebooting until the queues in both directions managed 
> to clear.

Oy vey!

> The point is that when the server sends EHLO, it is *not* a *permitted* 
> response for the client to drop the connection.
> 
> That was the specification for ESMTP - the client should reject EHLO, 
> the server tries again with HELO, and things (supposedly) proceed as 
> they should. Which they can't, if the client improperly kills the 
> connection.

Agreed.

> Which shouldn't have been a problem. ESMTP was designed to fall back 
> gracefully to SMTP. But if clients don't behave correctly as per the 
> SMTP spec, how can the server degrade gracefully?

I wonder how many Sun Sparc boxen were put between Microsoft mail 
infrastructure and the rest of the world in the '90s and '00s.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[J. Roeleveld]

On 6 April 2020 14:35:04 CEST, Ashley Dixon <ash@suugaku.co.uk> wrote:
>Hello,
>
>After many hours of confusing mixtures of pain and pleasure, I have a
>secure and
>well-behaved e-mail server which encompasses all the features I
>originally
>desired. However, in the event that I need to reboot the server
>(perhaps a
>kernel update was added to Portage), I would like to have a miniature
>mail
>server which catches incoming mail if, and only if, my primary server
>is down.
>
>I have Gentoo installation on an old Raspberry Pi (model B+), and was
>curious if
>such a set-up was possible ? I also want the solution to be as minimal
>as
>possible. I see the problem as three parts:
>
>(a) Convincing the D.N.S.\ and my router to redirect mail to the
>alternate
> server, should the default one not be reachable;
> 
>(b) Creating the alternate mail server to be as lightweight as
>possible. I'm
>not even sure if I need an S.M.T.P.\ server (postfix). Would
>courier-imap do
> the trick on its own (with courier-authlib and mysql) ?
>
>(c) Moving mail from the alternate server to the main server once the
>latter
>has regained conciousness. I realise this is a slightly different
>problem, and
>is not even necessarily _required_ for operation, although it's
>certainly a
> nice-to-have.
>
>What do you think; is this at all possible ? Has anyone here done
>anything like
>this before ?
>
>Thanks in advance.

You'd need to install a SMTP server on the backup system and configure it to relay emails to your primary mailserver.

In the DNS you can configure priorities in the MX entries.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Mon, Apr 06, 2020 at 05:24:03PM +0200, J. Roeleveld wrote:
> You'd need to install a SMTP server on the backup system and configure it to
> relay emails to your primary mailserver.
> 
> In the DNS you can configure priorities in the MX entries.

Hi, cheers for your response, however as Michael pointed out, such a server
would be unnecessary. I wasn't aware of the S.M.T.P.\ standard which mandates
M.T.A.s retry for four or five days, and given that my server won't be down for
longer than a few minutes, I think I'm going to stick with a single MX.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Robert Bridge]

On 6 Apr 2020, at 16:35, Ashley Dixon <ash@suugaku.co.uk> wrote:
> 
> On Mon, Apr 06, 2020 at 05:24:03PM +0200, J. Roeleveld wrote:
>> You'd need to install a SMTP server on the backup system and configure it to
>> relay emails to your primary mailserver.
>> 
>> In the DNS you can configure priorities in the MX entries.
> 
> Hi, cheers for your response, however as Michael pointed out, such a server
> would be unnecessary. I wasn't aware of the S.M.T.P.\ standard which mandates
> M.T.A.s retry for four or five days, and given that my server won't be down for
> longer than a few minutes, I think I'm going to stick with a single MX.

It is still commonly considered good practice to have a secondary MX server. I have encountered some DNS control panels which actually refuse to allow you to only configure a single MX record!

Why trust another party to correctly handle your email when your main system is offline?

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 11:51 AM, Robert Bridge wrote:
> 
> It is still commonly considered good practice to have a secondary MX server.

[citation needed]


> Why trust another party to correctly handle your email when your main system is offline?

You're still trusting the sender to do the right thing with a backup MX.
Only now you're trusting them to follow the part of the spec that talks
about backup MX records, rather than the part that talks about retries.

Re: [gentoo-user] Alternate Incoming Mail Server

[J. Roeleveld]

On 6 April 2020 18:02:22 CEST, Michael Orlitzky <mjo@gentoo.org> wrote:
>On 4/6/20 11:51 AM, Robert Bridge wrote:
>> 
>> It is still commonly considered good practice to have a secondary MX
>server.
>
>[citation needed]
>
>
>> Why trust another party to correctly handle your email when your main
>system is offline?
>
>You're still trusting the sender to do the right thing with a backup
>MX.
>Only now you're trusting them to follow the part of the spec that talks
>about backup MX records, rather than the part that talks about retries.

I find that, with a backup MX, I don't seem to loose emails.
I have, however, found evidence of mailservers belonging to big ISPs not retrying emails if there is no response from the singular MX.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 12:19 PM, J. Roeleveld wrote:
> 
> I find that, with a backup MX, I don't seem to loose emails.
> I have, however, found evidence of mailservers belonging to big ISPs not retrying emails if there is no response from the singular MX.
> 

Well, I can't refute an anecdote without more information, but if you're
worried about this you can create the same MX record twice so that the
"backup" is the primary.

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 10:43 AM, Michael Orlitzky wrote:
> Well, I can't refute an anecdote without more information, but if 
> you're worried about this you can create the same MX record twice so 
> that the "backup" is the primary.

That's not going to work as well as you had hoped.

I've run into many MTAs that check things and realize that the hosts in 
multiple MX records resolve to the same IP and treat them as one.

You may get this to work.  But I would never let clients to rely on this.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 1:02 PM, Grant Taylor wrote:
> On 4/6/20 10:43 AM, Michael Orlitzky wrote:
>> Well, I can't refute an anecdote without more information, but if 
>> you're worried about this you can create the same MX record twice so 
>> that the "backup" is the primary.
> 
> That's not going to work as well as you had hoped.
> 
> I've run into many MTAs that check things and realize that the hosts in 
> multiple MX records resolve to the same IP and treat them as one.
> 

Why don't you say which MTA it is that both (a) combines MX records with
different priorities, and (b) doesn't retry messages to the primary MX?

Re: [gentoo-user] Alternate Incoming Mail Server

[J. Roeleveld]

On 6 April 2020 19:14:35 CEST, Michael Orlitzky <mjo@gentoo.org> wrote:
>On 4/6/20 1:02 PM, Grant Taylor wrote:
>> On 4/6/20 10:43 AM, Michael Orlitzky wrote:
>>> Well, I can't refute an anecdote without more information, but if 
>>> you're worried about this you can create the same MX record twice so
>
>>> that the "backup" is the primary.
>> 
>> That's not going to work as well as you had hoped.
>> 
>> I've run into many MTAs that check things and realize that the hosts
>in 
>> multiple MX records resolve to the same IP and treat them as one.
>> 
>
>Why don't you say which MTA it is that both (a) combines MX records
>with
>different priorities, and (b) doesn't retry messages to the primary MX?

I have missed emails coming from mailing lists, this one for example, due to no retries.
The proof for that is that I got replies to emails I never received.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Alternate Incoming Mail Server

[Robert Bridge]

On 6 Apr 2020, at 18:20, J. Roeleveld <joost@antarean.org> wrote:
> 
> On 6 April 2020 19:14:35 CEST, Michael Orlitzky <mjo@gentoo.org> wrote:
>>> On 4/6/20 1:02 PM, Grant Taylor wrote:
>>> On 4/6/20 10:43 AM, Michael Orlitzky wrote:
>>>> Well, I can't refute an anecdote without more information, but if 
>>>> you're worried about this you can create the same MX record twice so
>> 
>>>> that the "backup" is the primary.
>>> 
>>> That's not going to work as well as you had hoped.
>>> 
>>> I've run into many MTAs that check things and realize that the hosts
>> in 
>>> multiple MX records resolve to the same IP and treat them as one.
>>> 
>> 
>> Why don't you say which MTA it is that both (a) combines MX records
>> with
>> different priorities, and (b) doesn't retry messages to the primary MX?
> 
> I have missed emails coming from mailing lists, this one for example, due to no retries.
> The proof for that is that I got replies to emails I never received.

But that is just an anecdote. </sarcasm>

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 1:24 PM, Robert Bridge wrote:
> 
> But that is just an anecdote. </sarcasm>
> 

It's very easy to collect evidence of this from the mail logs if you are
correct.

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 1:19 PM, J. Roeleveld wrote:
> 
> I have missed emails coming from mailing lists, this one for example, due to no retries.
> The proof for that is that I got replies to emails I never received.
> 

That doesn't prove that the server never retried, it proves that you
didn't receive one particular message that was sent from the list. The
most common reason for that is that your spam filter blocked the
original message, but not the reply. Retries only happen for 4xx errors
(like "connection timed out," when the server is down) and not for 5xx
errors (like "this is spam, go away").

Re: [gentoo-user] Alternate Incoming Mail Server

[J. Roeleveld]

On 6 April 2020 19:25:13 CEST, Michael Orlitzky <mjo@gentoo.org> wrote:
>On 4/6/20 1:19 PM, J. Roeleveld wrote:
>> 
>> I have missed emails coming from mailing lists, this one for example,
>due to no retries.
>> The proof for that is that I got replies to emails I never received.
>> 
>
>That doesn't prove that the server never retried, it proves that you
>didn't receive one particular message that was sent from the list. The
>most common reason for that is that your spam filter blocked the
>original message, but not the reply. Retries only happen for 4xx errors
>(like "connection timed out," when the server is down) and not for 5xx
>errors (like "this is spam, go away").

The messages were missing due to the MX being unavailable for a short period. Retries were not attempted as I would have received them.

The spam filter is configured with certain mailing lists whitelisted.


--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 1:32 PM, J. Roeleveld wrote:
> 
> The messages were missing due to the MX being unavailable for a short period. Retries were not attempted as I would have received them.
> 
> The spam filter is configured with certain mailing lists whitelisted.
> 

Here is proof that the Gentoo list server retries after ~8 minutes:

Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT
from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable;
from=<gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org>,
to=<michael@orlitzky.com>, proto=ESMTP, helo=<lists.gentoo.org>

Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass
(mailfrom) identity=mailfrom; client-ip=208.92.234.80;
helo=lists.gentoo.org; envelope-from
=gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org;
receiver=<UNKNOWN>

I'm not saying you're lying about what happened, but that the conclusion
you're drawing from it is premature. The Gentoo list server (and every
other real MTA) retries deliveries. If you lost a message, I'd bet
that's not the reason why.

Re: [gentoo-user] Alternate Incoming Mail Server

[Stefan Schmiedl]

"Michael Orlitzky" <mjo@gentoo.org>, 06.04.2020, 19:35:

> On 4/6/20 1:32 PM, J. Roeleveld wrote:
>> 
>> The messages were missing due to the MX being unavailable for a short period. Retries were not attempted as I would have received them.
>> 
>> The spam filter is configured with certain mailing lists whitelisted.
>> 

> Here is proof that the Gentoo list server retries after ~8 minutes:

> Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT
> from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable;
> from=<gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org>,
> to=<michael@orlitzky.com>, proto=ESMTP, helo=<lists.gentoo.org>

> Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass
> (mailfrom) identity=mailfrom; client-ip=208.92.234.80;
> helo=lists.gentoo.org; envelope-from
> =gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org;
> receiver=<UNKNOWN>

> I'm not saying you're lying about what happened, but that the conclusion
> you're drawing from it is premature. The Gentoo list server (and every
> other real MTA) retries deliveries. If you lost a message, I'd bet
> that's not the reason why.

And here's an example for J. Roeleveld's observed missed original
messages:

A few days ago I sent a message to this list. As usual, I received
a bunch of DMARC reports from mailservers rejecting the messages.

> From: "Seznam.cz" <forensicdmarc@seznam.cz>
> This is a spf/dkim authentication-failure report for an email message received
>  from IP 208.92.234.80 on Sun, 05 Apr 2020 22:14:23 +0200.
> 
> The message below did not meet the sending domain's dmarc policy.

The headers of that rejected message start with

> Received: from lists.gentoo.org (unknown [208.92.234.80])
>         by email-smtpd3.ng.seznam.cz (Seznam SMTPD 1.3.108) with ESMTP;
>         Sun, 05 Apr 2020 22:14:22 +0200 (CEST)  

This means that folks @seznam.cz (among others) will not get to see 
this message unless somebody replies to it from a domain that uses 
a less restrictive combination of SPF, DKIM and DMARC rules.

So one possible cause for receiving replies to messages you didn't
receive is the right mixture of configuration of sending domain and
transmitting mail server.

s.

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael]

[-- Attachment #1: Type: text/plain, Size: 4322 bytes --]

This thread has been covered in depth for a while now, but I noticed something 
noteworthy.

On Monday, 6 April 2020 19:13:06 BST Stefan Schmiedl wrote:
> "Michael Orlitzky" <mjo@gentoo.org>, 06.04.2020, 19:35:
> > On 4/6/20 1:32 PM, J. Roeleveld wrote:
> >> The messages were missing due to the MX being unavailable for a short
> >> period. Retries were not attempted as I would have received them.
> >> 
> >> The spam filter is configured with certain mailing lists whitelisted.
> > 
> > Here is proof that the Gentoo list server retries after ~8 minutes:
> > 
> > Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT
> > from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable;
> > from=<gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org>,
> > to=<michael@orlitzky.com>, proto=ESMTP, helo=<lists.gentoo.org>
> > 
> > Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass
> > (mailfrom) identity=mailfrom; client-ip=208.92.234.80;
> > helo=lists.gentoo.org; envelope-from
> > =gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org;
> > receiver=<UNKNOWN>
> > 
> > I'm not saying you're lying about what happened, but that the conclusion
> > you're drawing from it is premature. The Gentoo list server (and every
> > other real MTA) retries deliveries. If you lost a message, I'd bet
> > that's not the reason why.
> 
> And here's an example for J. Roeleveld's observed missed original
> messages:
> 
> A few days ago I sent a message to this list. As usual, I received
> a bunch of DMARC reports from mailservers rejecting the messages.
> 
> > From: "Seznam.cz" <forensicdmarc@seznam.cz>
> > This is a spf/dkim authentication-failure report for an email message
> > received> 
> >  from IP 208.92.234.80 on Sun, 05 Apr 2020 22:14:23 +0200.
> > 
> > The message below did not meet the sending domain's dmarc policy.

The reason your message was *rejected*, rather than failed to be delivered/
gone missing, was because there is a DKIM failure in its headers.  This is not 
the non-delivery failure Joost was talking about when an MX server has gone 
offline.


> The headers of that rejected message start with
> 
> > Received: from lists.gentoo.org (unknown [208.92.234.80])
> > 
> >         by email-smtpd3.ng.seznam.cz (Seznam SMTPD 1.3.108) with ESMTP;
> >         Sun, 05 Apr 2020 22:14:22 +0200 (CEST)
> 
> This means that folks @seznam.cz (among others) will not get to see
> this message unless somebody replies to it from a domain that uses
> a less restrictive combination of SPF, DKIM and DMARC rules.

I would think the @seznam.cz recipient server obliges by following the DMARC 
policy published, but ... the tag "p=none" in _dmarc.xss.de TXT means it 
should neither reject, nor quarantine the message.  :-/

This is what I see here in the headers delivered by Stephan via the gentoo-
user M/L:

Authentication-Results: <my_Vhost_server>;
	dkim=fail header.d=xss.de;      <== DKIM checks failed ==
	spf=pass (sender IP is 208.92.234.80)
[snip ...]

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xss.de; 
s=s1;

h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-
To:Subject:To:Message-ID:From:Date:Sender:Reply-To:Cc:Content-ID:Content-
Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-
Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-
Owner:List-Archive;

bh=IcmyWppZGnE0ObrMblHXHftN8IgNTO770eJL89ETQwQ=;

b=g+t6Zx2l9CbrtDTrLtTlyRMSPvuW4LQZ2s0aBdpPEOjp+jp7IutK42gCOTzgq/BH5Lj+/
TLm3dD7ctngYCiMmPlMQlevvDFteUSgueZ	7vKRd87NpPM9O0G9rd+xT84em298YzVm0GAIBSv/
4hb2StCOaC5TcDkKrtOw1vAc5i30=;

I've split the DKIM header above to illustrate a point.  Assuming the digital 
signatures are correct, the only thing I noticed being different from other 
DKIM headers which do not fail, is the sequence of the various DKIM tags 
above.  I don't know if this is important - the DKIM RFC needs reading more 
than once to understand it - but here it goes:

In other messages the 'bh=' hash is before the 'h=' string.  The sequence of 
tags is:

bh=.....;
h=......;
b=.......

In Stefan's message the sequence is different:

h=......;
bh=.....;
b=.......


Perhaps the order in which recipients servers parse the headers cause the DKIM 
check to fail?

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/7/20 1:10 PM, Michael wrote:
> 
> Perhaps the order in which recipients servers parse the headers cause the DKIM 
> check to fail?
> 

DKIM fails on many mailing lists. This list, for example, modifies your
subject to add "[gentoo user]" but leaves the DKIM signature intact. If
the sender has a p=reject DMARC policy, that can make his messages
"disappear" for recipients who check and enforce DMARC.

Stefan was putting forth another much more plausible explanation for
Joost's "missing" messages: he rejected them.

Blaming lists.gentoo.org (or any other MTA) for not retrying after a 4xx
without evidence is seeing hoof prints and thinking zebras. Ockham's
razor: you fucked up.

Re: [gentoo-user] Alternate Incoming Mail Server

[Stefan Schmiedl]

"Michael Orlitzky" <mjo@gentoo.org>, 07.04.2020, 20:34:

> Blaming lists.gentoo.org (or any other MTA) for not retrying after a 4xx
> without evidence is seeing hoof prints and thinking zebras. Ockham's
> razor: you fucked up.

I'm watching my exim logs right now and can confirm that the
gentoo mailing list server does cope well with greylisting,
i.e. it attempts delivery again after a few minutes.

Also, messages from me to others pass DKIM checks, unless
they are modified by what you suggested:

> DKIM fails on many mailing lists. This list, for example, modifies your
> subject to add "[gentoo user]" but leaves the DKIM signature intact. If
> the sender has a p=reject DMARC policy, that can make his messages
> "disappear" for recipients who check and enforce DMARC.

I'm pretty sure that I'm not the first one to ask, but given that
DMARC and DKIM seem to have become a thing, would it not be "better"
for delivery if the mailing list software removed the DKIM signature
if it modified a header that was signed?

s.

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/7/20 2:54 PM, Stefan Schmiedl wrote:
> 
>> DKIM fails on many mailing lists. This list, for example, modifies your
>> subject to add "[gentoo user]" but leaves the DKIM signature intact. If
>> the sender has a p=reject DMARC policy, that can make his messages
>> "disappear" for recipients who check and enforce DMARC.
> 
> I'm pretty sure that I'm not the first one to ask, but given that
> DMARC and DKIM seem to have become a thing, would it not be "better"
> for delivery if the mailing list software removed the DKIM signature
> if it modified a header that was signed?

It's a tricky question, but I know e.g. Mailman has tried that before.
The RFCs say that you should treat the signature header like a
Received-from header; i.e. leave it alone. Stripping off the signature
can cause other new and exciting problems, like getting you sent to Junk
at the big freemail providers.

I always attempt the simplest solution first: don't modify the message.

Some lists now have clever ways of modifying the "From" so that the
message appears to come from the list, and not from the person who sent
it, but they don't work in 100% of cases either. Off the top of my head,
it involves adding another type of "Sender" header, but that can only be
done if the original message doesn't have one, or something like that.
I'd check the available options in the latest version of Mailman to see
what it can do.

There's a lot of boring work that has been done on this, e.g.

  https://tools.ietf.org/html/rfc6377

but I'm not totally up to date on the best practices. I switched my own
domain to p=none after a few years of pain and suffering, and haven't
looked back.

Re: [gentoo-user] Alternate Incoming Mail Server

[Stefan Schmiedl]

"Michael" <confabulate@kintzios.com>, 07.04.2020, 19:10:

> This thread has been covered in depth for a while now, but I noticed something
> noteworthy.

> On Monday, 6 April 2020 19:13:06 BST Stefan Schmiedl wrote:
>> 
>> And here's an example for J. Roeleveld's observed missed original
>> messages:
>> 
>> A few days ago I sent a message to this list. As usual, I received
>> a bunch of DMARC reports from mailservers rejecting the messages.
>> 
>> > From: "Seznam.cz" <forensicdmarc@seznam.cz>
>> > This is a spf/dkim authentication-failure report for an email message
>> > received> 
>> >  from IP 208.92.234.80 on Sun, 05 Apr 2020 22:14:23 +0200.
>> > 
>> > The message below did not meet the sending domain's dmarc policy.

> The reason your message was *rejected*, rather than failed to be delivered/
> gone missing, was because there is a DKIM failure in its headers.  This is not
> the non-delivery failure Joost was talking about when an MX server has gone
> offline.

As I understood it, were I somebody@seznam.cz, I would not have
received the original message but only the replies to it, hence
observing the same strange behaviour of "missed original message
but received replies" due to issues completely out of somebody's
control.



>> The headers of that rejected message start with
>> 
>> > Received: from lists.gentoo.org (unknown [208.92.234.80])
>> > 
>> >         by email-smtpd3.ng.seznam.cz (Seznam SMTPD 1.3.108) with ESMTP;
>> >         Sun, 05 Apr 2020 22:14:22 +0200 (CEST)
>> 
>> This means that folks @seznam.cz (among others) will not get to see
>> this message unless somebody replies to it from a domain that uses
>> a less restrictive combination of SPF, DKIM and DMARC rules.

> I would think the @seznam.cz recipient server obliges by following the DMARC
> policy published, but ... the tag "p=none" in _dmarc.xss.de TXT means it
> should neither reject, nor quarantine the message.  :-/

It's been a while since I set this up, but according to RFC 7489,
section 6.7 "policies of "p=none" SHOULD NOT modify existing mail 
disposition processing", which I understood as "the receiver can
do what it wants, but I get notified about DMARC related problems".

I'll update the record to quarantine and see what breaks.

> In other messages the 'bh=' hash is before the 'h=' string.  The sequence of
> tags is:

> bh=.....;
> h=......;
> b=.......

> In Stefan's message the sequence is different:

> h=......;
> bh=.....;
> b=.......


> Perhaps the order in which recipients servers parse the headers cause the DKIM
> check to fail?

I really hope that is not the case as the sequence is whatever
exim uses as default sequence. Outgoing mail uses this transport:

  remote_smtp:
    driver = smtp
    dkim_domain = ${lc:${domain:$h_from:}}
    dkim_selector = s1
    dkim_private_key = CONFDIR/dkim/dkim.private.key
    dkim_canon = relaxed

> This is what I see here in the headers delivered by Stephan via the gentoo-
> user M/L:

> Authentication-Results: <my_Vhost_server>;
>         dkim=fail header.d=xss.de;      <== DKIM checks failed ==
>         spf=pass (sender IP is 208.92.234.80)
> [snip ...]

The problem could be that the header list includes things like
  h=...:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
which are not in my original message but are added by the mailing list 
software. So if you received one of my DKIM signed messages directly,
the signature would work, but if you received it after it passed
through a mailing list, your DKIM check would fail because it would
include List-Id in the test and the test would fail.

Michael, you should receive two copies of this message, one via list 
one directly. Could you do me the favour and let me know (offline)
what the Authentication-Results for both messages look like?

Thanks,
s.

Re: [gentoo-user] Alternate Incoming Mail Server

[J. Roeleveld]

On Monday, April 6, 2020 7:35:40 PM CEST Michael Orlitzky wrote:
> On 4/6/20 1:32 PM, J. Roeleveld wrote:
> > The messages were missing due to the MX being unavailable for a short
> > period. Retries were not attempted as I would have received them.
> > 
> > The spam filter is configured with certain mailing lists whitelisted.
> 
> Here is proof that the Gentoo list server retries after ~8 minutes:
> 
> Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT
> from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable;
> from=<gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org>,
> to=<michael@orlitzky.com>, proto=ESMTP, helo=<lists.gentoo.org>
> 
> Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass
> (mailfrom) identity=mailfrom; client-ip=208.92.234.80;
> helo=lists.gentoo.org; envelope-from
> =gentoo-announce+bounces-2524-michael=orlitzky.com@lists.gentoo.org;
> receiver=<UNKNOWN>
> 
> I'm not saying you're lying about what happened, but that the conclusion
> you're drawing from it is premature. The Gentoo list server (and every
> other real MTA) retries deliveries. If you lost a message, I'd bet
> that's not the reason why.

It was a few years ago, so no longer have the logs.
The outage was around 30 minutes (which I still consider a short time) and 
even after a few weeks, the emails didn't appear.

I no longer have this issue as I have 2 MXs in different datacenters.

I am also not willing to disable both MXs to see if this still occurs.

--
Joost

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 11:14 AM, Michael Orlitzky wrote:
> Why don't you say which MTA it is that both (a) combines MX records with
> different priorities, and (b) doesn't retry messages to the primary MX?

You seem to have conflated the meaning of my message.

I only stated that I've seen multiple MTAs to (a) combine MX records.

I never said that those MTAs also didn't (b) retry message delivery.

I have seen the following MTAs do (a) in the past:

  · Microsoft Exchange
  · IIS SMTP service
  · Novell GroupWise
  · Lotus Domino
  · Sendmail
  · Postfix

Those are the ones that come to mind.  I'm sure there are others that I 
ran into less frequently.

My understanding from researching this years ago is that it used to be 
considered a configuration error to have multiple MX records with names 
that resolve to the same IP.  As such, MTAs would combine them / 
deduplicated them to avoid wasted resource consumption.  There is no 
point trying to connect to the same IP, even by a different name, an 
additional time after the previous time failed during the /current/ 
delivery / queue cycle.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 1:44 PM, Grant Taylor wrote:
> On 4/6/20 11:14 AM, Michael Orlitzky wrote:
>> Why don't you say which MTA it is that both (a) combines MX records with
>> different priorities, and (b) doesn't retry messages to the primary MX?
> 
> You seem to have conflated the meaning of my message.
> 
> I only stated that I've seen multiple MTAs to (a) combine MX records.
> 
> I never said that those MTAs also didn't (b) retry message delivery.
> 

Ok, you're right. My suggestion to create multiple records was in
response to the claim that there are MTAs that will try a backup MX, but
won't retry the primary MX, which is false to begin with. Trying to
argue against an untrue premise only muddied the water.

Back to the point: all real MTAs retry messages. You can find bulk
mailers and spam zombies and one or two java "forgot password" webforms
from 1995 that won't retry; but by and large, everyone does. If anyone
has evidence to the contrary, it should be easy to find and present. If,
on the other hand no such MTAs exist, then it's quite pointless to run a
second MX for the five seconds a year that it's useful.

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 11:55 AM, Michael Orlitzky wrote:
> Ok, you're right.

;-)

> My suggestion to create multiple records was in response to the claim 
> that there are MTAs that will try a backup MX, but won't retry the 
> primary MX, which is false to begin with. Trying to argue against an 
> untrue premise only muddied the water.

I will not exclude the possibility of email sending programs that will 
use backup MX(s) and not use the primary MX.  But these are not general 
purpose MTAs.

> Back to the point: all real MTAs retry messages. You can find bulk
> mailers and spam zombies and one or two java "forgot password" webforms
> from 1995 that won't retry; but by and large, everyone does.

By and large, yes all well behaved MTAs do re-try.

The web form is a classic example of what a local queuing MTA is good for.

> If anyone has evidence to the contrary, it should be easy to find 
> and present. If, on the other hand no such MTAs exist, then it's 
> quite pointless to run a second MX for the five seconds a year that 
> it's useful.

I disagree.

   · I've seen connectivity issues break connection between a sending 
host and a primary MX.
      · Receiving side
      · Sending side
      · Breakage in the Internet (outside of the direct providers on the 
ends)
      · combination of the above
   · It's not five seconds a year.
      · It's more likely an hour or two a year, possibly aggregated.
   · You can't control the retry time frame on the sending side.
   · You can control the retry / forward time on secondary MX(s).
   · Messages can be canceled while sitting in sending systems queues.
   · It's much more difficult for someone to interfere with messages 
sitting on your systems.
      · Especially without your knowledge.
   · It's /still/ considered best practice to have /multiple/ inbound MX 
servers.
      · Be it primary / secondary
      · Anycasted instance
      · Other tricks
   · Do you want to tell the CEO that he can't have his email for 36 
hours because you patched the mail server and the sender's system won't 
retry for 35.5 hours?

My professional and personal opinion is that if you're serious about 
email, then you should have multiple inbound MX servers.



-- 
Grant. . . .
unix || die





-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[Michael Orlitzky]

On 4/6/20 3:59 PM, Grant Taylor wrote:
>    · It's not five seconds a year.
>       · It's more likely an hour or two a year, possibly aggregated.
>    · You can't control the retry time frame on the sending side.
>    · You can control the retry / forward time on secondary MX(s).
>    · Messages can be canceled while sitting in sending systems queues.
>    · It's much more difficult for someone to interfere with messages 
> sitting on your systems.
>       · Especially without your knowledge.
>    · It's /still/ considered best practice to have /multiple/ inbound MX 
> servers.
>       · Be it primary / secondary
>       · Anycasted instance
>       · Other tricks
>    · Do you want to tell the CEO that he can't have his email for 36 
> hours because you patched the mail server and the sender's system won't 
> retry for 35.5 hours?
> 
> My professional and personal opinion is that if you're serious about 
> email, then you should have multiple inbound MX servers.
> 

The same RFC suggests how long the sending system should wait to retry:

  Experience suggests that failures are typically transient (the target
  system or its connection has crashed), favoring a policy of two
  connection attempts in the first hour the message is in the queue,
  and then backing off to one every two or three hours.

  The SMTP client can shorten the queuing delay in cooperation with the
  SMTP server.  For example, if mail is received from a particular
  address, it is likely that mail queued for that host can now be sent.
  Application of this principle may, in many cases, eliminate the
  requirement for an explicit "send queues now" function such as ETRN,
  RFC 1985 [36].

If someone decides to configure his mail server to retry only after a
week, then sure, there's not much you can do about it. But it's not
really fair for you to cherry-pick this one specific way that a sender
can ignore the RFC, and claim that because a sender can ignore the RFC
in this way, that it's better to adopt a different architecture that
relies on the sender following the RFC in *another* very specific way
(trying the backup MX sooner than they would retry the primary MX). Why
aren't we pretending the sender will ignore that part of the RFC instead?

The real-life manifestations of these problems are non-existent. Anyone
who reads this thread and still decides to maintain a second MX to
mitigate these purely-hypothetical issues does so only at the risk of
his own free time and money. Caveat emptor =)

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 10:19 AM, J. Roeleveld wrote:
> I find that, with a backup MX, I don't seem to loose emails.

Having multiple email servers of your own, primary, secondary, tertiary, 
etc, makes it much more likely that the email will move from the sending 
systems control to your control.  I think it's fairly obvious that 
having the inbound email somewhere you control it is self evident.

I've run into poorly configured sending servers that will try 
(re)sending once a day / week.  So, you would be waiting on them for 
that day / week to re-send, presuming they do re-send.

Conversely, if you have your own secondary mail server, the inbound 
message will likely land at the secondary mail server seconds ~> minutes 
after being unable to send to the primary mail server.  Thus when your 
primary mail server comes back online minutes later, your secondary can 
send it on to your primary.  Thus a net delay of minutes vs hours / days 
/ week(s).

> I have, however, found evidence of mailservers belonging to big ISPs 
> not retrying emails if there is no response from the singular MX.

I've not noticed this, but I've not been looking for it, and I've had 
secondary email servers for decades.

Note:  You don't have to have and manage your own secondary mail server. 
  You can outsource the task to someone you trust.  The primary thing is 
that there are multiple servers willing to accept responsibility for 
your email.  Be they your servers and / or someone else's servers acting 
as your agent.

General call to everybody:  If you're an individual and you want a 
backup (inbound relay) email server, send me a direct email and we can 
chat.  I want to do what I can to help encourage people to run their own 
servers.  I'm happy to help.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 6:35 AM, Ashley Dixon wrote:
> Hello,

Hi,

> After many hours of confusing mixtures of pain and pleasure, I have 
> a secure and well-behaved e-mail server which encompasses all the 
> features I originally desired.

Full STOP!

I hoist my drink to you and tell the bar keep that your next round is on me.

Very nicely done!!!

In all seriousness, running your own email server is definitely not 
easy.  DNS, web, and database servers are easier.

This is especially true, by an order of magnitude, if you are going to 
be sending email and do all of the necessary things to get other mail 
receivers to be happy with email outbound from your server.

~hat~tip~

> However, in the event that I need to reboot the server (perhaps a 
> kernel update was added to Portage), I would like to have a miniature 
> mail server which catches incoming mail if, and only if, my primary 
> server is down.

Okay....

> I have Gentoo installation on an old Raspberry Pi (model B+), and was 
> curious if such a set-up was possible ?

Can you get a Raspberry Pi to function as a backup server?  Yes.  Do you 
want to do such, maybe, maybe not.

I've seen heavier inbound email load on my backup mail server(s) than I 
have on my main mail server.  This is primarily because some, 
undesirables, send email to the backup email server in the hopes that 
there is less spam / virus / hygiene filtering there.  The thought 
process is that people won't pay to license / install / maintain such 
software on the ""backup email server.

I encourage you to take a look at Junk Email Filter's Project Tar [1].

Aside:  JEF-PT encourages people to add a high order MX to point to 
JEF-PT in the hopes that undesirable email to your domain will hit their 
MX, which will always defer the email and never accept it.  Their hope 
is to attract as many bad actors to their system as they can, where they 
analyze the behavior of the sending system; does it follow RFCs, does it 
try to be a spam cannon, etc.  They look at the behavior, NEVER content, 
and build an RBL.  The provide this RBL for others to use if they 
desire.  —  I have been using, and recommending, JEF-PT for more than a 
decade.

JEF-PT could function as the backup MX in a manner of speaking.  They 
will never actually accept your email.  But they will look like another 
email server to senders.  As such, well behaved senders will queue email 
for later delivery attempts.

> I also want the solution to be as minimal as possible. I see the 
> problem as three parts:

This type of thinking is how you end up with different spam / virus / 
hygiene capabilities between the primary and secondary email systems. 
Hence why many undesirables try secondary email system(s) first.  ;-)

In for a penny, in for a pound.

If you're going to run a filter on your primary mail server, you should 
also run the filter on your secondary mail server(s).

> (a) Convincing the D.N.S.\ and my router to redirect mail to the 
> alternate server, should the default one not be reachable;

DNS is actually trivial.  That's where multiple MX records come in to 
play.  —  This is actually more on the sending system honoring what DNS 
publishes than it is on the DNS server.

Aside:  Were you talking about changing what DNS publishes dynamically 
based on the state of your email server?  If so, there is a lot more 
involved with this, and considerably more gotchas / toe stubbers to deal 
with.

There are some networking tricks that you can do in some situations to 
swing the IP of your email server to another system.  This assumes that 
they are on the same LAN.

  · VRRP is probably the simplest one.
  · Manually moving also works, but is less simple.
  · Scripting is automated manual.
  · Routing is more complex.
     · Involves multiple subnets
     · May involve dynamic routing protocols
     · Manual / scripting ....
  · NAT modification is, problematic

> (b) Creating the alternate mail server to be as lightweight 
> as possible. I'm not even sure if I need an S.M.T.P.\ server 
> (postfix). Would courier-imap do the trick on its own (with 
> courier-authlib and mysql) ?

You will need an SMTP server, or other tricks ~> hacks.  Remember that 
you're receiving email from SMTP servers, so you need something that 
speaks SMTP to them.

Courier IMAP & authlib are not SMTP servers.  I sincerely doubt that 
they could be made to do what you are wanting.

> (c) Moving mail from the alternate server to the main server once 
> the latter has regained conciousness.

SMTP has this down pat in spades.

This is actually what SMTP does, move email from system to system to 
system.  You really are simply talking about conditinally adding another 
system to that list.

Hint:  SMTP is the industry standard solution for what you're wanting to 
do, /including/ getting the email from the alternate server to the main 
server.

> I realise this is a slightly different problem, and is not even 
> necessarily _required_ for operation, although it's certainly a 
> nice-to-have.

It's not really a different problem.

It is really required.  Having the email on an alternate server without 
a way to get the email to the main mail server where all the clients are 
configured to access it is an untenable situation that is tantamount to 
not having the email that goes to the alternate server.

> What do you think; is this at all possible ?

Yes, absolutely possible.

> Has anyone here done anything like this before ?

Yes, absolutely been done before.

What you're asking for can all be hacked together using things other 
than SMTP.  But it is very much that, a hack, cobbled together.

Or, you can use SMTP, which you're already using, and does exactly what 
you're asking to do.

> Thanks in advance.

[1] https://wiki.junkemailfilter.com/index.php/Project_Tar



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 3871 bytes --]

On Mon, Apr 06, 2020 at 11:34:02AM -0600, Grant Taylor wrote:
> On 4/6/20 6:35 AM, Ashley Dixon wrote:
> > Hello,
> 
> Hi,

Hello,

[O.T.] Unfortunately, Grant, I cannot reply to your direct e-mail. My best guess
is that you have a protection method in place in the event that the reverse
D.N.S.\ does not match the forward ? As I'm on a domestic I.P., this is out of
my control (i.e., `nslookup mail.suugaku.co.uk` returns my I.P., but `nslookup
<I.P.>` returns some obscure hostname provided by my I.S.P.).

> I encourage you to take a look at Junk Email Filter's Project Tar [1].
> 
> Aside:  JEF-PT encourages people to add a high order MX to point to JEF-PT
> in the hopes that undesirable email to your domain will hit their MX, which
> will always defer the email and never accept it.  Their hope is to attract
> as many bad actors to their system as they can, where they analyze the
> behavior of the sending system; does it follow RFCs, does it try to be a
> spam cannon, etc.  They look at the behavior, NEVER content, and build an
> RBL.  The provide this RBL for others to use if they desire.  —  I have been
> using, and recommending, JEF-PT for more than a decade.
>
> JEF-PT could function as the backup MX in a manner of speaking.  They will
> never actually accept your email.  But they will look like another email
> server to senders.  As such, well behaved senders will queue email for later
> delivery attempts.

This sounds quite enticing; I'll have a look, thanks :)

> > I also want the solution to be as minimal as possible. I see the problem
> > as three parts:
> 
> This type of thinking is how you end up with different spam / virus /
> hygiene capabilities between the primary and secondary email systems. Hence
> why many undesirables try secondary email system(s) first.  ;-)
> 
> If you're going to run a filter on your primary mail server, you should also
> run the filter on your secondary mail server(s).

I didn't mean to infer that my back-up server would be different to my primary
server, as my primary is rather minimal. And yes, good point, I suppose if
anything, I should have tougher anti-spam measures on my backup MX :)

> > (a) Convincing the D.N.S.\ and my router to redirect mail to the
> > alternate server, should the default one not be reachable;
> 
> DNS is actually trivial.  That's where multiple MX records come in to play.
> —  This is actually more on the sending system honoring what DNS publishes
> than it is on the DNS server.

This is what I was intending to do. I hadn't even considered dynamically playing
with the D.N.S., given that addresses are commonly cached for a short period to
avoid hammering name-servers (?)

> > (b) Creating the alternate mail server to be as lightweight as possible.
> > I'm not even sure if I need an S.M.T.P.\ server (postfix). Would
> > courier-imap do the trick on its own (with courier-authlib and mysql) ?
> 
> You will need an SMTP server, or other tricks ~> hacks.  Remember that
> you're receiving email from SMTP servers, so you need something that speaks
> SMTP to them.
> 
> Courier IMAP & authlib are not SMTP servers.  I sincerely doubt that they
> could be made to do what you are wanting.

Oh my goodness, I feel silly now :) I was considering just using courier to
catch the incoming mail, and then rsync it over to my primary when it comes back
on-line, but using an S.M.T.P.-forwarder certainly seems more elegant.

> Or, you can use SMTP, which you're already using, and does exactly what
> you're asking to do.

Cheers for your help and detailed explanations Grant. Not only will your
suggestions make my humble mail server operate better, but it's also great fun
to set up :)

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 3:17 PM, Ashley Dixon wrote:
> Hello,

Hi,

> [O.T.] Unfortunately, Grant, I cannot reply to your direct e-mail. My 
> best guess is that you have a protection method in place in the 
> event that the reverse D.N.S.\ does not match the forward ?

You're close.  I do require reverse DNS.  I will log a warning if 
forward and reverse don't match, but the email should still flow.  Lack 
of reverse DNS is problematic though.

> As I'm on a domestic I.P., this is out of my control (i.e., `nslookup 
> mail.suugaku.co.uk` returns my I.P., but `nslookup <I.P.>` returns 
> some obscure hostname provided by my I.S.P.).

Oops!

Been there.  Done that.

I've added your mail server's name & IPv4 & IPv6 addresses to my 
/etc/hosts file.  Please try again.  I'll also send you an email from an 
alternate address.

Sadly, it doesn't look like you can use the hack that I've used in the past.

If forward and reverse DNS do match <something>, you can configure your 
outgoing email server to simply use that name when talking to the 
outside world.

Unfortunately, it doesn't look like you can do that because the forward 
DNS doesn't return an A / AAAA record for the name name that the PTR 
returns.

> This sounds quite enticing; I'll have a look, thanks :)

:-)

> I didn't mean to infer that my back-up server would be different to my 
> primary server, as my primary is rather minimal. And yes, good point, 
> I suppose if anything, I should have tougher anti-spam measures on 
> my backup MX :)

For simplicity and consistency sake, I'd encourage you to have the same 
spam / virus / hygiene filtering on all mail servers that you control.

> This is what I was intending to do. I hadn't even considered 
> dynamically playing with the D.N.S., given that addresses are commonly 
> cached for a short period to avoid hammering name-servers (?)

You have influence on how long things are cached for by adjusting the 
TTL value in your DNS.

I say "influence" vs "control" because not all recursive DNS servers 
honor the TTL value that you specify.  Some servers set a lower and / or 
upper bound on the TTL that they will honor.

> Oh my goodness, I feel silly now :) I was considering just using 
> courier to catch the incoming mail, and then rsync it over to my 
> primary when it comes back on-line,

I supposed that you could have a full functional mail server, including 
delivering to mailboxes and then synchronizing the mailboxes between the 
servers.  But that would be more work, and I'm guessing that's contrary 
to the simple alternate server that I think you are after.

> but using an S.M.T.P.-forwarder certainly seems more elegant.

;-)

> Cheers for your help and detailed explanations Grant. Not only will 
> your suggestions make my humble mail server operate better, but it's 
> also great fun to set up :)

You're quite welcome.



-- 
Grant. . . .
unix || die

Re: [gentoo-user] Alternate Incoming Mail Server

[J. Roeleveld]

On Monday, April 6, 2020 11:17:58 PM CEST Ashley Dixon wrote:
> On Mon, Apr 06, 2020 at 11:34:02AM -0600, Grant Taylor wrote:
> > On 4/6/20 6:35 AM, Ashley Dixon wrote:
> > > Hello,
> > 
> > Hi,
> 
> Hello,
> 
> [O.T.] Unfortunately, Grant, I cannot reply to your direct e-mail. My best
> guess is that you have a protection method in place in the event that the
> reverse D.N.S.\ does not match the forward ? As I'm on a domestic I.P.,
> this is out of my control (i.e., `nslookup mail.suugaku.co.uk` returns my
> I.P., but `nslookup <I.P.>` returns some obscure hostname provided by my
> I.S.P.).

I am afraid most (if not all) ISPs will reject emails if the reverse DNS does 
not match.
Using a dynamic range is another "spam" indicator and will also get your 
emails blocked by (nearly) all ISPs.

I would suggest putting your outbound SMTP server on a cheap VM hosted 
somewhere else. Or you get an outbound SMTP-service that allows you to decide 
on domain name and email addresses.

--
Joost

Re: [gentoo-user] Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

On Tue, Apr 07, 2020 at 06:49:08AM +0200, J. Roeleveld wrote:
> I am afraid most (if not all) ISPs will reject emails if the reverse DNS does
> not match. Using a dynamic range is another "spam" indicator and will also
> get your emails blocked by (nearly) all ISPs.
> 
> I would suggest putting your outbound SMTP server on a cheap VM hosted 
> somewhere else. Or you get an outbound SMTP-service that allows you to decide 
> on domain name and email addresses.

I've had a surprisingly-small amount of trouble with that. I've made sure to
correctly configure all the elements I can control, such as D.K.I.M., S.P.F.,
T.L.S.\ encryption, etc., and most common e-mail services (Gmail, Yahoo, and
Outlook) all receive my e-mail with no problems.

Grant's mail server, I assume, is configured with the highest security in mind,
so I can see how a mail server with a dynamic I.P.\ could cause issues in some
contexts. I just wish my I.S.P.\ offered _any_ sort of static I.P.\ package, but
given that I live in remote area in the north of England, I.S.P.s aren't exactly
plentiful.

-- 

Ashley Dixon
suugaku.co.uk

2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/7/20 4:53 AM, Ashley Dixon wrote:
> Grant's mail server, I assume, is configured with the highest security 
> in mind, so I can see how a mail server with a dynamic I.P. could 
> cause issues in some contexts.

I don't do any checking to see if the IP is from a dynamic net block or 
not.  Some people do.

> I just wish my I.S.P. offered _any_ sort of static I.P. package, 
> but given that I live in remote area in the north of England, I.S.P.s 
> aren't exactly plentiful.

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.  }:-)



-- 
Grant. . . .
unix || die





-- 
Grant. . . .
unix || die

[gentoo-user] Re: Alternate Incoming Mail Server

[Grant Edwards]

On 2020-04-08, Grant Taylor <gtaylor@gentoo.tnetconsulting.net> 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).

--
Grant

Re: [gentoo-user] Re: Alternate Incoming Mail Server

[Ashley Dixon]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Wed, Apr 08, 2020 at 01:39:15PM -0000, Grant Edwards wrote:
> On 2020-04-08, Grant Taylor <gtaylor@gentoo.tnetconsulting.net> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Re: Alternate Incoming Mail Server

[Grant Taylor]

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

[gentoo-user] Re: Alternate Incoming Mail Server

[Grant Edwards]

On 2020-04-08, Grant Taylor <gtaylor@gentoo.tnetconsulting.net> wrote:
> 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.

No, what I'm talking about are vendor-provisioned RedHat VMs.  I was
having problems sending emails from my server due to lack of reverse
DNS for the IP in question.  When I asked the provider if they could
set up reverse DNS for that IP, they said no they can't because that
IP is shared with other VM hosts. Therefore, it's not possible for
them to map that static IP address to my FQDN.  IIRC, I send email
through sendgrid.  If I wanted sole usage of a static IP (which would
allow reverse DNS), I'd have to move up a tier in the product list and
pay more.

That said, the VM in question does have two virtual web hosts (with
separate FQDNs) which would share the same IP even if I did cough for
the next higher tier where that VM has sole ownership of a static IP.
I only need to send mail from one of the two FQDNs that poit to that
IP, so that would be OK.

--
Grant

Re: [gentoo-user] Alternate Incoming Mail Server

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

On Tue, 7 Apr 2020 11:53:16 +0100, Ashley Dixon wrote:

> given that I live in remote area in the north of England, I.S.P.s
> aren't exactly plentiful.

Zen Internet are a premium ISP and give static IPs - and they are in the
north of England. I'm told that Plusnet will also give you a static IP if
you ask nicely.


-- 
Neil Bothwick

Pound for pound, the amoeba is the most vicious animal on the earth.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] Alternate Incoming Mail Server

[antlists]

On 07/04/2020 11:53, Ashley Dixon wrote:
> Grant's mail server, I assume, is configured with the highest security in mind,
> so I can see how a mail server with a dynamic I.P.\ could cause issues in some
> contexts. I just wish my I.S.P.\ offered_any_  sort of static I.P.\ package, but
> given that I live in remote area in the north of England, I.S.P.s aren't exactly
> plentiful.

https://www.aa.net.uk/

Andrews and Arnold. From what I know of them, a fair few people who know 
what they're talking about say they're good. Sounds they're like what 
Demon were before Clueless and Witless took them over.

Cheers,
Wol

Re: [gentoo-user] Alternate Incoming Mail Server

[Grant Taylor]

On 4/6/20 10:49 PM, J. Roeleveld wrote:
> I am afraid most (if not all) ISPs will reject emails if the reverse 
> DNS does not match.

My experience has been that there needs to be something for both the 
forward and reverse DNS.  Hopefully they match each other and — and what 
I call — round resolve each other.  Ideally, they round resolve /and/ 
match the SMTP HELO / EHLO name.

I think you can get away with at least the first part.  There will 
likely be warnings, but they probably won't prevent email delivery in 
and of themselves.

> Using a dynamic range is another "spam" indicator and will also get 
> your emails blocked by (nearly) all ISPs.

Yep.

If it's not blatant blocking of believed to be dynamic clients (how is 
left up to the reader's imagination), you start to run into additional 
filtering that may or may not reject the message.

> I would suggest putting your outbound SMTP server on a cheap VM hosted 
> somewhere else. Or you get an outbound SMTP-service that allows you 
> to decide on domain name and email addresses.

Unfortunately the spammers have made many such cheap VMs IP net blocks 
have bad reputations.  I'm starting to see more people blocking the 
cheaper VPS providers.



-- 
Grant. . . .
unix || die