Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Alessandro Vesely via mailop]

On Tue 25/Feb/2020 12:12:05 +0100 Simon Lyall via mailop wrote:
> 
> Thank you for all the suggestions. I've put together a couple of pages:
> 
> https://www.mailop.org/faq/
> https://www.mailop.org/best-practices/


Some more links:


DNSBL check:
http://multirbl.valli.org/lookup/
http://www.mxtoolbox.com/blacklists.aspx

SPF check:
https://dmarcian.com/spf-survey/
https://tools.wordtothewise.com/spf

Whitelists:
https://www.dnswl.org/?page_id=27


hth
Ale
-- 






















___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Hans-Martin Mosner via mailop]

Am 26.02.2020 22:35, schrieb Michael Peddemors via mailop:

...
* Unsubscribe pages/urls
* Domain Pages


I'm somewhat unsure about this one.
Although nowadays the WWW *is* the internet for many people, running a 
mail server and running a web presence are two different things, and it 
should be absolutely possible to have a domain that only does mail 
services without any fancy newfangled web stuff.
However, I also admit that I tend to look at the web sites of suspicious 
mail sender domains, and what I see often supports my suspicions...


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Michael Peddemors via mailop]

Hehe.. another one.. (You think it would be self obvious)

When you talk about transparency, the idea is that the domain in the PTR 
should have a URL, where contact information related to abuse for/from 
that domain can be found..


97.107.24.93x1  1.outbound1.email-aeg.com
97.107.24.95x1  1.outbound3.email-aeg.com

(triggering one of our invalid user detection tools)

Visit the domain, http://email-aeg.com, and it redirects.. to an 
insecure page.. https://email-aeg.com/YesConnect?page=login


This server could not prove that it is email-aeg.com; its security 
certificate is from *.emailmarketing.com


I don't know if it is EXACTLY an email best practice..

But make sure that your pages have proper SSL's.

* Unsubscribe pages/urls
* Domain Pages

If your page is insecure, no one (and rightly so) will continue to 
unsubscribe, or report to you problems.




On 2020-02-25 3:12 a.m., Simon Lyall via mailop wrote:


Thank you for all the suggestions. I've put together a couple of pages:

https://www.mailop.org/faq/
https://www.mailop.org/best-practices/

as a start. What do people think needs to be added or changed?

Simon.
Mailop Admin Team.





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Jonathan Leroy - Inikup via mailop]

Le mar. 25 févr. 2020 à 21:51, Luis E. Muñoz via mailop
 a écrit :
> This is a TLS Checker that is POP/IMAP/SMTP: aware
> https://esmtp.email/tools/tls

Another, more complete TLS configuration checker: https://cryptcheck.fr/
You can also add Hardenize: https://www.hardenize.com/


> There's also a sibling MTA-STS validator:
> https://esmtp.email/tools/mta-sts

Another one, MTA-STS validator: https://aykevl.nl/apps/mta-sts/


-- 
Jonathan Leroy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Luis E. Muñoz via mailop]

On 25 Feb 2020, at 3:12, Simon Lyall via mailop wrote:

Thank you for all the suggestions. I've put together a couple of 
pages:


https://www.mailop.org/faq/
https://www.mailop.org/best-practices/

as a start. What do people think needs to be added or changed?


This is a TLS Checker that is POP/IMAP/SMTP: aware 
https://esmtp.email/tools/tls


There's also a sibling MTA-STS validator: 
https://esmtp.email/tools/mta-sts


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Michael Peddemors via mailop]

On 2020-02-25 3:12 a.m., Simon Lyall via mailop wrote:


Thank you for all the suggestions. I've put together a couple of pages:

https://www.mailop.org/faq/
https://www.mailop.org/best-practices/

as a start. What do people think needs to be added or changed?

Simon.
Mailop Admin Team.



Thanks Simon for this important step.

It is also something that everyone on the mailing list might 
use/reference and as a result attract more email operators to this list.


* [FUTURE] Support for i18n

https://www.mailop.org/faq/

* What do do if being blocked by a large provider?
  (Might want to also put a link to ..)

