View Issue Details
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 | |||||
|
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. |
|
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 ... |
|
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 |
|
Note Added: 0000231 | |
2006-05-19 03:34 |
|
Assigned To | => bluec |
2006-05-19 03:34 |
|
Severity | minor => feature |
2006-05-19 03:34 |
|
Status | closed => needs work |
2006-05-19 03:34 |
|
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 |