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/
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
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.95
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
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
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
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
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/
> 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
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
- 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
> 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
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?
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
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
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
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
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
> 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
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
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
21 matches
Mail list logo
