It seems that I have located a problem with the Postie extender. It is not a bug, but a limitation. The length of the userid and password used in Kinit have a combined limit when using kGetMail. For example, the userid of winbatch@test.com only allows a password length of 35 characters. If using winbatch1@test.com, the password length can only be 34 characters. The length of host and fromaddr doesn't have any impact.
Example code:
AddExtender("WWPST44I.DLL")
host="mail.test.com"
fromaddr="winbatch@test.com"
userid="winbatch@test.com"
password="AzS5BbjRyF1234567890123456789012345"
port="143"
kInit(host,fromaddr,userid,password,port)
msgnumber=""
outputfile=""
pat = "Test *"
mailbox=""
flags="4h"
result=kGetMail(msgnumber,outputfile,pat,mailbox,flags)
Message("result", result)
Exit
Adding a 6 to the end of the password (after changing it on the email server too) causes kGetMail to return:
"Could not log in as <email address> to: <mail host>:143@CRLF2 NO [AUTHENTICATIONFAILED] Authentication failed.@CRLF@CRLF"
I tested with other email software (Thunderbird) on the same server and used 50 character email addresses and 100 character passwords without issue.
It would be sincerely appreciated if the Postie extender would be updated to allow longer usernames and passwords. Since some of the email servers I deal with require the full domain name in the userid in order to login, there are some very long email addresses (pushing 50 characters), and the user may be required use very long passwords (I've seen them higher than 65 characters) for their email accounts, I'd be grateful to see Postie updated to increase the total length allowed.
First, thank you for reporting the problem. Postie doesn't have hard coded limits on the user name and password combination length so whatever your problem is, it isn't as simple as might appear. Since according to your script you are using plain text authentication, It may or may not be caused by some disagreement about how the the user name and password are base 64 encoded or something.
Whatever the cause, it is unlikely that any resolution will be found anytime soon so you may do well to assume that no new version of the extender is forthcoming in the foreseeable future.
Many email servers support multiple authentication protocols so you could try using the Postie extender with cram-md5 authentication instead of plan text. Of course, your server would need to support cram-md5 as well.
Sorry, my fault for posting too late and not clarifying the issue correctly.
The limit only appears with IMAP connections, not with POP3. I initially used TLS and changed to plain text for testing to make sure security was not the issue.
I'm not expecting an update to Postie anytime soon. I'm working around this issue for now. But since most of the projects I do these days with WinBatch use the Postie extender, I'm hoping to get any issues with it resolved and tested before WinBatch reaches retirement June 30, 2017.
Unless you are using client side certificates (which Postie does not support), using TLS would not affect any user name+password base 64 encoding issues.
Am I missing something obvious? I don't see any way to use cram-md5 with kGetMail.
You would need to have the mail server list the protocol as a capacity then it happens automagically. Should have mentioned that.
BTW, we have identified a bug in the IMAP code that calls the base 64 encoding module within the extender. The default base 64 encoding setting is 72 byte encoded line lengths and the IMAP code never indicates otherwise. The IMAP protocol dictates that the username+password response should be on a single encoded line.
This will be fixed in the next extender release.
Just wanted to say "Thank you" for the Postie Extender update (http://forum.winbatch.com/index.php?topic=1708.0) that corrects the IMAP line length. I just downloaded it (via vcheck) and will test this weekend.
The new release should fix the problem. Please let us know either way.
Line length issue is corrected by the updated extender. Now I've run into another oddity.
When using the simplified code below, all of the email messages are marked as read... except the oldest email (the first returned in the result).
AddExtender("WWPST44I.DLL")
host="mail.test.com"
fromaddr="winbatch@test.com"
userid="winbatch@test.com"
password="myreallylongpassword123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
port="993"
security="TLS"
kInit(host,fromaddr,userid,password,port,security)
msgnumber=""
outputfile=""
pat = ""
mailbox=""
flags="4h" ; Get only headers using imap4.
result=kGetMail(msgnumber,outputfile,pat,mailbox,flags)
Message("result", result)
Exit
We cannot reproduce that behavior.
Private Message sent with email credentials and webmail access.
The IMAP standard indicates that header only fetches should not cause a message to be marked as read (\SEEN). Because of available options requirements that affect the way the extender fetches headers, servers consider the first message of a multiple message header request just that but consider subsequent header fetches as not just header request.
Changing the way the extender performs IMAP header fetches has several undesirable side-effects so it is not likely to be changed any time soon. While it may not always be practical, you could consider retrieving one message at a time to leave all unread messages marked as 'unread'.
That makes perfect sense. Thank you for looking into the issue.
My opinion is this falls under 'Needs to be documented somewhere' such as the tech database or help file rather than modifying the extender.
Your patients and thoughtful cooperation has been much appreciated.
I'm sure that you look forward to me adding to this thread Tony...
I think I've found a couple of more issues with Postie. The first appears to be similar to the headers-only fetch issue. The following simplified code does not purge any of the emails.
AddExtender("WWPST44I.DLL")
host="mail.test.com"
fromaddr="winbatch@test.com"
userid="winbatch@test.com"
password="MyPassword"
port="993"
security="TLS"
kInit(host,fromaddr,userid,password,port,security)
msgnumber=""
outputfile="test.txt"
pat = ""
mailbox=""
flags="4rd" ;imap4, raw, mark for deletion.
result=kGetMail(msgnumber,outputfile,pat,mailbox,flags)
Exit
As you can see, I'm not using the headers flag. But I am using IMAP4, Raw, and Delete flags. If I remove the Raw flag, the emails are deleted.
The second issue is sending emails. It's similar to my original issue in this thread with long passwords. But rather than being variable with the combined length of the userid, it's a set limit of 54 characters. 55 character passwords fails.
AddExtender("WWPST44I.DLL")
host="mail.test.com"
fromaddr="winbatchx@test.com"
userid="winbatchx@test.com"
password="MyInsanelyLongPassword123456789012345678901234567890123" ;55 characters
port="25"
kInit(host,fromaddr,userid,password,port)
tolist="winbatch@test.com"
cclist=""
bcclist=""
kDest(tolist,cclist,bcclist)
flags="e"
attachments=""
subject="Example"
body="This is a test message"
ret = kSendText(subject,body,attachments,flags)
Exit
We very much appreciate the bug reports and feedback . The Postie extender is made up of a very large code base of third party source code with more than few WindowWare implemented defect fixes. It does the job for most users but it is not perfect. Given the amount of time required to address defects because of the large code base and limited resources, we cannot immediately address every issue. So when there is a viable alternative, that alternative is recommended. Reported defects are noted and, hopefully, an attempt to address them will be made as resources permit. To that end:
1. Postie options can be mutually exclusive and no not all of them are documented as such nor are they likely to be in the near future. So when you find such cases make a note to yourself to not use the combination again. It may also be the case that the extender can be modified in some fashion at some point in the future to handle both options simultaneously.
2. WinBatch has many ways besides Postie to send email so you may want to consider using one of them when you encounter a real-world password length problem.