Re: TLS warning

[Rick Leir]

On 2017-05-25 02:31 AM, Philip Paeps wrote:
On 2017-05-24 14:54:34 (+0200), Bastian Blank 
 wrote:

On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com wrote:

‎You shouldn't be accepting sslv3 due to the poodle attack.
https://en.m.wikipedia.org/wiki/POODLE


Please explain how exactly SMTP is exploitable using POODLE?


There are other good reasons to disable SSLv3.  But POODLE is a 
distraction in the context of SMTP.
In the context of a SASL login to send outgoing email, is it still a 
distraction?


How about dovecot, logging in to receive email and clean up my inbox?

As recommended by lazyG,

http://disablessl3.com/



In general though, when it comes to SMTP, any encryption is better 
than none.  And opportunistic encryption is the way to go.  Read RFC 
7435:


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

Thanks!


Philip

Re: TLS warning

[li...@lazygranch.com]

On Thu, 25 May 2017 03:02:39 -0400
Rick Leir  wrote:

> 
> 
> On 2017-05-25 02:31 AM, Philip Paeps wrote:
> > On 2017-05-24 14:54:34 (+0200), Bastian Blank 
> >  wrote:
> >> On Wed, May 24, 2017 at 02:41:01AM -0700, li...@lazygranch.com
> >> wrote:
> >>> ‎You shouldn't be accepting sslv3 due to the poodle attack.
> >>> https://en.m.wikipedia.org/wiki/POODLE
> >>
> >> Please explain how exactly SMTP is exploitable using POODLE?
> >
> > There are other good reasons to disable SSLv3.  But POODLE is a 
> > distraction in the context of SMTP.
> In the context of a SASL login to send outgoing email, is it still a 
> distraction?
> 
> How about dovecot, logging in to receive email and clean up my inbox?
> 
> As recommended by lazyG,
> 
> http://disablessl3.com/
> 
> >
> > In general though, when it comes to SMTP, any encryption is better 
> > than none.  And opportunistic encryption is the way to go.  Read
> > RFC 7435:
> >
> > https://tools.ietf.org/html/rfc7435
> Thanks!
> >
> > Philip
> >
> 

This paper is a good read on email security. It goes into the various
means that a man in the middle can reduce security, one of which is
enabled by selecting opportunistic encryption. (Of which in all
practicality you don't have a choice if you want maximum
compatibility. I'm amazed at the lack of encryption in first world
countries like Canada or the UK.)

"Neither Snow Nor Rain Nor MITM . . .
An Empirical Analysis of Email Delivery Security"
https://jhalderm.com/pub/papers/mail-imc15.pdf
Video by one of the authors.
https://www.youtube.com/watch?v=_aogXeTbERs

Given the email issues in recent political campaigns, I'm seeing a
number of articles suggesting setting up DMARC for quarantine. Most
recent:

http://www.prnewswire.com/news-releases/bishop-fox-research-finds-98-of-the-top-million-internet-domains-are-potentially-vulnerable-to-email-spoofing-300461861.html
Specifically "First, companies must safeguard their company's domain by
checking the company's DNS records for SPF and DMARC. Make sure that
the company's domain has a properly configured SPF record and a DMARC
record with a policy of quarantine or reject. Then, use Spoofcheck to
check if the domain is sufficiently protected."
Where 
http://spoofcheck.bishopfox.com/#!/
isn't exactly rocket science. It just reads your DMARC.

Re: Relay access denied

[alexvojproc]

Thanks Viktor, I knew my sloppy configuration must have been at fault.
Everything related to this works now.

- Alex



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Relay-access-denied-tp90614p90623.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Postfix and FUSE: Function not implemented

[alexvojproc]

To avoid running out of room on my mail server, I mounted a storage bucket
using FUSE and created a user with this as its home directory. To avoid
permissions issues, I used the arguments "allow_other" and
"default_permissions" and made sure my user owned its home directory. Even
after this, Postfix bounces my mail:
Status: 5.2.0
Diagnostic-Code: X-Postfix; maildir delivery failed: create maildir file
/mnt/bucket/user/Mail/new/1495706489.V20I27M436672.server: Function not
implemented

Dovecot also didn't work, here is the error it kept giving which might help:
server dovecot: imap(user): Error: close() failed with file
/mnt/bucket/user/Mail/dovecot.index.log: Input/output error

