zem_contact_reborn 4.0.3.20

Gocom · 2012-12-07 20:07:36

ruud wrote:

2. header values aren’t encoded using encode_mailheader()

Which is pretty much intended. Encoding the whole value will limit what the header can contain. I can add that, but well…

3. And no check is done on the validity of the field names, although arguably, whoever calls this function should check that.

Headers can be anything. I for do not want to limit the headers in a way or other. It would same type of nonsense as PHP validating what can be passed to header() (what it actually does but thankfully it’s deprecated as of 5.3).

To_name, From_name and Reply_name are optional parameters, in the function call they are at the beginning of the parameter list instead of at the end. If you look at the PHP mail function, i’d order them like this:

I would really want to keep the related arguments bundled together. If there ever is going to be new arguments added to the function, the positions won’t make much sense.

The arguments in PHP accept any possible combinations allowed, but send_email() requires just addresses. As such having the arguments together makes sense, right? The code reads well and you clearly know which name is which.

5. I’ve seen Spamassassing treat this as spam because it really likes the “to” address in “< >” in all cases

Good to know. Will add.

6. In the code above, the strip_rn isn’t applied to to_address. Same applies to reply-to and from.

The addresses are filtered, which makes it unnecessary. If the filterer allows control characters, then there is a bug.

Allow a different “x-mailer” header by doing this only if it isn’t supplied in the headers

Textpattern is the application that is doing the sending tho.

9. Can we finally drop the ISO-8859-1 support? TXP does UTF-8 every else. If there were mail clients that didn’t support UTF-8 when TXP was released, surely no-one is using them now anymore. The whole utf_decode stuff is really an ugly hack. Is there anyone who really needs this, raise your hand!

Agreed, it’s nasty. Not really a hack, but doesn’t work correctly. Basically destroys the content.

You might think that time has changed, but the webmail clients we use to this day are the same and as bad and limited. We here at work send some thousand emails each month to customers and few percent of those that receive those messages, don’t see those emails properly for reason or other.

But even then, I do agree that the conversion should probably be dropped. And the normal emails Textpattern itself sends will work regardless, being mainly ASCII only, and for more exotic languages, the conversion has never been usable.

Is_valid_email() is not future proof. It limits the TLD to 6 characters. PHP has some built in support for this now.

is_valid_email() and neither PHP’s filter do exactly proper validation. Both flag valid email addresses unfortunately, being simple regex implementations. Replacing the regex with PHP’s filterer is planned, even that it doesn’t make it future or full proof, but works certainly bit better.

I hadn’t actually thought about that one. ZCR strips NULL bytes in both header and body.

NULL bytes nor any other control bytes shouldn’t matter, even that some of the 1024671 PHP classes seem to do that. Nothing else than LF and CR should have relevance in email headers. Plus, Textpattern’s HTTP stack removes NULL bytes already from there at least.

11. If people want to use the phpmailer add-on, then it’s perhaps easier to pass on unprocessed parameters.

The callback functions receive both encoded and raw values. The $arguments contains the initial arguments supplied to send_email() as mentioned in the above example I posted.

Last edited by Gocom (2012-12-07 20:23:59)

ruud · 2012-12-07 21:06:03

Gocom wrote:

Encoding the whole value will limit what the header can contain. I can add that, but well…

~~True. Hadn’t thought of that. No problem if it’s not encoded, as long as that’s documented.~~

Headers can be anything. I for do not want to limit the headers in a way or other. It would same type of nonsense as PHP validating what can be passed to header() (what it actually does but thankfully it’s deprecated as of 5.3).

Field names, not values. There are restrictions on field names (printable us-ascii, no spaces or colons). Not important enough to check probably, because these typically aren’t supplied by whoever visits the website.

I would really want to keep the related arguments bundled together. If there ever is going to be new arguments added to the function, the positions won’t make much sense.

The arguments in PHP accept any possible combinations allowed, but send_email() requires just addresses. As such having the arguments together makes sense, right? The code reads well and you clearly know which name is which.

How about having a list of arguments, to call send_mail with an array of parameters, much like how tag handlers work. Easier to extend in the future. (if only PHP supported named parameters).

Textpattern is the application that is doing the sending tho.

Makes sense. Otherwise, I can always switch to using an X-plugin header :)

