View Issue Details

IDProjectCategoryView StatusLast Update
0000239Main CAcert Websiteaccount administrationpublic2013-01-14 08:41
Reportertomek Assigned To 
Status closedResolutionwon't fix 
Fixed in Version2006 
Summary0000239: Use real MTA which doesn't fail on greylisting
DescriptionI strongly suggest CAcert uses for sending "ping" messages some real mail transfer agent which copes well with greylisting. The problem is known and it's even described in .

Any service which sends mail should be able to enqueue mail messages which - due to various reasons - cannot be delivered in the first try (a temporary error). It's even required by RFC. Greylisting is a very good antispam measure (and RFC compliant!) so mail servers using it can't be blamed for that. Requiring them to whitelist CAcert servers is plainly not realistic.

A substantial number of people who I assured have not registered themselves successfully because they have never received the "ping" messages necessary to verify their registration.

This not only decreases a number of CAcert users but also creates a bad image of CAcert as they filled the CAPs with their personal details and then they can have a feeling that all this was pointless and worry about their data which they wrote for who-knows-for-what.
TagsNo tags attached.
Reviewed by
Test Instructions


related to 0000667 closedegal E-Mail verify does not work if recipient's server requres TLS 



2006-05-19 02:57

developer   ~0000230

The web form isn't meant to be a real MTA, it was designed to give immediate feedback if a message would be accepted or not.

More often then not people were entering email addresses that were misconfigured etc, as a result the system was change from blindly sending out emails, to pre-checking and reporting to the user.

To by-pass greylisting the user only needs to wait the timeout period before re-trying or continuing.

This is not a bug, and will not be altered.


2006-05-19 03:34

manager   ~0000231

An easy solution would be to provide the communication protocol between the script and the MTA. This would at least identify the reason for the rejection ... Some greylisting software already provides an URL that may explain the case to the user.

Simply saying "that's not our problem" is easy but not all users are system administrators and understand/know about the greylisting of their MTA.

Let me keep it as an open feature request ...


2006-05-20 21:12

reporter   ~0000232

Thank you, Bluec, for re-opening the bug.

Duane, I'm afraid your advice "To by-pass greylisting the user only needs to wait the timeout period before re-trying or continuing" won't help. The reasons:

1) The timeout after the user can re-register is 48 h. I don't think that servers using greylisting keeps their temporary entries so long. Which means that another "ping message" to the given user after more than 48 h will be treated by the server as a new message so it will be temporarily rejected as well. Hence, we are in the starting point again.

2) Many (most?) users won't re-register. They just think "it doesn't work", period. Few users are determined enough to dig the Wiki pages in search for the solution. Besides, convincing big ISPs by a few users to whitelist CAcert won't work.

No matter whether you consider it a bug or not, the result is that some users won't succeed in registering, decreasing our community and creating a bad "public relations".

Please note that a MTA can be configured perfectly secure for our purpose, listening only to localhost (if the script is on the same machine), or whatever. No sophisticated configuration required, just simple, standard retrying to deliver messages. No additional feedback for users, no additional action from users (we are not talking about any challenge-response solution), users need not be informed about the server response, URL, nothing. The "ping message" will be delivered simply after a couple of tens of minutes. That's all.

Thank you in advance!

Issue History

Date Modified Username Field Change
2006-05-18 05:56 tomek New Issue
2006-05-19 02:57 duane Status new => closed
2006-05-19 02:57 duane Note Added: 0000230
2006-05-19 02:57 duane Resolution open => won't fix
2006-05-19 03:34 bluec Note Added: 0000231
2006-05-19 03:34 bluec Assigned To => bluec
2006-05-19 03:34 bluec Severity minor => feature
2006-05-19 03:34 bluec Status closed => needs work
2006-05-19 03:34 bluec Resolution won't fix => open
2006-05-20 21:12 tomek Note Added: 0000232
2006-05-20 23:25 duane Status needs work => closed
2006-05-20 23:25 duane Resolution open => won't fix
2009-04-21 12:08 ph3 Relationship added related to 0000667
2013-01-14 08:41 Werner Dworak Assigned To bluec =>
2013-01-14 08:41 Werner Dworak Fixed in Version => 2006