Root > Basic procedures > Configuring sending report > Selecting send method

Selecting send method

Previous pageReturn to chapter overviewNext page   

Unfortunately, there is no best sending method for your bug reports - each way have its own advantages and drawbacks.


Important note: there are events for customizing sending: such as OnAttachedFilesRequest, OnZippedFilesRequest, and OnCustomWebFieldRequest.



First, let's start with common properties for each group:



E-mail methods


Simple and familiar.
Can be send manually (good as "last resort measure").
Clients most likely have e-mail access, so sending have good chances to succeed.
Good for basic support for unsupported web-trackers (see also).


Depends on client's environment. You can't control it. May be blocked by firewall.
No backward feedback - you can't tell customer that this problem is already solved.
No bug report management (however, you can use EurekaLog Viewer to collect reports from e-mail account).



Web methods


Simple and controllable.
May be customizable.
Simple setup.
SSL/TLS support.
HTTP(S) access is usually allowed by firewall.


No bug report management.
User e-mail address is optional.
Require hosting or server.



Web-trackers methods


Powerfull and customizable.
Bug report management.
SSL/TLS support.
HTTP(S) access is usually allowed by firewall.


Requires setup.
Require hosting or server + database.
User e-mail address is optional.
Requires setup for each your project.


Note: bug trackers and e-mail methods are close-related: bug trackers are usually able to parse incoming e-mails and insert them as issues into database. Thus, you can get non-supported bug tracker working (by setuping it to parse e-mails and setup e-mail sending in EurekaLog). Also, web trackers usually can generate e-mail notifications about new issues.



Now, let's take a look at each method (common advantages/drawbacks aren't listed). Only major points are listed below. For detailed pros/cons of each method - please see description of each method.



E-mail: Shell (mailto protocol)


Available always


High amount of limitations (not customizable, no attaches, etc.)


Conclusion: good for "last resort" measure only, have many limitations. See also: Dealing with send failures


Note: due to "no way to get real send result" - it's best to place this method last, if you select several methods.



E-mail: Simple MAPI


Most common protocol for 3rd party e-mail clients


Obsolete protocol, not supported by modern Outlook
Modern desktops and laptops may use web e-mail client, so there will be no desktop e-mail client installed


Conclusion: good for e-mail sending in corporate environments, but no longer a good choice on modern desktops, which use web-clients for e-mails (e.g. there is no desktop e-mail app). Suitable as "last resort" measure. See also: Dealing with send failures



E-mail: MAPI (also known as "Extended MAPI" or "MAPI 1.0")


Supported by Outlook and Exchange


Not supported by other e-mail clients


Conclusion: good as alternative for SMAPI in case your users use Outlook/Exchange. Avoid in typical software outside of controlled corporate environments.



E-mail: SMTP client


Most reliable e-mail protocol


You must store your real e-mail account details (login/password) in your application


Conclusion: best choice for most cases.



E-mail: SMTP server


Most powerful method with low limitations


It's usually blocked by ISPs to block spam software


Conclusion: good method with low limitations, but only if it's not blocked by client's firewall, ISP or your e-mail server. Not very reliable on practice. Worth trying as "last resort" measure.





Simple and highly customizable.


A lot of custom work to get anything above simple upload functionality.


Conclusion: good as base for building custom sending. Very good for hiding passwords behind a facade. For simple file uploads - FTP is a preferred way.



Web: FTP


Minimum efforts to setup (among all web methods, including web-trackers), very reliable


No other functionality except simple bug reports upload


Conclusion: good if you need simple and reliable file send (upload). Often it is better than e-mail methods.




No additional points, except common items listed above in the "Web-trackers methods" section. Please read through descriptions of each bug tracker. There are also setup manuals available. You can read through manual to get idea of bug tracker's capabilities and working process.


See also:


Conclusion: best if you need a complete bug tracking solution. For simple file sending HTTP or FTP is preferable.



(*) That's because, if you have two e-mail client installed (say, Windows Mail and Outlook) - both will definitely support mailto protocol, but only one can support simple MAPI, so you may launch non-default e-mail client (which is not configured). For example, if you have Outlook 2010 as your default e-mail client and you use simple MAPI - it will launch Windows Mail client, because Outlook 2010 doesn't support simple MAPI. The same example holds true for MAPI, if you use Windows Mail as your default e-mail client (because Windows Mail doesn't support MAPI).



Recommended order of send methods

We recommend the following order:

1. The method of your choice (like HTTP or Web-tracker)
2. SMTP Server or SMTP Client (depending on whenever can you store your account details in application or not)
3. MAPI or Simple MAPI or both
4. Shell (mailto)


If you don't want (or can't) use some method in this list - just exclude it and place the rest in this order.


For example, if you want a reliable "mail only" delivery - use this:

1. SMTP Client
2. MAPI or Simple MAPI or both
3. Shell


If you can't afford storing password - use this:

1. SMTP Server
2. MAPI or Simple MAPI or both
3. Shell

(however, this has greater chances to fail sending)


This is just recommendation, not final rule. For example, you may use this sequence:

1. Mantis

2. Shell


It's your choice, it's up to you.


Note: usually there is no big reason to enable both SMTP client and SMTP server modes. Use either first or second, but not both. I.e. if you can afford storing the password from your real e-mail account in application - use SMTP client. Otherwise use SMTP server.



See also:

Send feedback... Build date: 2023-09-11
Last edited: 2023-03-07
The documentation team uses the feedback submitted to improve the EurekaLog documentation. We do not use your e-mail address for any other purpose. We will remove your e-mail address from our system after the issue you are reporting has been resolved. While we are working to resolve this issue, we may send you an e-mail message to request more information about your feedback. After the issues have been addressed, we may send you an email message to let you know that your feedback has been addressed.

Permanent link to this article: