Scribe Trouble Shooting Guide

Lots of people ask for assistance with Scribe and a lot of the time it comes back to the same issues again and again. So this is a little guide that will help explain the procedures to follow to give yourself the best chance of resolving the issue at hand. You may even find the answer your looking for right here.

Latest Version:

For starters please don't email me until you have at least tried using the latest version of Scribe (even if it's a 'test' version). Especially if the issue is a crash. To keep your old version intact backup the files: To a different directory and then you can restore your current setup if needed.

Connection Issues:

Problems sending and receiving email are quite common and usually are related to incorrect configuration of your settings.

Firstly, anytime you have an issue connecting to a server to send or receive the account will tell you be lighting one of the LED's as red on the status panel on the main window. This tells you there is a problem and you need to look into it. It's deliberately done this way so that errors don't interrupt your work flow. Scribe makes a general rule of not putting up a message box unless you click a command. That way you can compose email in peace even if the connections are failing in the backgroud. This is important for users that don't have a reliable connection or server.

Once an account has failed to connect, open the status panel (on the main window) and click on the account in the list. The first two columns show you the send and receive status. Now you can click on the "Log" tab to see the communication between the client and server for the currently selected account. This is coloured for easy reading, green showing you successful responses from the server, blue marks the commands sent from Scribe and red marks errors from the server. These are the ones to look for. Sometimes the error message will be obvious, and will prompt you to fix something, otherwise if you don't understand it then right click on the log and "Copy to clipboard". Paste the log into an email to me and I'll attempt to decipher it.

If there is no log message that indicates an error then it's probably a bug in Scribe. The next step is to create a log file of the connection. To do this follow these steps:

This produces as execution log, that lists all the sections of code running while the connection thread executes. It can narrow down the part of code that failing.

Another level of logging that can be useful is a content log which can be setup in the debug options. This logs the bytes sent and received across the socket connection. You might want to do that if you feel it's relevant to the problem your having.

Common Sending Errors:

"550 relaying denied" or "550 we do not relay, sorry"
Your ISP's mail server will only send mail from senders it accepts as local to itself, and it's not accepting you as local. A mail server can determin how "local" you are either by the email address you specify in the From: field or by the IP address your connecting from. Generally this error message appears when you specify an external From: address in the outgoing email. e.g.
Server: mail.my-isp.com
From: user@some-other-isp.com
The other common reason is connecting to your mail server from another network outside the ISP's domain. Occasionally this error is caused by a mis-configuration of the mail server itself, and you should contact your ISP's admin staff if you believe the first 2 reasons given above don't apply to you.

Note: 'Relaying' is used by spammers to get someone else to send their spam. Thus most mail servers now days are configured to prevent relaying mail. 

"Syntax error in EHLO command"
You'll get this with ESMTP switched (authenticated SMTP) and you don't have your username setup correctly. In fact username is a misleading field name, as what should really go there is the domain part of your email address. i.e. for the address 'me@privacy.net' the domain is everything after the '@' symbol.

Crashes:

Scribe does on occasion crash, although it really shouldn't. So to best help me to fix a crash start by downloading symbols for the executable. These symbols let the crash handler look up the source code reference for the parts of Scribe currently executing when the crash happens. This information is vital in pinning down where the crash occured. Symbols downloads (when available) are posted to this directory. Look for a zip file named after the version your running, i.e. if your running scribe-win32-v187-test1 then you'll need the symbols file scribe-win32-sym-v187-1.zip

Unpack the symbols into the same directory as scribe[.exe] and start Scribe. Make Scribe crash if you can or wait until it does crash and then afterwards inspect the crashdata.txt file in the Scribe directory. If it has meaningful contents it'll look like: 

Unhandled Exception
  Code: xxxxxxxx
  Description: xxxxx_xxxxx_xxxxx

Call stack:
------------------------------------------------------------------
00413DDD: D:\Code\Scribe\Code\ScribeApp.cpp Line: 2771
10028685: d:\code\lgi\debug\Lgi.dll
00413499: D:\Code\Scribe\Code\ScribeApp.cpp Line: 2572
1002285F: d:\code\lgi\debug\Lgi.dll
77E12E98: D:\WINNT\system32\USER32.dll Offset: 0x490 (ScrollDC)
0041D185: D:\Code\Scribe\Code\ScribeMain.cpp Line: 87
77E97D08: D:\WINNT\system32\KERNEL32.dll Offset: 0xDA8 (CreateProcessW)
------------------------------------------------------------------
If it looks like this: 
Unhandled Exception
  Code: xxxxxxxx
  Description: xxxxx_xxxxx_xxxxx

Call stack:
------------------------------------------------------------------
------------------------------------------------------------------
Then it's of no use to me. The most likely reason for this is that the crash handler can't find the symbols or the DLL's for reading the symbol files aren't on your system. To fix this you can download some extra DLL's for debugging from here.

Once you have some good crashdata.txt information to send me, please also include some description of what your doing when the crash occured. So that I have some idea where to look in the code.

Damaged Folders:

If you have folders that Scribe can't open because of corruption or a crash. Then your only alternative is to try the dumping the folders to a new file using this [win32] tool. Run folder dump from the command line like this: 
FolderDump c:\path\folders.mail2 -s -a
And you'll see a whole lot of debug information scroll past. At the end there should be a file called 'export.mail2' created in the current directory. This has all the detectable objects from the source folder reconstructed into a new heirarchy. It doesn't fix any objects that are internally damaged but it does fix the relationships between objects and also reattaches orphaned objects to new folders called "Ophan [Object-Type]". You should be able to then load this in Scribe using the File -> Open Folders command.

The file format is available as 2 text files. As is the source for folder dump. If folder dump doesn't work for you and you are familiar with C++ I suggest you download the source and format specifications (you'll need LGI as well) and have a go at figuring out why folder dump didn't work for your particular folders. Folder dump is mostly stand alone code, but it does use at least a few headers from Lgi.