Help – I’m on a Blocklist
Updated February 2018, Version 1.0.1 (June 2014)
Shortened URL to this document: www.m3aawg.org/BlocklistHelp

* List to sites to check IP health

 Suggest, that you list both mxtoolbox and Hetrixtools
 And link directly to the IP Blacklists

* Add 'List to sites to check Domain Health'

For the Best Practices Page..

Not 100% sure "if FCrDNS records for all you public-facing IPs that 
match the SMTP HELO and EHLO" correctly describes the issue..


Maybe we need to order it in the form of the most essential requirements 
first, going down to 'suggested' ..


Eg, having an SPF record has now reached the point of being a Best 
Practice, however the format of it, might be a suggestion.


Some are more important than others.. And then there are the ones that 
'might' be more controversial, but senders should be informed about..
eg, The Address in the MAIL FROM/Return Path SHOULD reflect the domain 
of the person who's content is represented .. (I know, badly worded) but 
you get my drift..


For those on the security side, we would like to see it come from 
@trustedbank.com instead of @3rdpartymailprovider.com, but those in the 
sending community might not agree..







--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Alessandro Vesely via mailop]

On Tue 25/Feb/2020 12:12:05 +0100 Simon Lyall via mailop wrote:
> 
> Thank you for all the suggestions. I've put together a couple of pages:
> 
> https://www.mailop.org/faq/

s/What do do if being/What to do if being/


> https://www.mailop.org/best-practices/

s/all you public-facing/all your public-facing/


*SPF and Forwarding*:

Who does "consider a weak signal" domains having SPF?  Since SPF is part of
DMARC, presumably they also consider a weak signal domains having DMARC?



*Links*:

The Exim/exim/wiki/BlockCracking link is only valid for Exim users.  How about
replacing it with a paragraph on rate-limiting?



jm2c
Ale
-- 
































___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Simon Lyall via mailop]

Thank you for all the suggestions. I've put together a couple of pages:

https://www.mailop.org/faq/
https://www.mailop.org/best-practices/

as a start. What do people think needs to be added or changed?

Simon.
Mailop Admin Team.

--
Simon Lyall  |  Very Busy  |  Web: http://www.simonlyall.com/
"To stay awake all night adds a day to your life" - Stilgar


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Laura Atkins via mailop]

> On 24 Feb 2020, at 13:02, Vytis Marciulionis via mailop  
> wrote:
> 
> Hi, 
> 
> - Have proper FCrDNS records. Just having MX and PTR records doesn't cut it. 
> Add an A record that matches your PTR.  
> 
> Could someone please confirm whether this is a best common practice for 
> RFC.5321 header domains as well? From what I have been asking around and 
> inspecting returnpath domains of a number of ESPs it is not a widespread 
> standard to have the FCrDNS on them but, I would like to someone to confirm. 
> As far as the discussion here goes, usually I get an answer that mail sending 
> domains do not need an A record if they have MX record, is that correct?

The reason you want FCrDNS is so that you can actually verify that the IP 
address is actually in use by the domain in the rDNS.  I can set up my rDNS to 
be me.google.com  or mail.facebook.com 
 or any number of other domains. I have full control 
over the rDNS for an IP address under my control and there is nothing technical 
to stop me from forging domains. Spammers figured this out and would steal 
domain names for the rDNS of the connecting IP. 

As a way to verify whether this was authorized usage, the receiving servers 
would do a lookup on the IP. See, if someone is stealing facebook.com 
 or google.com  names for rDNS, then 
the corresponding domain DNS entries will not match. If someone is legitimately 
using the domain name in the rDNS then it is trivial for them to set up a 
corresponding DNS entry.

FCrDNS starts with an IP, finds out what domain name that IP points to and then 
checks to see that the domain name points back to the same IP address. It’s a 
method of deciding whether or not the IP address is legitimately being used by 
the domain in the rDNS entry.

FCrDNS is a way to verify the identity of the connecting IP. If the rDNS 
doesn’t match, then it’s much more likely that the mail is coming from an 
illegitimate source. 

