Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Eric Tykwinski 

> On Jul 26, 2017, at 5:42 PM, Steve Atkins  wrote:
> 
> It doesn't _really_ matter in the context of deciding whether a certificate
> is being presented by a legitimate domain owner or a MitM.

Well I think that’s the whole solution of DANE, ie validate through DNSSCEC 
that the owner of the domain is the owner.
Obviously the DNS chain could be compromised, but at some point we have to let 
birds fly.

> A domain-validated certificate doesn't stop being domain-validated
> the day it's dodgy CA is removed from the approved list.

But that is the point of anyone removing the CA from authoritative chains, or 
intermediates.
Quick google search and GlobalSign comes up, sorry guys: 
https://www.theregister.co.uk/2016/10/13/globalsigned_off/ 


> It's relationship to the domain continues to be about as trustworthy
> as it was before the CA was smacked down, and still more so
> than anything self-signed or created using a private CA.

Trust me, if you ask the CAs, if you get “smacked” down, it’s probably all 
hands on deck.
Having a self signed cert, you the domain owner know what you are getting into.

> Cheers,
>  Steve

I think the major argument would be with corporate as they don’t care about 
random joe, but then do they than care about DNSSEC to actually publish 
records.  It’s sort of like the same catch 22 that DANE was supposed to fix.  I 
personally think of it like DEMARC, it’s that extra bit of time that spammers 
sure are not going to go through, but possible.  So security wise, it’s 
basically the same, we know mail.example.com  sent an 
email, it’s either DNS validated through DNSSEC, or some CA did it’s magic.  

The major problem apparently is that most solutions don’t check CA certificate 
paths, so at least DANE does something.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Restricted email address UIDs for public email domains

2017-07-26 Thread Peter Bowen 
On Tue, Jul 25, 2017 at 9: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 the "restricted" email addresses are 
> otherwise valid in terms of length, characters, etc.
>
> I tend to think that UIDs which one could consider "vulgar" aren’t realistic 
> to restrict, since those types of feelings evolve over time and are subject 
> to personal and cultural bias (to say nothing of the wordlist/regex 
> complexity), but it would be interesting to know if there are addresses which 
> folks commonly feel fall into a role/reserved type of category and/or should 
> otherwise be restricted to the domain owners use (or no one's use).

Public certification authorities are allowed to use five mailbox names
when verifying domain control for TLS/SSL certificate issuance.  These
are postmaster, hostmaster, webmaster, administrator, and admin.  I
would suggest ensuring these are controlled, so that there is not a
repeat of 
https://arstechnica.com/security/2015/03/man-who-obtained-windows-live-cert-said-his-warnings-went-unanswered/

Thanks,
Peter

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

Re: [mailop] Restricted email address UIDs for public email domains

2017-07-26 Thread Michael 
You might be going too stringent in that case..
For instance, many people create aliases related to the service they are 
working with..
Also, a lot of people use 'throwaway' addresses related to the service..
I remember using 'ticketmaster@' once and surprised at how quickly 3rd party 
offers came to me after buying tickets online.. (this was way back when)

Just because someone 'might' use a name for nefarious purposes, doesn't mean it 
will always be used for the purpose.. however, if I was starting up a 
'freemail' service, I might like to be overly restrictive, but even if you went 
as far as 'any' trademarked name.. you might still have problems.

On Wed, 26 Jul 2017 18:31:57 -0400
Rich Kulawiec  wrote:
> On Tue, Jul 25, 2017 at 04:59:39PM +, 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?
> 
> In addition to the excellent ideas already on the table, I suggest
> disallowing the domain names of the top N sites (pick your flavor
> of "top", pick your N), e.g., do not allow:
> 
> ebay.com@
> amazon.com@
> google.com@
> 
> and so on.  There are many, MANY people out there who don't grasp the
> difference between RHS and LHS of email addresses and will be fooled
> by these.   You might also want to consider disallowing the domain
> names sans the TLD, e.g., ebay@, amazon@, google@ for the same reason.
> 
> ---rsk
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
> 



--
-- 
"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" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada


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

Re: [mailop] Restricted email address UIDs for public email domains

2017-07-26 Thread Rich Kulawiec 
On Tue, Jul 25, 2017 at 04:59:39PM +, 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?

In addition to the excellent ideas already on the table, I suggest
disallowing the domain names of the top N sites (pick your flavor
of "top", pick your N), e.g., do not allow:

ebay.com@
amazon.com@
google.com@

and so on.  There are many, MANY people out there who don't grasp the
difference between RHS and LHS of email addresses and will be fooled
by these.   You might also want to consider disallowing the domain
names sans the TLD, e.g., ebay@, amazon@, google@ for the same reason.

---rsk

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

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Steve Atkins 

> On Jul 26, 2017, at 1:43 PM, valdis.kletni...@vt.edu wrote:
> 
> On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
>> Why can't smtp software being expected to maintain a list of trusted CAs?
>> Or at least run on an OS that is expected to do so.
> 
> Quick: What two CAs did Google just remove from Chrome's list?
> 
> Has your OS vendor followed suit?  And what percent of your OS vendor's 
> installs
> are prompt in applying patches?

It doesn't _really_ matter in the context of deciding whether a certificate
is being presented by a legitimate domain owner or a MitM.

A domain-validated certificate doesn't stop being domain-validated
the day it's dodgy CA is removed from the approved list.

It's relationship to the domain continues to be about as trustworthy
as it was before the CA was smacked down, and still more so
than anything self-signed or created using a private CA.

Cheers,
  Steve



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

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Brandon Long via mailop 
If it becomes important, I'm sure it can be done.

I mean, you all update your av signatures at least daily, or your spam
rules.

And whether they would need to follow the browser list or whatever isn't
clear, sure.

It's early in this stuff for email, maybe DANE will be the solution that
catches on for smtp, and CA verified won't be the common choice.

Brandon

On Jul 26, 2017 1:55 PM, "Kevin A. McGrail"  wrote:

> On 7/26/2017 4:43 PM, valdis.kletni...@vt.edu wrote:
>
>> Quick: What two CAs did Google just remove from Chrome's list?
>>
> Not to mention the Chrome v Symantec issue that's about to cause the 2nd
> coming...
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread valdis . kletnieks 
On Wed, 26 Jul 2017 10:10:53 -0700, Brandon Long via mailop said:
> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.

Quick: What two CAs did Google just remove from Chrome's list?

Has your OS vendor followed suit?  And what percent of your OS vendor's installs
are prompt in applying patches?


pgpwnCPJNDv7D.pgp
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Luis E. Muñoz 

I think the key part is not "expect", but actually don't require it.

-lem

On 26 Jul 2017, at 10:10, Brandon Long via mailop wrote:

> Why can't smtp software being expected to maintain a list of trusted CAs?
> Or at least run on an OS that is expected to do so.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Brandon Long via mailop 
On Wed, Jul 26, 2017 at 1:23 AM, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

>
> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
>
>
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
>
> 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 be very few unsignificant implementors,
> all peers accept self-signed certificates for STARTTLS (unless DANE or
> SMTP STS are used).
>
>
> I agree that this matches historical norms. I suspect that DANE and /
> or SMTP STS are going to be changing this.
>
> If you use DANE, whether the certificate is self-signed or signed by a CA
> does not make any significant difference; your trust derives from a secure
> DNS query that verifies that the certificate you show is actually the same
> that is pinned in appropriate DNS records for your hostname. Actually,
> using a self-signed certificate may make DANE deployment easier. Also, SMTP
> software (differently from browsers) cannot be expected to maintain a list
> of trusted certification authorities, so there is no advantage in using a
> CA-signed certificate. You can refer to RFC 7672 for further details on the
> topic.
>
Why can't smtp software being expected to maintain a list of trusted CAs?
Or at least run on an OS that is expected to do so.

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

Re: [mailop] shutterfly contact?

2017-07-26 Thread Dave Lugo 

Hi,

Not sure if this is being sent by the ESP... it's coming from 
136.179.236.38, which whois tells me is:


SWITCH, LTD SWITCH-LTD (NET-136-179-0-0-1) 136.179.0.0 - 136.179.255.255
Shutterfly SHUTTERFLY-236 (NET-136-179-236-0-1) 136.179.236.0 - 136.179.239.255

Thanks,

Dave

On Mon, 24 Jul 2017, Matt Vernhout wrote:


They seem to use Responsys (Oracle) as their ESP - If you need a contact there 
LMK and I'll send you one off list.

~
Matt

On Sun, Jul 23, 2017 at 4:47 PM, Dave Lugo  wrote:
  Does anyone have a shutterfly contact they can share?

  They're violating can-spam in at least two ways...

  Thanks,

  Dave

  --
  
  Dave Lugo   dl...@etherboy.com    LC Unit #260   TINLC
  Have you hugged your firewall today?   No spam, thanks.
  
  Are you the police?  . . . .  No ma'am, we're sysadmins.

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






--

Dave Lugo   dl...@etherboy.comLC Unit #260   TINLC
Have you hugged your firewall today?   No spam, thanks.

Are you the police?  . . . .  No ma'am, we're sysadmins.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] self-signed cert for inbound TLS

