0000239: Use real MTA which doesn't fail on greylisting - CAcert Bug Tracker

ID	Project	Category	View Status	Date Submitted	Last Update

0000239	Main CAcert Website	account administration	public	2006-05-18 05:56	2013-01-14 08:41

Reporter	tomek	Assigned To
Priority	normal	Severity	feature	Reproducibility	always
Status	closed	Resolution	won't fix
Fixed in Version	2006

Summary	0000239: Use real MTA which doesn't fail on greylisting
Description	I 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 http://wiki.cacert.org/wiki/FAQ/Registration . 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.
Tags	No tags attached.

Reviewed by
Test Instructions

duane 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.

~~bluec~~ 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 ...

tomek 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!

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