If you consider that as the reason WHY recipient MXs check FCrDNS, then it 
becomes clear why your question gets the answer it does. 

FCrDNS is verifying a connecting IP isn’t lying about the domain it’s 
representing. There is no IP to start with in the 5321.from, so there’s no need 
to do the FCrDNS process. We have other ways to identify and verify the 
veracity of the domain in the address. We don’t really care anything about the 
IP address there. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
la...@wordtothewise.com
(650) 437-0741  

Email Delivery Blog: https://wordtothewise.com/blog 







___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Vytis Marciulionis via mailop]

Hi,

- Have proper FCrDNS records. Just having MX and PTR records doesn't cut
> it. Add an A record that matches your PTR.


Could someone please confirm whether this is a best common practice for
RFC.5321 header domains as well? From what I have been asking around and
inspecting returnpath domains of a number of ESPs it is not a widespread
standard to have the FCrDNS on them but, I would like to someone to
confirm. As far as the discussion here goes, usually I get an answer that
mail sending domains do not need an A record if they have MX record, is
that correct?

On Fri, Feb 21, 2020 at 2:57 PM M. Omer GOLGELI via mailop <
mailop@mailop.org> wrote:

>
> - Have proper FCrDNS records. Just having MX and PTR records doesn't cut
> it. Add an A record that matches your PTR.
>
>
>
>
>
>
> M. Omer GOLGELI
> ---
>
>
> February 16, 2020 5:21 PM, "Hans-Martin Mosner via mailop" <
> mailop@mailop.org
> >
> wrote:
>
> Some ideas from running small to medium mail servers for a long time. Many
> of you will probably have more extensive experience and advice, but this is
> just a minimal list off the top of my head to get something for a start:
>
>1. Don't hide behind anonymity. Mail server domain whois should have
>an identifiable registrant organization, there should be a point of contact
>for any technical and abuse problems related to the mail server. If your
>registry hides registrant data, it might be a good idea to have a web site
>with the same name that's not just showing a welcome message from an
>uninitialized CMS or hosting package. Mails sent to the abuse address must
>be read and acted upon, except for blatant spam of course.
>2. Naturally, don't send spam, and have all your users understand that
>sending unsolicited bulk/commercial mail is not acceptable and will lead to
>termination.
>3. Have proper DNS setup:
>
>
>- MX record for the domain pointing to the mail server.
>- PTR record for the mail server' IP address pointing to the mail
>server's name.
>- Stable IP address (not 5-minute TTL for dynamic DNS updates, no
>long-lasting outages)
>
>
>- Use TLS for both incoming and outgoing traffic whenever offered by
>the other side.
>- Use a separate submission port for authenticated and encrypted mail
>submissions from your users. Add authentication information in mail headers
>to make identifying hacked mail accounts possible.
>- If possible, restrict the use of foreign From: addresses to trusted
>users and automatic software. Don't let just anybody send mails from
> ...
>- Avoid creating backscatter, i.e. either reject mails in the SMTP
>dialog or accept them. If you use spam detection software after SMTP
>acceptance, it should flag messages but still deliver them. There are cases
>such as autoresponders for vacations and mailing list software which will
>need to automatically send responses to sender addresses, but these should
>be monitored closely to detect abuse early.
>- (opinionated) Don' use SPF, it's broken by design.
>- Cheers,
>Hans-Martin
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>


-- 
Pagarbiai,
Vytis Marčiulionis
+37064734475
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[M. Omer GOLGELI via mailop]

- Have proper FCrDNS records. Just having MX and PTR records doesn't cut it. 
Add an A record that matches your PTR.
M. Omer GOLGELI
---
February 16, 2020 5:21 PM, "Hans-Martin Mosner via mailop" mailto:mailop@mailop.org?to=%22Hans-Martin%20Mosner%20via%20mailop%22%20)>
 wrote:
