Freron MailMate

Comments and changes to this ticket

• 

  benny August 27th, 2011 @ 03:18 PM

  • Assigned user set to “benny”

  No, MailMate should be fully functional until after 30 days of active use. You should of course not buy a license before this and the mailbox issue have been resolved. I hope you are willing to help me track down the problems.

  First of all, could you provide the error message given. And it would also be very useful with the corresponding log from the Activity Viewer (⌘0).

• You flagged this item as spam.
  

  Matthew Bunn August 27th, 2011 @ 08:51 PM

  I can't figure out how to copy what's in the Activity Viewer box to send it to you -- let me know how to do that, and I'll go ahead and do so (for both tickets).

• You flagged this item as spam.
  

  Matthew Bunn September 1st, 2011 @ 12:47 AM

  Now I have an additional problem: it's pretending to fail in sending e-mail. I hit "send," it sits for a while and then sends me an error message saying it was unable to send, and offers me the option to edit message or to retry. If you edit message and then try again, the same thing happens. Nothing turns up in the sent messages folder. But it turns out it was actually sending these messages -- one of the people I wrote to got 12 copies of the same message, from my various attempts to send it.

  Any thoughts?

• 

  benny September 1st, 2011 @ 05:19 AM

  Yes, based on the output you sent for SMTP, I think it is related to a
  too short timeout value when sending messages. MailMate waits for the
  server to reply after uploading the message, but gives up before the
  server actually replies. This is always a problem in theory (which
  cannot be solved), but apparently for this server it is very often a
  problem in practice.

  If you write a private email to me then I'll make (and provide
  instructions on how to get) a cutting edge beta for MailMate with a
  larger timeout value.

  If you have been able to obtain additional information about the IMAP
  problem (special Exchange folders) then that is also welcome by email
  (any logging is likely to contain private information). There is a feedback menu item in the Help menu.

• 

  benny September 1st, 2011 @ 05:23 AM

  It just occurred to me that I can also improve the error message given
  to state that it is unknown whether or not the message was sent.

  And I'm sorry about the many copies sent. I also hope the receiver was
  not too upset by this issue.

• 

  benny November 14th, 2011 @ 12:08 PM

  • State changed from “new” to “fixcommitted”

  I believe this problem was fixed by the larger timeout value described.

• You flagged this item as spam.
  

  Bill Cole November 22nd, 2011 @ 02:03 AM

  • Tag set to “standard compliance rfc5321”

  Please note: the proper timeout for a client at the end of DATA is 10 MINUTES according to every RFC addressing SMTP timeouts, dating back to 1989 (RFC1123) and being re-affirmed as recently as 2008 (RFC5321) MailMate's use of a 15-second timeout in released versions causes problems as described in this ticket due primarily to spam filters in MTA's, but there are also some systems that do not reply to the second step of the DATA command until they have handed off the message to the next hop (or at least completed an attempt to do so that has resulted in queueing the message for a later retry.)

  If the new timeout is something less than 10 minutes, MailMate will continue to be out of compliance with the specification of SMTP.

• 

  benny November 22nd, 2011 @ 08:19 AM

  I was wondering when someone was going to bring up the standard :-) I wasn't actually aware (or forgotten) that the timeout values had been confirmed in 2008.

  I already have a note in my code about following the standard timeouts more closely (and the requirements of making them configurable), but it has not been a high priority. The special end of DATA timeout does make a lot of sense though. The other timeout values smell like over-specification. In one case it is even useless:

  4.5.3.2.3.  RCPT Command: 5 Minutes
  
      A longer timeout is required if processing of mailing lists and
      aliases is not deferred until after the message was accepted.
  

  So how does the client know whether or not such processing is deferred? And how long should it wait? (Rhetorical questions :-) ).

  I'll make sure (right now) that the timeout for end of DATA is 10 minutes since that is the important one. At worst, the other time out values are going to cause a retry for delivery later (which MailMate is also better at in the next release).

• 

  benny November 22nd, 2011 @ 03:18 PM

  Not that it changes anything, but I remembered reading something about SMTP timeouts recently, so for the sake of completeness: RFC6409. It only deals with port 587 and recommends that all commands are replied within 2 minutes.

• 

  benny December 22nd, 2011 @ 01:10 PM

  • State changed from “fixcommitted” to “fixreleased”

  [bulk edit]