Do I have to make any configuration changes when using FUSE? Here's the
specific file system (if relevant):
https://github.com/GoogleCloudPlatform/gcsfuse



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Postfix-and-FUSE-Function-not-implemented-tp90624.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: Postfix and FUSE: Function not implemented

[Wietse Venema]

alexvojproc:
> To avoid running out of room on my mail server, I mounted a storage bucket
> using FUSE and created a user with this as its home directory. To avoid
> permissions issues, I used the arguments "allow_other" and
> "default_permissions" and made sure my user owned its home directory. Even
> after this, Postfix bounces my mail:
> Status: 5.2.0
> Diagnostic-Code: X-Postfix; maildir delivery failed: create maildir file
> /mnt/bucket/user/Mail/new/1495706489.V20I27M436672.server: Function not
> implemented

To find out which function isn't implemented, you can use strace
(see http://www.postfix.org/DEBUG_README.html).  Then, you may
consider to wrap Postfix daemons, using LD_PRELOAD or the like,
with a module that cheats.

Postfix requires a filesystem that correctly implements all the
system calls that it makes.  These system calls are made for good
reasons, and I don't intend to make then optional.

Wietse

> Dovecot also didn't work, here is the error it kept giving which might help:
> server dovecot: imap(user): Error: close() failed with file
> /mnt/bucket/user/Mail/dovecot.index.log: Input/output error
> 
> Do I have to make any configuration changes when using FUSE? Here's the
> specific file system (if relevant):
> https://github.com/GoogleCloudPlatform/gcsfuse
> 
> 
> 
> --
> View this message in context: 
> http://postfix.1071664.n5.nabble.com/Postfix-and-FUSE-Function-not-implemented-tp90624.html
> Sent from the Postfix Users mailing list archive at Nabble.com.
> 

removing private data from headers

[spamvoll]

Hi all,

since three days I'm trying to remove my internal and external IP from the
Message header when I'm sending mails. But no solution has worked so far.

What I did:
created a new service in master.cf

header-cleanup unix n – – – 0 cleanup
-o syslog_name=postfix/header-cleanup
-o header_checks=pcre:/etc/postfix/header-cleanup.pcre

added to submission service:
-o cleanup_service_name=header-cleanup

created the file:
header-cleanup.pcre:
/^\s*Received/ IGNORE

Doenst work, the Received headers are still in there.

Any ideas ?

Hans

Re: removing private data from headers

[Albrecht Dreß]

Am 25.05.17 14:20 schrieb(en) spamv...@googlemail.com:

since three days I'm trying to remove my internal and external IP from the 
Message header when I'm sending mails. But no solution has worked so far.

What I did:
created a new service in master.cf


A simpler solution (working for me) for all outgoing messages is to add


smtp_header_checks = pcre:/etc/postfix/clean_outgoing_headers


to /etc/postfix/main.cf.  The file /etc/postfix/clean_outgoing_headers contains


# drop mail application information
/^X-Mailer:.*/  IGNORE
/^User-Agent:.*/IGNORE
/^X-Enigmail-Version:.*/IGNORE
# drop all received stuff
/^Received:.*/  IGNORE


which additionally removes information about the MUA which may be used by an 
attacker to craft a targeted attack.

Hth,
Albrecht.

pgpuP97RQLj7E.pgp
Description: PGP signature

Re: removing private data from headers

[spamvoll]

Interesting..

smtp_header_checks did the trick, header_checks did not.

2017-05-25 14:26 GMT+02:00 Albrecht Dreß :

> Am 25.05.17 14:20 schrieb(en) spamv...@googlemail.com:
>
>> since three days I'm trying to remove my internal and external IP from
>> the Message header when I'm sending mails. But no solution has worked so
>> far.
>>
>> What I did:
>> created a new service in master.cf
>>
>
> A simpler solution (working for me) for all outgoing messages is to add
>
> 
> smtp_header_checks = pcre:/etc/postfix/clean_outgoing_headers
> 
>
> to /etc/postfix/main.cf.  The file /etc/postfix/clean_outgoing_headers
> contains
>
> 
> # drop mail application information
> /^X-Mailer:.*/  IGNORE
> /^User-Agent:.*/IGNORE
> /^X-Enigmail-Version:.*/IGNORE
> # drop all received stuff
> /^Received:.*/  IGNORE
> 
>
> which additionally removes information about the MUA which may be used by
> an attacker to craft a targeted attack.
>
> Hth,
> Albrecht.

Re: Multiple recipients in BCC will not relay if it contains one bad email address.

[Noel Jones]

On 5/24/2017 5:23 PM, madrida wrote:
> Hi Everyone first time posting, I am hoping you can help me. We have an issue
> when an email sent to multiple emails via BCC is deleted if an invalid email
> address is in the list. The email is discarded all together and I don't see
> any logs other then the bounces. They need to send via BCC for privacy to
> other vendors. We need to bounce the back emails and continue to send to all
> the valid recipients. 

Either your observations are flawed or the information you provide
is incomplete.

BCC addresses are indicated in the headers, which postfix never uses
for delivery decisions.  Postfix operates on envelope addresses.

Postfix logs all actions.

Other than a few user-defined actions such as DISCARD or REDIRECT,
postfix operates on individual recipients, not entire messages.
Check your logs and config carefully for these all-recipients actions.

Perhaps an external content filter or spam filter, or your relayhost
is mangling your mail.

for general debugging help, please see:
http://www.postfix.org/DEBUG_README.html

If you need to ask more questions, please include more information.
Include "postconf -n" and related logs in your message to the list,
not to an external site.
http://www.postfix.org/DEBUG_README.html#mail



  -- Noel Jones

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: removing private data from headers

[spamvoll]

Hi Albrecht,

tested it and it works as it shoud.

big thanks

2017-05-25 14:41 GMT+02:00 :

> Interesting..
>
> smtp_header_checks did the trick, header_checks did not.
>
> 2017-05-25 14:26 GMT+02:00 Albrecht Dreß :
>
>> Am 25.05.17 14:20 schrieb(en) spamv...@googlemail.com:
>>
>>> since three days I'm trying to remove my internal and external IP from
>>> the Message header when I'm sending mails. But no solution has worked so
>>> far.
>>>
>>> What I did:
>>> created a new service in master.cf
>>>
>>
>> A simpler solution (working for me) for all outgoing messages is to add
>>
>> 
>> smtp_header_checks = pcre:/etc/postfix/clean_outgoing_headers
>> 
>>
>> to /etc/postfix/main.cf.  The file /etc/postfix/clean_outgoing_headers
>> contains
>>
>> 
>> # drop mail application information
>> /^X-Mailer:.*/  IGNORE
>> /^User-Agent:.*/IGNORE
>> /^X-Enigmail-Version:.*/IGNORE
>> # drop all received stuff
>> /^Received:.*/  IGNORE
>> 
>>
>> which additionally removes information about the MUA which may be used by
>> an attacker to craft a targeted attack.
>>
>> Hth,
>> Albrecht.
>
>
>

Re: Multiple recipients in BCC will not relay if it contains one bad email address.

[madrida]

Thanks for you response Noel, I had included the postconf -n information in
my post I guess its a link. Thanks once again for you very useful feedback. 
postconf.txt   



--
View this message in context: 
http://postfix.1071664.n5.nabble.com/Multiple-recipients-in-BCC-will-not-relay-if-it-contains-one-bad-email-address-tp90616p90631.html
Sent from the Postfix Users mailing list archive at Nabble.com.

Re: TLS warning

[Viktor Dukhovni]

> On May 25, 2017, at 5:23 AM, li...@lazygranch.com wrote:
> 
> Given the email issues in recent political campaigns, I'm seeing a
> number of articles suggesting setting up DMARC for quarantine.

DMARC is an abuse of the IETF process (informational RFC) to promote
and deploy a deeply flawed specification.  It should never have been
deployed outside domains that only do "transactional email" subject
to phishing like paypal.com.  Yahoo deployed it despite the resulting
breakage to everyone else, because it lowered their abuse desk costs.

I neither deploy nor check DMARC.  It is a broken design.

-- 
Viktor.

Re: TLS warning

[Viktor Dukhovni]

> On May 25, 2017, at 5:23 AM, li...@lazygranch.com wrote:
> 
> "Neither Snow Nor Rain Nor MITM . . .
> An Empirical Analysis of Email Delivery Security"
> https://jhalderm.com/pub/papers/mail-imc15.pdf
> Video by one of the authors.
> https://www.youtube.com/watch?v=_aogXeTbERs

It is a good academic study, but like many such efforts, it implicitly
compares SMTP with HTTPS, but the proper comparison is with the
combination of HTTP and HTTPS.  Take a look at:

https://www.google.com/transparencyreport/saferemail/

By now ~85-88% email inbound to Gmail is TLS encrypted in transit.  The
fraction of Web traffic that uses HTTPS is in recent reports only ~50%.

If we're talking SMTP security (and not end-to-end encryption which remains
deeply impractical for most use-cases), then implement DANE, but make sure
you understand the operational responsibilities, DANE is not deploy and
forget, key rotation must be handled correctly and consistently:

   https://dane.sys4.de/common_mistakes
   