Some ideas from running small to medium mail servers for a long time. 
Many of you will probably have more extensive experience and advice, but this 
is just a minimal list off the top of my head to get something for a start: 
* Don't hide behind anonymity. Mail server domain whois should have an 
identifiable registrant organization, there should be a point of contact for 
any technical and abuse problems related to the mail server. If your registry 
hides registrant data, it might be a good idea to have a web site with the same 
name that's not just showing a welcome message from an uninitialized CMS or 
hosting package. Mails sent to the abuse address must be read and acted upon, 
except for blatant spam of course. 
* Naturally, don't send spam, and have all your users understand that 
sending unsolicited bulk/commercial mail is not acceptable and will lead to 
termination. 
* Have proper DNS setup: 
* MX record for the domain pointing to the mail server. 
* PTR record for the mail server' IP address pointing to the mail 
server's name. 
* Stable IP address (not 5-minute TTL for dynamic DNS updates, no 
long-lasting outages) 
* Use TLS for both incoming and outgoing traffic whenever offered by 
the other side. 
* Use a separate submission port for authenticated and encrypted mail 
submissions from your users. Add authentication information in mail headers to 
make identifying hacked mail accounts possible. 
* If possible, restrict the use of foreign From: addresses to trusted 
users and automatic software. Don't let just anybody send mails from 
 (mailto:presid...@whitehouse.gov)... 
* Avoid creating backscatter, i.e. either reject mails in the SMTP 
dialog or accept them. If you use spam detection software after SMTP 
acceptance, it should flag messages but still deliver them. There are cases 
such as autoresponders for vacations and mailing list software which will need 
to automatically send responses to sender addresses, but these should be 
monitored closely to detect abuse early. 
* (opinionated) Don' use SPF, it's broken by design. 
* Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Luis Muñoz via mailop]

> On Feb 17, 2020, at 1:18 PM, G. Miliotis via mailop  wrote:
> 
> On 17/2/2020 22:39, Luis E. Muñoz via mailop wrote:
>> One could state facts – i.e., pointing out that SPF will break straight 
>> forwarding and mailing lists that do not rewrite – without introducing 
>> judgement. 
> 
> How about a small section in the FAQ about decisions that the mail admin must 
> make? Such as factors to consider with SPF (in this case), DMARC, quarantine, 
> RBLs and so on. Let the new guy know what he's getting into, probably early 
> on in the documentation. If it's too much material, just a mention to get 
> them started.

To me, this will work much better.

Best regards

-lem



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[G. Miliotis via mailop]

On 17/2/2020 22:39, Luis E. Muñoz via mailop wrote:
One could state facts – i.e., pointing out that SPF will break 
straight forwarding and mailing lists that do not rewrite – without 
introducing judgement. 


How about a small section in the FAQ about decisions that the mail admin 
must make? Such as factors to consider with SPF (in this case), DMARC, 
quarantine, RBLs and so on. Let the new guy know what he's getting into, 
probably early on in the documentation. If it's too much material, just 
a mention to get them started.


Best regards,
--GM


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Al Iverson via mailop]

On Mon, Feb 17, 2020 at 2:45 PM Luis E. Muñoz via mailop
 wrote:

> Unfortunately, we are operating in a world where legitimate forwarding
> is far outweighed by spoofed email and SPF is a response to that. If
> forwarding is expected, cooperating mail systems can make arrangements
> – i.e., ARC is an attempt to do this at a larger scale – but this
> is part of the consensual aspect of email transmission.
>
> As for SPF-breaking mailing lists, this is likely a self-correcting
> problem. ARC would also help with this use case.
>
> One could state facts – i.e., pointing out that SPF will break
> straight forwarding and mailing lists that do not rewrite – without
> introducing judgement.

Luis is right. SPF is broadly used and in the operational context
people need better guidance than "run away."

Cheers,
Al Iverson


-- 
al iverson // wombatmail // chicago
dns tools are cool! https://xnnd.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Luis E. Muñoz via mailop]

On 17 Feb 2020, at 11:20, Hans-Martin Mosner via mailop wrote:

My personal experience with SPF is that it is less helpful than 
harmful, at least when mail server operators use it for
rejection instead of tagging. It can help reject some mails with fake 
sender information, but at the same time it

prevents some legitimate forwarded mails from getting through.


