datawookie/emayili

Exegetic email

Closed this issue · 7 comments

Hi

I tried to use the package with an email account with the domain name "exegetic.biz". When I try to use this domain to send an email I get the error:

emayili_3

I also had a warning email from Google in my mailbox: "Someone just used your password to try to sign in to your account from a non-Google app. Google blocked them, but you should check what happened. Review your account activity to make sure no one else has access."

Thanks for the issue, Gary. I've just done some testing and this is what I've found:

  • can't send email on my exegetic.biz account using {emayili} but
  • can send email on my exegetic.biz account using curl from the command line.

Just need to figure out what extra curl options are being applied on the command line.

Weirdly, I tried sending email from my exegetic.biz account again this evening and now it works fine.

However, I also sent email from the command line first. So maybe that had something to do with it.

Can you please do some testing for me?

Run the following in the terminal:

curl -v --mail-from "andrew@exegetic.biz" --mail-rcpt "andrew.b.collier@gmail.com" \
--user andrew@exegetic.biz:$PWD --ssl smtp://smtp.gmail.com:587

Replace my work/personal addresses with yours. Also store your work password in environment variable PWD like this first:

export PWD="my_secret_password"

Record the result from the curl command and post it here. Then try sending email using {emayili}. Does it work?

Can you also please send me the output from when you try to send email using {emayili}? If you use verbose = TRUE when you send the email there should be a flurry of output in the console. This will help me with debugging.

After you've tried the above, you could also try allowing access from less secure apps. Let me know if that makes a difference.

curl -v --mail-from "gerard@exegetic.biz" --mail-rcpt "andrew.b.collier@gmail.com"
--user gerard@exegetic.biz:$PWD --ssl smtp://smtp.gmail.com:587

* Rebuilt URL to: smtp://smtp.gmail.com:587/
*   Trying 64.233.166.108...
*   Trying 2a00:1450:400c:c0c::6c...
* Immediate connect fail for 2a00:1450:400c:c0c::6c: Network is unreachable
* Connected to smtp.gmail.com (64.233.166.108) port 587 (#0)
< 220 smtp.gmail.com ESMTP f24sm3366541wmb.16 - gsmtp
> EHLO gerrywalsh-GL702VMK
< 250-smtp.gmail.com at your service, [197.88.54.164]
< 250-SIZE 35882577
< 250-8BITMIME
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-PIPELINING
< 250-CHUNKING
< 250 SMTPUTF8
> STARTTLS
< 220 2.0.0 Ready to start TLS
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 597 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
* 	 server certificate verification OK
* 	 server certificate status verification SKIPPED
* 	 common name: smtp.gmail.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: C=US,ST=California,L=Mountain View,O=Google LLC,CN=smtp.gmail.com
* 	 start date: Tue, 30 Apr 2019 09:06:33 GMT
* 	 expire date: Tue, 23 Jul 2019 09:02:00 GMT
* 	 issuer: C=US,O=Google Trust Services,CN=Google Internet Authority G3
* 	 compression: NULL
* ALPN, server did not agree to a protocol
> EHLO gerrywalsh-GL702VMK
< 250-smtp.gmail.com at your service, [197.88.54.164]
< 250-SIZE 35882577
< 250-8BITMIME
< 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
< 250-ENHANCEDSTATUSCODES
< 250-PIPELINING
< 250-CHUNKING
< 250 SMTPUTF8
> AUTH LOGIN
< 334 VXNlcm5hbWU6
> Z2VyYXJkQGV4ZWdldGljLmJpeg==
< 334 UGFzc3dvcmQ6
> OTkyR1QyUlM=
< 535-5.7.8 Username and Password not accepted. Learn more at
< 535 5.7.8  https://support.google.com/mail/?p=BadCredentials f24sm3366541wmb.16 - gsmtp
* Closing connection 0
curl: (67) Login denied

I get the same warning from Google about a blocked sign-in attempt. I think that it was "unrecognized device" could play a part in this issue?

emayili_4

And from {emayili}:

emayili_5

Changing the "less secure access" solves the problem, for both instances