http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
   https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
   
https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
   
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
   http://tools.ietf.org/html/rfc7671#section-8.1
   http://tools.ietf.org/html/rfc7671#section-8.4

Ideally via robust hooks that automatically update the relevant DNS entries
(as required) as part of the key rotation process.

-- 
Viktor.

Re: Issue with SASL authentication

[Daniel Bareiro]

Hi!

On 24/05/17 21:18, Daniel Bareiro wrote:

> Hi again.
> 
> On 24/05/17 17:46, Daniel Bareiro wrote:
> 
>> Maybe this question is not 100% about Postfix, but it is related. I am
>> configuring a Postifx server with SASL authentication.
>>
>> When I do a test to authenticate, I get an error:
>>
>> --
>> root@server2:~# saslpasswd2 -c daniel
>> --
>> root@server2:~# testsaslauthd -u daniel -p password
>> 0: NO "authentication failed"
>> --
>>
>> However it works when I provide the realm:
>>
>> --
>> root@server2:~# testsaslauthd -u daniel -r server2 -p password
>> 0: OK "Success."
>> --
>>
>> It's strange because I have another mail server where it works without
>> problems:
>>
>> --
>> root@mail:~# testsaslauthd -u daniel -p password
>> 0: OK "Success."
>> --
>>
>> Both hosts have Debian Jessie and the SASL configuration is the same:
>>
>> --
>> root@mail:~# grep ^[^#] /etc/default/saslauthd
>> START=yes
>> DESC="SASL Authentication Daemon"
>> NAME="saslauthd"
>> MECHANISMS="sasldb"
>> MECH_OPTIONS=""
>> THREADS=5
>> OPTIONS="-c -m /var/run/saslauthd"
>> --
>> root@server2:~# grep ^[^#] /etc/default/saslauthd
>> START=yes
>> DESC="SASL Authentication Daemon"
>> NAME="saslauthd"
>> MECHANISMS="sasldb"
>> MECH_OPTIONS=""
>> THREADS=5
>> OPTIONS="-c -m /var/run/saslauthd"
>> --
>>
>> "mail" has some updates to apply, but I do not see any differences in
>> the versions of the SASL packages:
>>
>> --
>> root@mail:~# aptitude show libsasl2-2 | grep Versión
>> Versión: 2.1.26.dfsg1-13+deb8u1
>>
>> root@mail:~# aptitude show libsasl2-modules | grep Versión
>> Versión: 2.1.26.dfsg1-13+deb8u1
>>
>> root@mail:~# aptitude show sasl2-bin | grep Versión
>> Versión: 2.1.26.dfsg1-13+deb8u1
>> --
>>
>> --
>> root@server2:~# aptitude show libsasl2-2 | grep Version
>> Version: 2.1.26.dfsg1-13+deb8u1
>>
>> root@server2:~# aptitude show libsasl2-modules | grep Version
>> Version: 2.1.26.dfsg1-13+deb8u1
>>
>> root@server2:~# aptitude show sasl2-bin | grep Version
>> Version: 2.1.26.dfsg1-13+deb8u1
>> --
>>
>> In this case I'm not doing the authentication test against IMAP but
>> directly against SASL, so I guess the problem will be directly related
>> to the SASL configuration itself.
>>
>> In case it is useful, when the authentication fails I get this in
>> /var/log/auth.log:
>>
>> --
>> May 24 15:31:38 server2 saslauthd[2701]: do_auth : auth failure:
>> [user=daniel] [service=imap] [realm=] [mech=sasldb] [reason=Unknown]
>> --
>>
>> It seems that authentication is done through IMAP and I have previously
>> installed the Cyrus packages.
>>
>>
>> Any thoughts about what might differ between the two environments?
> 
> Apparently, despite this difference, the SASL authentication via IMAP is
> working.
> 
> /var/log/mail.log:
> 
> --
> May 24 19:38:51 server2 cyrus/imaps[3711]: starttls: TLSv1.2 with cipher
> ECDHE-RSA-AES128-SHA (128/128 bits new) no authentication
> May 24 19:38:51 server2 cyrus/imaps[3711]: login: host.domain.tld.net
> [x.y.z.t] daniel CRAM-MD5+TLS User logged in
> SESSIONID=
> May 24 19:38:51 server2 cyrus/imaps[3711]: created decompress buffer of
> 4102 bytes
> May 24 19:38:51 server2 cyrus/imaps[3711]: created compress buffer of
> 4102 bytes
> May 24 19:38:51 server2 cyrus/imaps[3711]: client id: "name"
> "Thunderbird" "version" "45.8.0"
> May 24 19:38:53 server2 cyrus/master[3800]: about to exec
> /usr/lib/cyrus/bin/imapd
> May 24 19:38:53 server2 cyrus/imaps[3800]: executed
> May 24 19:38:53 server2 cyrus/imaps[3800]: accepted connection
> May 24 19:38:53 server2 cyrus/imaps[3800]: imapd:Loading hard-coded DH
> parameters
> May 24 19:38:53 server2 cyrus/imaps[3800]: SSL_accept() incomplete -> wait
> May 24 19:38:54 server2 cyrus/imaps[3800]: SSL_accept() succeeded -> done
> --
> 
> But SMTP authentication for sending mail is not working.
> 
> /var/log/auth.log:
> 
>