And this is a decision of the sending mail system. Editorializing on 
this does not help. Many of us have personal experience that shape our 
own decision making process. Those experiences don't necessarily map 
well to others'.


Unfortunately, we are operating in a world where legitimate forwarding 
is far outweighed by spoofed email and SPF is a response to that. If 
forwarding is expected, cooperating mail systems can make arrangements 
– i.e., ARC is an attempt to do this at a larger scale – but this 
is part of the consensual aspect of email transmission.


As for SPF-breaking mailing lists, this is likely a self-correcting 
problem. ARC would also help with this use case.


One could state facts – i.e., pointing out that SPF will break 
straight forwarding and mailing lists that do not rewrite – without 
introducing judgement.


Best regards

-lem

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Hans-Martin Mosner via mailop]

Am 17.02.20 um 19:21 schrieb Alessandro Vesely via mailop:
> On Sun 16/Feb/2020 15:21:34 +0100 Hans-Martin Mosner via mailop wrote:
>> (opinionated) Don' use SPF, it's broken by design.
>
> I don't think that a FAQ starting with such opinionated entries is going 
> anywhere.
>
>
> Best
> Ale

I deliberately did not start the list with this, instead put it as the last 
point because I know opinions differ on this
topic. A public FAQ should probably not be place this into the "agreed-upon 
best practices" but the "controversial
opinions" department.

My personal experience with SPF is that it is less helpful than harmful, at 
least when mail server operators use it for
rejection instead of tagging. It can help reject some mails with fake sender 
information, but at the same time it
prevents some legitimate forwarded mails from getting through.

I do know about SRS, even had it running some time ago, and if someone wants to 
run it to improve deliverability of
forwarded mail that's perfectly fine with me.

But if you run a mail server and your users aren't getting mails forwarded from 
their accounts on other mail servers
because you reject based on SPF, you're not exactly helping deliverability.

Cheers,
Hans-Martin



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Alessandro Vesely via mailop]

On Sun 16/Feb/2020 15:21:34 +0100 Hans-Martin Mosner via mailop wrote:
> (opinionated) Don' use SPF, it's broken by design.


I don't think that a FAQ starting with such opinionated entries is going 
anywhere.


Best
Ale
-- 


















___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Hans-Martin Mosner via mailop]

Am 16.02.2020 22:15, schrieb Jaroslaw Rafa via mailop:

Dnia 16.02.2020 o godz. 15:21:34 Hans-Martin Mosner via mailop pisze:


 1. Don't hide behind anonymity. Mail server domain whois should have 
an identifiable registrant organization, there

[...]

 8. (opinionated) Don' use SPF, it's broken by design.


9. If you want to send mail to recipients who have accounts at big 
email

providers, be aware that all of the above cannot guarantee that these
providers won't reject your mail, put it straight into recipient's spam
folder or just silently discard it - they just impose their own rules 
on

anyone and you virtually can't do anything about it.


You're right, following best practices won't guarantee delivery, this is 
a caveat that should be added to such a list.
However, that's just an observation of fact, and if you can't do 
anything about it, it doesn't belong among the best practices.


BTW, in some rare cases, when you have alternative means of contact, 
notifying the recipients and suggesting they leave their mail-unfriendly 
provider for a better place may help.


Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Lena--- via mailop]

> Either links to existing material or specific stuff written for pages
> on would be welcome.

Blocking of compromised mail accounts (for Exim):
https://github.com/Exim/exim/wiki/BlockCracking


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Ideas for possible content for FAQ: "Best Practices for running a mail server"

[Jaroslaw Rafa via mailop]

Dnia 16.02.2020 o godz. 15:21:34 Hans-Martin Mosner via mailop pisze:
> 
>  1. Don't hide behind anonymity. Mail server domain whois should have an 
> identifiable registrant organization, there
[...]
>  8. (opinionated) Don' use SPF, it's broken by design.

9. If you want to send mail to recipients who have accounts at big email
providers, be aware that all of the above cannot guarantee that these
providers won't reject your mail, put it straight into recipient's spam
folder or just silently discard it - they just impose their own rules on
anyone and you virtually can't do anything about it.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop