eike.hoffmann

Q: 10.10.4 Mail SMTP problem

Hi,

 

I know, that there are other discussions regarding Apple Mail not sending mails via SMTP. Most of these SMTP-servers do not use a strong DH key (logjam). But my problem is different.

 

I'm using a self operated mail server with dovecot (and dovecot SALS) and postfix. The server already uses strong DH keys and strong encryption. TLSv1.0 is available, but not v1.1 or higher.

 

Actually I had no problems before 10.10.4. The problems started after I upgraded to 10.10.4.

 

I use a payed Google Apps account in combination with my own SMTP server for sending mails. So Google Apps IMAP for incoming, my own SMTP server for sending mails.

 

I tried changing the configuration, but it simply does not work. Apple Mail connects, but sends no password.

 

The servers mail.log says simply:

 

Jul 13 10:09:21 aldur postfix/smtpd[28176]: warning: unknown[x.x.x.x]: SASL LOGIN authentication aborted


The connection log says (garion is my MacBook):


Jul 13 10:09:47 garion Mail[1346] <Debug>: Connected: <MFSMTPConnection: 0x60000057a580> (Connected) account: A{SMTP - 534CDE8D-59E7-4698-8A0E-ABF14A273AB5}

  hostname: hostname.domain.de, port: 465, security layer: kCFStreamSocketSecurityLevelTLSv1_0

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] >> EHLO  (19 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-hostname.domain.de

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-PIPELINING

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-SIZE 110000000

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-VRF

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-ETRN

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-AUTH PLAIN LOGIN

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-AUTH=PLAIN LOGIN

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-ENHANCEDSTATUSCODES

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250-8BITMIME

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 250 DSN

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] >> AUTH  (5 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 334  (12 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] >>  (12 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 334  (12 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] >> * (0 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 501 5.7.0  (22 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] >> QUIT (0 additional bytes)

Jul 13 10:09:47 garion Mail[1346] <Debug>: [0x60000057a580] << 220  (28 additional bytes)

 

Interessting are the bold lines. Apple Mail successfully connects to my SMTP server via TLSv1.0. It sends the EHLO and starts AUTH (first bold line). Thre server responds "give my your login name" (second bold line). Mail responds "here it is" (third bold line, 12 Byte BASE64 encoded login name). Then servers asks "ok, now give me your password" (fourth bold line). And Apple Mail respons with 0 bytes, so an empty password.

 

But the password is correctly set. It's stored in keychain, too.

 

My first solution was to use Airmail 2 and wait until a solution may be discovered (I upgraded to 10.10.4 when it was released). But up to now, there is no fix...

 

The problem is clearly Apple Mail, because other clients do not have any problems. Even the local postfix on my MacBook works. I configured the local postfix on my MacBook to forward all e-mails to my SMTP server, using PLAIN authentication. This works without problems.

 

Currently I configured Apple Mail to send mails through the local postfix (which forwards them to my SMTP server...).

 

But this can't be the final solution, as Apple Mail should be able to do it, too.

 

Currently I'm out of ideas... Maybe someone else can help.

 

Best regards,

Eike Hoffmann

MacBook Pro (Retina, 13-inch, Late 2013), OS X Yosemite (10.10.4), null

Posted on Jul 13, 2015 1:35 AM

Close

Q: 10.10.4 Mail SMTP problem

  • All replies
  • Helpful answers

first Previous Page 3 of 5 last Next
  • by eike.hoffmann,

    eike.hoffmann eike.hoffmann Jul 17, 2015 1:27 AM in response to ASnoeren
    Level 1 (0 points)
    Jul 17, 2015 1:27 AM in response to ASnoeren

    EDIT3: Some more things I found out. When creating the SMTP server using the steps above the password for the SMTP account is correctly saved. When I close the SMTP settings dialog and reopen it without setting the newly created SMTP server entry as the active SMTP server I can see that the password is saved (the dots...).

     

    Bildschirmfoto 2015-07-17 um 10.19.42.png


    Now, when I set the newly created SMTP server entry as the active SMTP server and reopen the SMTP server settings the password field is empty. So Mail lost the password ... but ony if "Automatically detect and maintain account settings" is enabled in both places.


    Bildschirmfoto 2015-07-17 um 10.23.45.png


    @ASnoeren: Yes, you are right. Sending only works, if you disable this auto detect feature. I accidently used the other server for sending . All seems to be related to EDIT3. Mail app loses the password if auto detect is enabled and the server is set as the active server for sending.

  • by Lionchild,

    Lionchild Lionchild Jul 17, 2015 5:51 AM in response to eike.hoffmann
    Level 1 (90 points)
    Jul 17, 2015 5:51 AM in response to eike.hoffmann

    Eike -

     

    I believe that in installations where this is working and it "suddenly stops" working, checking the saved password under the SMTP server settings will find that it's blank.  My question is, what's causing the password to be lost in that field?  Is it the 'Automatically detect and maintain account settings' being enabled that's causing this behavior at some random point?

     

    An installation like this using 2-step authentication with an app-specific password that should never change with a 16-character randomly generated password seems to work in a stable state for anywhere between 2 weeks and 4 months, then suddenly is broken and won't send.  Has anyone else seen this sort of event happening?

  • by CTP_9,

    CTP_9 CTP_9 Jul 17, 2015 10:04 AM in response to eike.hoffmann
    Level 1 (0 points)
    Jul 17, 2015 10:04 AM in response to eike.hoffmann

    Thanks to everyone for their contributions here. It's been helpful in narrowing down the problem.

     

    I followed steps 1-13 (up to getting the problem server showing green in the Connection Doctor after setting it as the sending server). And I made sure to uncheck both of the auto detection boxes. It looked very promising because it was still green in the Connection Doctor and when I reopened the connection settings dialog I could see the password field still populated. When I actually tried sending, however, the connection failed. It is now red in the Connection Doctor again, the password field is empty again and no password is being sent during the authentication process.

  • by ClausFromSchwäbischHall,

    ClausFromSchwäbischHall ClausFromSchwäbischHall Jul 17, 2015 10:41 AM in response to eike.hoffmann
    Level 1 (0 points)
    Jul 17, 2015 10:41 AM in response to eike.hoffmann

    Thanks, I deleted the old not working SMPT accounts and created it new with you settings.

    After the connection was online, I assigned it the the mail account and it works.

  • by eike.hoffmann,

    eike.hoffmann eike.hoffmann Jul 17, 2015 11:10 AM in response to ClausFromSchwäbischHall
    Level 1 (0 points)
    Jul 17, 2015 11:10 AM in response to ClausFromSchwäbischHall

    Kein Problem Claus

  • by eike.hoffmann,

    eike.hoffmann eike.hoffmann Jul 17, 2015 11:11 AM in response to CTP_9
    Level 1 (0 points)
    Jul 17, 2015 11:11 AM in response to CTP_9

    I can't explain that. I think it's time for someone who actually develops on Mail.app...

  • by Ryan Homer,

    Ryan Homer Ryan Homer Jul 19, 2015 4:49 AM in response to eike.hoffmann
    Level 1 (99 points)
    iPod
    Jul 19, 2015 4:49 AM in response to eike.hoffmann

    Same here with OS X 10.10.4.

     

    I've spent the last two days doing not much else but trying to figure this out... to no avail. I'm stuck at the same point where I get that "Failed a step of SASL authentication" (32775) on the Mac and "warning: unknown[client.ip.address.here]: SASL LOGIN authentication aborted" server-side. I am running Ubuntu 14.04 (server1) with postfix and SASL. I've tried both Cyrus and Dovecot SASL. I've set up my Gmail web interface to send mail using this server as the SMTP server (TLS, port 587) and it works. Apple Mail bombs out. I've already updated my postfix configuration for logjam and that didn't seem to help any.

     

    I also have another server, also running Ubuntu 14.04 (server2) as well. This one has Dovecot set up for pop3s/imaps and uses Cyrus SASL for authentication. This server was set up BEFORE the wretched, under-documented Apple Mail update and surprisingly survived the update and continued working. I haven't even generated a new, unique DH Group for it yet. I've done lots of comparison between these two servers and still haven't been able to figure out why Apple Mail can send on one but not the other. Interestingly, when this server authenticates, the log indicates that it was PLAIN, not LOGIN.

     

    Upon revisiting the logs of server1, I have just noticed that Gmail (web) also authenticates using PLAIN. So we have Gmail using PLAIN on server1 and Apple Mail using PLAIN on server2. So why is Mail attempting to authenticate using LOGIN on server1?

     

    Well, food for thought. Will take another stab at it when I recompose myself!

  • by joedjjjjj,

    joedjjjjj joedjjjjj Jul 19, 2015 7:18 PM in response to eike.hoffmann
    Level 1 (0 points)
    Jul 19, 2015 7:18 PM in response to eike.hoffmann

    I am seeing exactly the same behaviour as you Eike, and have come to the same conclusion that this is a bug in Mail.app.  I don't have a workaround.  Let's hope they fix it in 10.10.5 ...

  • by eike.hoffmann,

    eike.hoffmann eike.hoffmann Jul 20, 2015 12:04 PM in response to eike.hoffmann
    Level 1 (0 points)
    Jul 20, 2015 12:04 PM in response to eike.hoffmann

    I installed the current beta of 10.10.5. The problem is still there.

  • by Lionchild,

    Lionchild Lionchild Jul 20, 2015 12:11 PM in response to eike.hoffmann
    Level 1 (90 points)
    Jul 20, 2015 12:11 PM in response to eike.hoffmann

    Eike -

     

    Did you say the problem remained after turning off the "Automatically detect and maintain account settings" function?  (In 10.10.4 or 10.10.5?)

  • by eike.hoffmann,

    eike.hoffmann eike.hoffmann Jul 20, 2015 3:06 PM in response to eike.hoffmann
    Level 1 (0 points)
    Jul 20, 2015 3:06 PM in response to eike.hoffmann

    @Lionchild

     

    I can't see your post here, but I got the mail... So: I upgraded to 10.10.5 beta and tried setting up the SMTP account. The same problem as before with 10.10.4. I think it would work if I uncheck "Automatically detect...". But this is not a option for me, as my IMAP server would not work anymore. So I did not try that.

  • by Lionchild,

    Lionchild Lionchild Jul 20, 2015 3:33 PM in response to eike.hoffmann
    Level 1 (90 points)
    Jul 20, 2015 3:33 PM in response to eike.hoffmann

    Eike -

     

    The "Automatically detect..." is -required- for your server side?  Let me make sure I have this right:  We can't set/force the type of authentication from our side, if we want the higher level protection, we have to use the "Automatically detect.." to get it?

  • by eike.hoffmann,

    eike.hoffmann eike.hoffmann Jul 21, 2015 12:33 PM in response to Lionchild
    Level 1 (0 points)
    Jul 21, 2015 12:33 PM in response to Lionchild

    Yes: "We can't set/force the type of auth... from our side..." If we want XOAuth2 we need to set "Password" and "Auto detection"=true. If the incoming server uses a different (less/more secure) auth mech as the outgoing this will not work (my case).

     

    If "Auto detect"=true Mail seems to try to use the same mech on incoming and outgoing (or none at all, as no auth works with "auto detect"=true). I think there is something mixed up in the configuration. The outgoing tries to use the incoming auth mech, because it was the last used. Or something like that...

     

    I like Apple Mail Everything else is Bullsh...

    Apple, please fix this.

     

    Thanks.

  • by Lionchild,

    Lionchild Lionchild Jul 23, 2015 1:22 PM in response to eike.hoffmann
    Level 1 (90 points)
    Jul 23, 2015 1:22 PM in response to eike.hoffmann

    Eike -

     

    I like the way Apple Mail works too!  Not to mention how well it works with iCal and Contacts.

     

    As a Developer, were you able to submit the bug to Apple under the 10.10.5 beta program?

     

    I'm going to try to do some testing of un-checking the "Automatically Detect" feature and see if that stops causing the Mail App to forget it's SMTP password in the Account configuration.  I think that's what's happening in my situation with Gmail and 2-step authentication.

  • by ClausFromSchwäbischHall,

    ClausFromSchwäbischHall ClausFromSchwäbischHall Jul 25, 2015 10:33 AM in response to eike.hoffmann
    Level 1 (0 points)
    Jul 25, 2015 10:33 AM in response to eike.hoffmann

    Eike,

    I had the same Problems as you until I deleted my old not working SMTP account configurations.

     

    But not only from inside mail, too from defaults.

     

    Both not workings accounts were found with defaults!

     

    defaults read com.apple.mail DeliveryAccounts > DeliveryAccounts.log

    defaults delete com.apple.mail DeliveryAccounts

     

    Than I added the DeliveryAccounts completely new after your receipt, but only from mail!

    The defaults read com.apple.mail DeliveryAccounts is now not found!

     

    First I used it without  "Automatically Detect" and later with this option checked.

     

    And still it works

     

    Claus

first Previous Page 3 of 5 last Next