2017-07-26 Thread Vittorio Bertola 

> Il 25 luglio 2017 alle 22.25 Grant Taylor via mailop ha scritto:
> 
> 
> On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
> 
> > > 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 be very few unsignificant 
> > implementors,
> > all peers accept self-signed certificates for STARTTLS (unless DANE 
> > or
> > SMTP STS are used).
> > 
> > > I agree that this matches historical norms. I suspect that DANE 
> > and /
> or SMTP STS are going to be changing this.
> 

If you use DANE, whether the certificate is self-signed or signed by a CA does 
not make any significant difference; your trust derives from a secure DNS query 
that verifies that the certificate you show is actually the same that is pinned 
in appropriate DNS records for your hostname. Actually, using a self-signed 
certificate may make DANE deployment easier. Also, SMTP software (differently 
from browsers) cannot be expected to maintain a list of trusted certification 
authorities, so there is no advantage in using a CA-signed certificate. You can 
refer to RFC 7672 for further details on the topic.

(SMTP-STS is mainly a short term workaround while DNSSEC is being deployed, so, 
if you can, you should go for DANE instead.)

Regards,

--

kind regards,

Vittorio Bertola
Research & Innovation Engineer


Cell:   +39 348 7015022
Skype:  in-skype...@bertola.eu
Email:  vittorio.bert...@open-xchange.com 
mailto:vittorio.bert...@open-xchange.com
 
Twitter: @openexchange http://twitter.com/openexchange - Facebook: OpenXchange 
https://www.facebook.com/OpenXchange - Web: www.open-xchange.com 
http://www.open-xchange.com
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 
24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein
Chairman of the Board: Richard Seibt

European Office:
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court 
Siegen, HRB 8718
Managing Directors: Frank Hoberg, Martin Kauss

US Office:
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA
 
Confidentiality Warning: This message and any attachments are intended only for 
the use of the intended recipient(s), are confidential, and may be privileged. 
If you are not the intended recipient, you are hereby notified that any review, 
retransmission, conversion to hard copy, copying, circulation or other use of 
this message and any attachments is strictly prohibited. If you are not the 
intended recipient, please notify the sender immediately by return e-mail, and 
delete this message and any attachments from your system.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop