| [X] Options should always be done through an options class, and no longer |
| through arrays like is shown in trunk/Mail/docs/tutorial/tutorial_smtp_auth.php. |
| See: http://ez.no/ezcomponents/contributing/coding_standards#id45 |
| As in this case there are options before, the functionality should stay, |
| but the array() way of passing objects should not be documented. |
| |
| - The IMAP, POP3 and SMTP transports and the ezcMailParser class can receive |
| options objects in the constructor. They can still receive options as arrays |
| to keep compatibility. |
| |
| - TS: Actually we should not even document anymore, that an array also |
| works as options. Just the option class itself should be documented so |
| no new users start with the deprecated way of handling options. The |
| default value for $options in ctors should also be null, not array() |
| then. |
| |
| [X] The same in ezcMailImapSet but as that did not have options before, the |
| array way should not be supported at all. |
| |
| - To keep consistency in the whole package array options were used. |
| |
| [X] The "James Bond" header looks broken to me in the tutorial. |
| |
| - Fixed. |
| |
| [ ] Shouldn't the charset for headers default to "Utf-8" instead of "us-ascii"? |
| I am not sure what we do in other cases, it of course has to be consistent. |
| |
| - TS: I think we should default to UTF-8 everywhere we need to define a |
| default charset. |
| |
| [ ] Isn't the "$charset = $this->getHeaderCharset" to |
| "$value = substr( $value, 7 ); // "dummy: " + 1" bit copied from somewhere? |
| If so, we should make this a new (private) method somewhere. |
| |
| [X] In ezcMailImapTransport, why did you change many properties to protected |
| (from private)? |
| |
| - I think it makes more sense to have protected properties, and also makes |
| it easier to test. |
| |
| [X] I see some strange things with ezcMailTransportMta vs ezcMailMtaTransport |
| in the trunk/Mail/src/transports/mta/mta_transport.php file... are you |
| sure you didn't swap something? Or was it fucked up before? :) |
| |
| - ezcMailTransportMta is a wrong name so it is deprecated in transport_mta.php |
| ezcMailMtaTransport is correct and it is in mta_transport.php |
| |
| [X] The same thing seems to be going on with ezcMailTransportSmtp vs |
| ezcMailSmtpTransport. |
| |
| - The same thing above. |
| |
| [ ] In ezcMailTools::validateEmailAddressMx() we are using smtp.ez.no in the |
| HELO command. This will be incorrect for most of the use cases, since HELO |
| should identify the server that is opening the communication. We should |
| either rely on $_SERVER['SERVER_NAME'] or let the user supply the domain |
| to use in HELO. Same applies for the sender email address. This should |
| either be "postmaster@{$_SERVER['SERVER_NAME']}" or also configurable. |
| |
| [ ] On my system several failures and warnings occur. I guess this is mostly |
| because test cases don't get skipped that are only working inside the eZ |
| network, but some seem to have real problems. For details, please check |
| http://home.schlitt.info:8080/buildresults/Mail. |