Re: TLS warning

[James B. Byrne]

On Thu, May 25, 2017 05:23, li...@lazygranch.com wrote:
>
>
> This paper is a good read on email security. It goes into the various
> means that a man in the middle can reduce security, one of which is
> enabled by selecting opportunistic encryption. (Of which in all
> practicality you don't have a choice if you want maximum
> compatibility. I'm amazed at the lack of encryption in first world
> countries like Canada or the UK.)
>

Yes, I cannot image why members of the so called 'five-eyes'
consortium would not actively promote signal security among their
populations.

Must be an oversight.

-- 
***  e-Mail is NOT a SECURE channel  ***
Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited  http://www.harte-lyne.ca
9 Brockley Drive  vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada  L8E 3C3

Re: TLS warning

[Phil Stracchino]

On 05/25/17 12:28, James B. Byrne wrote:
> Yes, I cannot image why members of the so called 'five-eyes'
> consortium would not actively promote signal security among their
> populations.
> 
> Must be an oversight.

Or a lack thereof


-- 
  Phil Stracchino
  Babylon Communications
  ph...@caerllewys.net
  p...@co.ordinate.org
  Landline: +1.603.293.8485
  Mobile:   +1.603.998.6958

Re: Issue with SASL authentication

[John Fawcett]

On 05/25/2017 06:20 PM, Daniel Bareiro wrote:
> Hi!
>
> On 24/05/17 21:18, Daniel Bareiro wrote:
>
>> Hi again.
>>
>> On 24/05/17 17:46, Daniel Bareiro wrote:
>>
>>> Maybe this question is not 100% about Postfix, but it is related. I am
>>> configuring a Postifx server with SASL authentication.
>>>
>>> When I do a test to authenticate, I get an error:
>>>
>>> --
>>> root@server2:~# saslpasswd2 -c daniel
>>> --
>>> root@server2:~# testsaslauthd -u daniel -p password
>>> 0: NO "authentication failed"
>>> --
>>>
>>> However it works when I provide the realm:
>>>
>>> --
>>> root@server2:~# testsaslauthd -u daniel -r server2 -p password
>>> 0: OK "Success."
>>> --
>>>
>>> It's strange because I have another mail server where it works without
>>> problems:
>>>
>>> --
>>> root@mail:~# testsaslauthd -u daniel -p password
>>> 0: OK "Success."
>>> --
>>>
>>> Both hosts have Debian Jessie and the SASL configuration is the same:
>>>
>>> --
>>> root@mail:~# grep ^[^#] /etc/default/saslauthd
>>> START=yes
>>> DESC="SASL Authentication Daemon"
>>> NAME="saslauthd"
>>> MECHANISMS="sasldb"
>>> MECH_OPTIONS=""
>>> THREADS=5
>>> OPTIONS="-c -m /var/run/saslauthd"
>>> --
>>> root@server2:~# grep ^[^#] /etc/default/saslauthd
>>> START=yes
>>> DESC="SASL Authentication Daemon"
>>> NAME="saslauthd"
>>> MECHANISMS="sasldb"
>>> MECH_OPTIONS=""
>>> THREADS=5
>>> OPTIONS="-c -m /var/run/saslauthd"
>>> --
>>>
>>> "
Is the contents of the file containing the sasl users and passwords the
same between the two hosts?
John

