- ehlo www.palm.com
STARTTLS
AUTH LOGIN
And Postfix 2.4.5 is replying: Error: send HELO/EHLO first
The problem there is that EHLO should have been upper case it's not sending another EHLO after STARTTLS. Turning off smtpd_helo_required is a workaround.
My question, dear Lazyweb:
- Where's the Palm Pre WebOS Bugzilla? How do I report this bug in such a way that it will actually reach a developer who can say, "Oh, duh" and actually check in a fix?
If there is not a public bug reporting mechanism, then next best would be for someone to point me at your friend who works there who is willing to take mailed reports from me directly...
I would be surprised if the lower-case "ehlo" is the problem. A much more likely explanation is that it didn't send EHLO again after STARTTLS.
"Upon completion of the TLS handshake, the SMTP protocol is reset to the initial state (the state in SMTP after a server issues a 220 service ready greeting). The server MUST discard any knowledge obtained from the client, such as the argument to the EHLO command, which was not obtained from the TLS negotiation itself. The client MUST discard any knowledge obtained from the server, such as the list of SMTP service extensions, which was not obtained from the TLS negotiation itself. The client SHOULD send an EHLO command as the first command after a successful TLS negotiation."
It's not a requirement though.
http://www.rfc-editor.org/rfc/rfc2487.txt
The reason it's a SHOULD not a MUST is because you can get away without it if you do not subsequently need to use any ESMTP extensions. That is not true in this case.
This is what it sends:
← 220 [...] ESMTP Postfix
→ ehlo http://www.palm.com
← 250-[...]
← 250-PIPELINING
← 250-SIZE
← 250-VRFY
← 250-ETRN
← 250-STARTTLS
← 250-ENHANCEDSTATUSCODES
← 250-8BITMIME
← 250 DSN
→ STARTTLS
← 220 2.0.0 Ready to start TLS
→ AUTH LOGIN
← 334 [...]
→ [...]
← 334 [...]
→ [...]
← 235 2.0.0 Authentication successful
→ MAIL FROM:<...>
← 250 2.1.0 Ok
→ RCPT TO:<...>
← 250 2.1.5 Ok
→ DATA
← 354 End data with <CR><LF>.<CR><LF>
← 250 2.0.0 Ok: queued as [...]
→ QUIT
← 221 2.0.0 Bye
re-reading full log-- it's not your phone, its your server, it accepted the mail.
That's only after I turned off smtpd_helo_required.
are you saying this email didnt show up though?
No, this one worked. "Turn off smtpd_helo_required" equals "mail works now". Which means the original problem was that the phone doesn't send the second EHLO.
Ah then problem solved-- to be fair in the vendors defense, turning on a lot of the checks postfix has the capability to do out of the box deters a lot of spam, but blocks a lot of legitimate things as well-- its mostly crap MUAs, but you know that.
he's saying something is wrong with the client side on the palm, not the server side..
Because you were so kind to help me with my English, I'll help you with yours; quid pro quo.
Ah then problem solved--
"Oh Okay, I see that the email log you posted showing the full transaction is post-postfix configuration changes; problem solved its obviously an issue with the client not resetting after STARTTLS."
to be fair in the vendors defense,
"To expand upon the above thought..."
turning on a lot of the checks postfix has the capability to do out of the box deters a lot of spam, but blocks a lot of legitimate things as well--
"Using many of the available postfix configuration options blocks a lot of spam, but it blocks a lot of legitimate email [to a point that you may not even notice it unless you miss a specific email, ala one from your phone..."
its mostly crap MUAs,
"You have to be careful with this, not because anything postfix is doing is incorrect, but there's a lot of buggy MUAs that don't follow the standards or don't follow all of the 'SHOULD' statements."
but you know that.
"But I'll give you (jwz) the benefit of the doubt and assume you're (jwz) intelligent enough to know this already"
For your sake I hope you're at least hot.
hot and paid a lot more money to come fix your mistakes @ msft.
Let's also not forget that "www.palm.com" is not the proper argument for the phone to be sending in the HELO/EHLO command.
per RFC, you need to wait for a response before sending STARTTLS or anything else, EHLO/HELO, then wait.
I don't know if there is public Bugzilla, but I went to the early developer's camp for Web OS and have access to the internal bug system.
I'll pass the word along.
Unfortunately there doesn't appear to be a public bug tracker. At least not currently
http://forums.palm.com/palm/board/message?board.id=webossoftware&thread.id=881
The best place to report bugs that I have found is their forum. There is not much acknowledgment of issues from Palm staff, but they do read the forums and supposedly the bugs go into an internal tracking system.
http://forums.palm.com/palm/board/message?board.id=webossoftware&thread.id=416
In this thread is the most official thing I have seen about updates and fixes:
http://forums.palm.com/palm/board/message?board.id=webossoftware&thread.id=2545
I've got a buddy on Facebook (used to work with him at QNX) who's a developer at Palm on WebOS, I've asked him to send you email if he can help you out.
Palm Pre SSH & root hack. You might be able to do your own "bug fix" this way.
While I remember, thank you for being one of the brave 'first kids on the block' to try this - your pain is very useful for everyone else considering whether or not to get one.