> On Jul 25, 2017, at 7:46 PM, Brandon Long via mailop
> wrote:
>
> Agreed that STS and DANE are the solution for enforcing, however it's still
> early days for those.
>
> Brandon
Sorry, probably straying from the topic, but does anyone know any good SMTP
tests for DANE.
I’m using https://
On Tue, Jul 25, 2017 at 4:13 PM, Ted Cabeen
wrote:
> On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:
>
>> STARTTLS is opportunistic and doesn't protect against active
>> Man-in-the-Middle. In case of TLS problems it falls back to plain text.
>>
>
> Interestingly, that's not always the c
On 7/25/2017 8:14 AM, Vladimir Dubrovin via mailop wrote:
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
Interestingly, that's not always the case now. We typoed the cert on
one of our list servers earlier t
On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
STARTTLS is opportunistic, but MTAs can be configured to require
protected channels and to refuse ema
Not nearly a complete list but somethings that might inspire you, also YMMV
based on your exact needs.
abuse
admin
administration
all
announce
approved
contact
email
events
help
hostmaster
info
information
List-help
Lists
List-subscribe
List-unsubscribe
mailer-daemon
marketing
Moderators
Mods
NoRe
On Tue, 25 Jul 2017 10:49:09 -0700, Brandon Long via mailop
wrote:
>Gmail also restricted all usernames that it's employees used and all
>popular names. More because they figured it would lead to confusion, I
>know the guy who had dave@yahoo and even a decade ago it was nearly useless
>with peop
On common OS names, I have an ISP client who blocks Administrator@ (both in
and out). They claim it reduces a whole load of problems with misconfigured
Exchange / AD servers living on client LANs.
Also make sure messages to abuse@ also feeds into your Abuse dept. as well
as going to your client.
Other things to consider are support/sales/ads or anything that contains
your brand. Guess this depends on whether this is a set of domains that
anyone can sign up for an address on, or whether they own the domain.
Gmail also restricted all usernames that it's employees used and all
popular names
On 17-07-25 09:59 AM, Kirk MacDonald wrote:
In addition to what is mentioned in RFC2142, can anyone offer any resources (or "best practices")
for what can be considered "restricted" email addresses/UIDs for a domain which offers mailbox
service to the general public? This would also be assuming
In addition to what is mentioned in RFC2142, can anyone offer any resources (or
"best practices") for what can be considered "restricted" email addresses/UIDs
for a domain which offers mailbox service to the general public? This would
also be assuming the "restricted" email addresses are otherwi
I've not had any issues with self signed certs with TLS on SMTP. That said,
lately I've been using Lets Encrypt certificates with the certbot program
to manage them, and that has worked really well. The initial setup takes a
little effort to do a DNS based verification since the mail hosts are not
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
To protect against passive Man-in-the-Middle, there is no actual
difference between the self-signed certificate and certificate from
recognized CA, so, except may b
Hello,
We're looking to implement inbound TLS on machines that are only used to
send mail and receive bounces, and I was wondering if anyone has
encountered problems using a self-signed cert for that purpose. It seems
like it would be easier to implement on a larger scale than would CA-signed
cert
13 matches
Mail list logo