Re: TLS warning

[lists]

Right from the Telus website :
--
"Clear the Requires a secure connection (SSL) check box"
‎
"Authenticate using: Clear text‎"

‎http://business.telus.com/en/business/support/global/how-to/how-to-set-up-your-email-on-any-computer
---

Seriously Canada? And this is the advice to their business customers. 

‎


  Original Message  
From: Phil Stracchino
Sent: Thursday, May 25, 2017 9:31 AM
To: postfix-users@postfix.org
Subject: Re: TLS warning

On 05/25/17 12:28, James B. Byrne wrote:
> Yes, I cannot image why members of the so called 'five-eyes'
> consortium would not actively promote signal security among their
> populations.
> 
> Must be an oversight.

Or a lack thereof


-- 
Phil Stracchino
Babylon Communications
ph...@caerllewys.net
p...@co.ordinate.org
Landline: +1.603.293.8485
Mobile: +1.603.998.6958

Re: TLS warning

[D'Arcy Cain]

On 2017-05-25 03:20 PM, li...@lazygranch.com wrote:

Right from the Telus website :
--
"Clear the Requires a secure connection (SSL) check box"
‎
"Authenticate using: Clear text‎"

‎http://business.telus.com/en/business/support/global/how-to/how-to-set-up-your-email-on-any-computer
---

Seriously Canada? And this is the advice to their business customers.


Hey!  Canada's a big place.  Don't blame all of us for one company's 
policies.  We don't blame all of you for Microsoft.


--
D'Arcy J.M. Cain
System Administrator, Vex.Net
http://www.Vex.Net/ IM:da...@vex.net
VoIP: sip:da...@vex.net

Re: Why am I accepting this email?

[Bill Cole]

On 24 May 2017, at 9:25, D'Arcy Cain wrote:


I have no server called nan.vex.net


But your DNS says that mail for any addresses @nan.vex.net that might 
exist are handled by mail.vex.net, regardless of whether that name 
represents an actual server or whether mail.vex.net actually can handle 
those addresses. The same is true of any hostname under vex.net, 
implying a wildcard MX record.


I expect that you have or at least have had a reason for that wildcard 
record but you may want to reconsider it.

Re: TLS warning

[Rick Leir]

Telus is so broken in several ways. I complain and the friendly support person 
acts as if nothing is wrong. 

As I understand it, you need to be sending to their SMTP server from 'within 
their network'. Either on their LTE or on their home/business internet service. 
So when you leave your wifi on and it connects somewhere, perhaps in a 
restaurant, then your outgoing email fails auth. And the auth on LTE is by 
IMEI, not by password, so if someone can spoof that... I suspect that is not 
difficult?

Telus is not as big as Microsoft, agreed, but it is one third of our wireless 
industry, so it is big.
Cheers -- Rick

On May 25, 2017 3:26:34 PM EDT, D'Arcy Cain  wrote:
>On 2017-05-25 03:20 PM, li...@lazygranch.com wrote:
>> Right from the Telus website :
>> --
>> "Clear the Requires a secure connection (SSL) check box"
>> ‎
>> "Authenticate using: Clear text‎"
>> 
>>
>‎http://business.telus.com/en/business/support/global/how-to/how-to-set-up-your-email-on-any-computer
>> ---
>> 
>> Seriously Canada? And this is the advice to their business customers.
>
>Hey!  Canada's a big place.  Don't blame all of us for one company's 
>policies.  We don't blame all of you for Microsoft.
>
>-- 
>D'Arcy J.M. Cain
>System Administrator, Vex.Net
>http://www.Vex.Net/ IM:da...@vex.net
>VoIP: sip:da...@vex.net

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com