mailform checking correct email input

[cmb]

So we might consider to apply the ToASCII conversion to the IDN before sending the mail.

This seems to be not as easy as expected. PHP offers the helpful function idn_to_ascii() only since PHP 5.3. This function is available as part of the intl and the idn packages too, but I'm in doubt, if these extensions are widely available. I found a class that can do the conversion in both ways, but it's 95 k uncompressed and works only with PHP 5.

As I'm not sure, if we need to implement the conversion, it's probably best to postpone the decision if and how we do it to XH 1.6.

[svasti]

We improved the mailform a little bit, I think that's already something for 1.5.4. We have to leave something for the next improvement

[cmb]

Hello Community,

regarding the IDN ToAscii conversion: I'm still not sure, what to do. In my latest post in this thread I mentioned two possibilities to do the conversion, but both need PHP 5 resp. PHP 5.2/5.3. A further search brought me to another library, which is much smaller than the one mentioned above. I don't know why! But anyway this library requires at least PHP 5 too. As it has only 217 lines, it might be possible to rewrite it for PHP 4, but I'm neither sure, if that's possible nor if that's worth the trouble.

As IDN is a relatively new feature, we might not be able to find a ready to use PHP 4 library to do the conversion. Unfortunately the ToAscii algorithm seems very complex (see RFC 3490) so it seems overkill to implement it ourselves.

I suggest that we reconsider adding the ToAscii conversion or at least restricting it's use to PHP 5 driven installations.

Christoph

[manu]

Just a practial question: According to my knowledge domain names with umlauts could be established and are accessible. But email addresses with umlauts in the domain names were usually rejected. Is it possible in the meantime to use email addresses with these umlauts in the domain name?
regards
manu

[cmb]

RFC 6531, which allows this, is currently a "Proposed Standard", so I assume it's currently not possible to send emails to IDN domains directly. But isn't is possible to use the ASCII form of the domain to send these emails? E.g. instead of sending a mail to christoph@bäcker.example, which is likely to fail, the mail could be sent to christoph@xn--bcker-gra.example---I assume this should be possible (if not, we could close the discussion about the ToAscii conversion).

I have a client with the domain "sachverständiger-bestattungswesen.de", any email of this domain wouldn't be accepted.

svasti might have more information about this issue.

[manu]

the mail could be sent to christoph@xn--bcker-gra.example--

you mean, this conversion could be done automatically. If you have an idea how this can be done easily, then it's a good idea for now or the future.
regards
manu

[cmb]

Hi manu,

I have mixed up two issues:

1. the restriction that email header fields may contain ASCII characters only (RFC 5322 section 2.2)
2. the sending of mails to email addresses with non ASCII characters

(1) can easily be solved by using encoded-words for the "From" header field. This should have been done in parallel with simplifying the regexp for checking the sender's email address, but it wasn't. So I suggest we do it for XH 1.5.6.

(2) is much harder to accomplish, as it involves the ToAscii algorithm already mentionend in this thread. But as this concerns the webmaster's email address only, that might not be a real problem, if it will be documented, that $cf['mailform']['email'] does accept "classic" email addresses only.

Christoph

[cmb]

Hello Community,

Ludwig has confirmed, that sending a mail from CMSimple's built-in mailform with a IDN mail address fails: http://cmsimpleforum.com/viewtopic.php?f=16&t=6020&p=34923#p34922. As the reliable working of the mailform may well be regarded as crucial, we have to fix this ASAP.

(1) can easily be solved by using encoded-words for the "From" header field.

That doesn't work!

I suggest we disallow any "problem" characters in the sender's mail address and emit an appropriate error message, if such characters are found, for XH 1.5.7. Perhaps we may even consider to switch back to the former regex--at least it's better to reject sending the mail in a controlled way by CMSimple, as to rely on the mail transport chain to cater for non standard email headers.

Tackling the ToAscii conversion might better be postponed to XH 1.6, due to the given complexity.

Christoph

[cmb]

I suggest we disallow any "problem" characters in the sender's mail address and emit an appropriate error message, if such characters are found, for XH 1.5.7.

I have implemented an additional check for non ASCII characters, and I have changed the error message from "Please fill in the required fields" to "This email address is not allowed" (the latter seems to be more descriptive ).