NULL bytes nor any other control bytes shouldn’t matter, even that some of the 1024671 PHP classes seem to do that. Nothing else than LF and CR should have relevance in email headers.

Actually, they’re not allowed anymore since RFC 2822:
“The NUL character (ASCII value 0) was once allowed, but is no longer for compatibility reasons”
Various security software will reject mails that contain NUL characters (for example: Symantec mail security)

Plus, Textpattern’s HTTP stack removes NULL bytes already from there at least.

Where does that happen? I grepped for x00. Didn’t find it.

The callback functions receive both encoded and raw values. The $arguments contains the initial arguments supplied to send_email() as mentioned in the above example I posted.

Aaah… I missed the part where $arguments was defined. Good.

Last edited by ruud (2012-12-09 14:24:06)

Gocom · 2012-12-07 21:20:59

ruud wrote:

Where does that happen? I grepped for x00. Didn’t find it.

PHP has “\0” for NULL too. Textpattern runs POST and GET parameters through its own deNull().

How about having a list of arguments, to call send_mail with an array of parameters, much like how tag handlers work. Easier to extend in the future. (if only PHP supported named parameters).

I would rather write a class at that point and use objects. I personally don’t like that array stuff that much to be honest. Makes writing documentation hard and restricted too.

Not important enough to check probably, because these typically aren’t supplied by whoever visits the website.

That’s what I was after.

Actually, they’re not allowed anymore since RFC 2822:

Good to know. Will add the filtering to strip_rn().

ruud · 2012-12-09 14:20:31

Gocom wrote:

ruud wrote:: header values aren’t encoded using encode_mailheader()

Which is pretty much intended. Encoding the whole value will limit what the header can contain. I can add that, but well…

Two arguments for encoding the $header values in send_mail:

1. I would expect the callback event to do it’s own escaping. I know class.phpmailer does. So you need the unencoded header values there.
2. TXP does encoding / escaping as late as possible in most other places.

The only two additional headers I can think of that might be limited – if you encode them completely – are CC and BCC. Perhaps these could be added as function arguments.

I hope To/From/Reply-To/CC/BCC names/addresses can be supplied as array(‘address’ => ‘name’, address2’ => ‘name’). That makes it easy to supply multiple addresses for one header. This is something that can be done now, because it’s a new function, but would be harder to implement once 4.6 is released. Even though this adds CC/BCC, it would reduce the number of arguments:

send_email($from, $to, $subject, $body, $reply = array(), $cc = array(), $bcc = array(), $headers = array())

PS. if no reply-to address is specified, mail clients will automatically reply to the address(es) in the From header. So it doesn’t have to be added.

ruud · 2012-12-11 20:42:30

Yay for r4980

If I’m reading the code correctly, the function arguments $from (and to/cc/bcc/reply-to) can now be in one of the following formats (which makes it very flexible):

'user@example.com'
array('user1@example.com', 'user2@example.com')
array('user1@example.com' => 'name1', 'user2@example.com' => 'name2')

A few small things:

if ($charset == 'UTF-8')
{
  $name = utf8_decode($name);
}

Should probably have != instead of ==.

foreach ($headers as $field => $value)
{
  if (!isset($envelope[$field]) && preg_match('/[A-z0-9-_]/i', $value))
  {
    $envelope[] = $field.': '.encode_mailheader(strip_rn($value), 'phrase');
  }
}

I can’t figure out the purpose of the preg_match there, but A-z should probably be A-Z or a-z.
If it was to ensure a valid header field name, RFC2822 3.6.8 says: /^[\041-\071\073-\176]+$/ (printable US-ASCII characters except SP and colon)
If it was to avoid an adding a header without a value, I’d simply check if the value is a non-empty string.

The values in those headers can contain utf-8 as well, so may need utf-8 decode if charset != UTF8.

Gocom · 2012-12-12 00:16:30

The regular expression, just like character set conversion were overlooked. Were there for no reason, basically leftovers.

I was supposed to replace the placeholder regular expression with a header field validation, but I suppose I never did.

I’ve now fixed those, so, thank you.

ruud wrote:

If I’m reading the code correctly, the function arguments $from (and to/cc/bcc/reply-to) can now be in one of the following formats (which makes it very flexible):

That would be correct.

hilaryaq · 2013-01-07 15:38:25

Hi All, I’ve edited zem contact reborn to be HTML5 valid, and include two new HTML5 tags of placeholder and autofocus on any field like ‘placeholder=“Please enter your name”’, anyone interested in the edited code? And if so where do I put it, can put the code to copy and paste from my own site if that’s handiest??

jstubbs · 2013-01-08 06:34:54

@hiliaryaq – sounds perfect, I’d like to use your updated plugin, but hopefully Ruud will add it to the new version of ZCR whenever that is?

For adding a jquery date picker to a ZCR input I need an #id to get the calendar attached to the field. Is there a way to add an #id to a text field – can’t see it at the moment.

Last edited by jstubbs (2013-01-08 06:35:45)

uli · 2013-01-08 14:06:42

jstubbs wrote:

Is there a way to add an #id to a text field – can’t see it at the moment.

Whatever you put into the name attributes is used as the ID.

tye · 2013-01-08 22:00:11

@hilaryaq I would like a look at your plugin please…. I’m not sure what you would do with it, probably ask ruud :)

jstubbs · 2013-01-09 01:09:16

uli wrote:

Whatever you put into the name attributes is used as the ID.

Thanks Uli! Worked a treat. I didn’t know about the name attribute being used as the id.

jfp · 2013-01-11 15:48:54

For years I used zem_contact_reborn with success on few websites.

Suddenly one of them displaying error.

The form in question is here: http://www.zecraft.com/contact
Impossible to make it working, we have that instead:
Invalid value for “”, “[message content]” is not one of the available options.

The same form, works well here:
http://porchez.com/about/3/Contact-Jean-Francois-Porchez

<txp:zem_contact label="" subject="[contact]" form="mycontactform" from="info@website.com" to="email@website.com" />

The two websites feature same TXP, same plugin versions, same server. Unique difference is the later have theses things on a content/article when the buggy one on a presentation/page.

How to resolve this? So far no success.

{Edited to add some Textile for better code display. – Uli}

Last edited by uli (2013-01-11 16:20:52)

uli · 2013-01-11 16:23:46

There are some id="invalid" and name="invalid" in the form’s source code. Try to get rid of them. Have you entered something in the name attributes, special characters, apostrophes, something that’s not viable for an ID?

Last edited by uli (2013-01-11 16:24:38)

gfdesign · 2013-01-11 21:48:59

Hi, quick question
Is there any way to add an address email BCC: Blind Carbon Copy (sorry I’m not sure if it’s correct in English. Copia Oculta en Español) as receiver? I want all messages go to an hidden email too.
Thanks

uli · 2013-01-11 21:59:37

You could try whether this hack is still working.

And also this one, which, BTW, is Ruud’s reply to a question of yours ;)

Last edited by uli (2013-01-11 22:08:14)

Textpattern CMS

Textpattern CMS support forum

#1276 2012-12-07 20:07:36

Re: zem_contact_reborn 4.0.3.20

#1277 2012-12-07 21:06:03

Re: zem_contact_reborn 4.0.3.20

#1278 2012-12-07 21:20:59

Re: zem_contact_reborn 4.0.3.20

#1279 2012-12-09 14:20:31

Re: zem_contact_reborn 4.0.3.20

#1280 2012-12-11 20:42:30

Re: zem_contact_reborn 4.0.3.20

#1281 2012-12-12 00:16:30

Re: zem_contact_reborn 4.0.3.20

#1282 2013-01-07 15:38:25

Re: zem_contact_reborn 4.0.3.20

#1283 2013-01-08 06:34:54

Re: zem_contact_reborn 4.0.3.20

#1284 2013-01-08 14:06:42

Re: zem_contact_reborn 4.0.3.20

#1285 2013-01-08 22:00:11

Re: zem_contact_reborn 4.0.3.20

#1286 2013-01-09 01:09:16

Re: zem_contact_reborn 4.0.3.20

#1287 2013-01-11 15:48:54

Re: zem_contact_reborn 4.0.3.20

#1288 2013-01-11 16:23:46

Re: zem_contact_reborn 4.0.3.20

#1289 2013-01-11 21:48:59

Re: zem_contact_reborn 4.0.3.20

#1290 2013-01-11 21:59:37

Re: zem_contact_reborn 4.0.3.20

Board footer