Plug-in: zem_contact_reborn

thebombsite · 2006-02-08 01:32:48

I haven’t tried that Anton but “Reborn” now references your setting in “Preferences” if that’s any help. It should also retain any input data if an error is thrown.

As far as I am aware the only area where we are still having a problem with foreign characters is the “Select” drop-down list.

Maniqui – at the moment the plug-in only checks that it is a properly formated email address so if they are using your domain they will pass the test. I’ll have a word and see if there is anything that can be done about this. Those emails are weird. Wasn’t there any message?

-P- · 2006-02-08 14:00:50

<blockquote> > maniqui wrote:

> Hi,
i think I’m having some problems that maybe are related with this plug-in, but I really dont know.

Yesterday, I updated from 4.0.1 and plug-in dca_email_form to 4.0.3 and zem_contact (reborn), because an spammer sent SPAM maybe thru a hole in the dca_email_form. I also was receiving 10 or 20 e-mails by day, sent through my contact form, that were obviusly a kind of SPAM, because they were all sent from a non-existing email address of my own domain (like 2jlk298@mydomain.com or similar).

So, as I said, I upgraded to 4.0.3 and zem_contact reborn, hoping that those kind of e-mails will gooing to stop.

But today I have received new fake e-mails sent thru the new contact form.
You can see the emails content here (the 3 are different):
http://pastebin.com/543365
http://pastebin.com/543404
http://pastebin.com/543409

As I also said, they are always sent with a fake address of my own domain.

So, my first idea to stop this kind of abuse is: to exclude email addresses from @mydomain.com.
Is there anyway to do this?

Also, does anyone suffered this kind of attack with zem_contact?

thanks.
</blockquote>

I have had similar problems on one of my domains I host during past two days. But that site runs on Wordpress and the spam subject is from it´s contact form that obviously uses wp plugin contact form so I believe these spam attacts are not releated only to zem_contact.

Only today I have received 600 hundred mail delivery notifications with my domains fake email addresses used. I contacted my ISP to exclude all the email addresses that are not in use de facto and I assume it works (well, does not prevent those email addresses beeing used but it stops my server receiving them).

Last edited by -P- (2006-02-08 14:02:05)

thebombsite · 2006-02-08 14:46:15

I wonder if these are “bot” attacks, looking at the quantity P has received, in which case using the “checkbox” function may help. I can’t say I’ve seen any of these though it is probably a mistake to say so. ;)

Last edited by thebombsite (2006-02-08 14:47:29)

-P- · 2006-02-08 14:55:11

You read my mind :) I was just about to add checkbox to all my TXP installations with contact form. Ones running with Wordpress, guess I just have to disable the contact forms for a moment.

I assume this is some kind of new security hole or something that bots have found, ability to some how use Textpattern or Wordpress contact forms to send spam.

Those emails that I personally received were not the actual spam but mail delivery failure notices. The poor person whose blog contact form was used, received actual spam.

tinyfly · 2006-02-08 15:08:17

You know it would be great if zem_contact_submit could use html’s <button> element instead of the <input> element, or have that option.

Some thing like <txp:zem_contact_submit label="Send" button="yes" /> would output <button type="submit" name="zem_contact_submit">Send</button>.

thebombsite · 2006-02-08 15:09:45

Bots are getting more clever by the minute. I take it the WP plug-in doesn’t have a similar function then. Maybe it’s time to wake the developer up. ;)

We are currently looking at adding a couple of empty “hidden” fields. When the form is sent it will only be accepted if the fields remain empty. If some really clever bot has filled them in… and combine that with a checkbox as well… maybe it will blow itself up.

@tinyfly – explain to me what the difference is please.

Last edited by thebombsite (2006-02-08 15:12:24)

tinyfly · 2006-02-08 15:24:41

The only difference would be in targeting the element via css. If it is an <input> and you wanted to style your submit input differently than your text inputs then you have to use a class or id. If it is a <button> element then no class or id is neccessary. The current way works fine since you do have ids but it would be nice to have the option. Just good practice in general.

Also, could you add a class to any hidden inputs you add? like class="zemHidden" that way when I make inputs display:block; I can exclude the hiddens?

Last edited by tinyfly (2006-02-08 15:26:20)

tinyfly · 2006-02-08 16:19:20

I am having a problem with show_input.

Here is the code I am using:
<txp:zem_contact to="myemail.com” form=“contact_form” show_input=“no” />@
<txp:zem_contact to="myemail.com” form=“contact_form” show_error=“no” />@

Everything seems fine except that but when I submit the form with no email the error message shows in the top area but so does a 2nd contact form.

Anybody else run into this?

tranquillo · 2006-02-08 16:44:06

The problem arises because of the show_error attribute. It doesn’t work properly, yet. We didn’t wanted to change that before the select email function is implemented, because it could need some major change in the code structure.

thebombsite · 2006-02-08 18:40:47

See how we think about you all. ;) Actually that bit is too complicated for me but your button, on the other hand, isn’t. I’ll have a look. So what we could end up with then is an attribute – button=“yes” – default is “no” – and if set to “yes” you get a button instead of an input. That sound about right?

I don’t think this will affect anything else will it tranquillo?

And I always keep a beady eye on ids and classes so rest assured that any added fields will conform.

Whilst we are on the subject in general I’ve noticed that the “for” attribute that is output in “labels” causes a problem, but only for the “select label”, when the DTD is set to “XHTML 1.0 Strict” and probably “XHTML 1.1” as well, though I haven’t tried that. I have the impression that, in plain English rather than jargon, the label doesn’t know what it is a label for. Anyway I was wondering exactly what purpose the “for” attribute served. Would it cause some problem if it were removed from the “select label” output permanently?

tinyfly · 2006-02-08 19:51:14

The button thing sounds great.

With regards to the label: “for” is used to associate the “label” with the form control. The “for” should match the “id” of the form control.

Where the problem is in the current plugin is that there is no “id” being put onto the “select” tag. If the “select” had an “id” that matched its “label’s” “for” value then you wouldn’t see any problems. This is valid for all versions of xhtml (strict and 1.1).

Please do not remove it. That would be introducing accessibility errors, as it is now it needs to be fixed by adding the “id” to the “select” tag.

thebombsite · 2006-02-08 20:15:26

Ah. There you go then. A case of working from the other direction. So that’s on the list of things to do.

As for the button. I’ve just added the code in and got myself a lovely button which even highlights itself when hovered over, but the damn thing doesn’t work! Oh woe is me say I. So I shall have to do some checking. Just for your information I did create a button element as opposed to an “input type=button” which would require some added javascript mumbo-jumbo to do the “submit” bit. No luck with it though. The attribute worked so button=“yes” gave you a button instead of an input. It’s the button itself which appears to have the problem.

So you will have to live with the input for a while longer tinyfly and be thankful I like ids and classes. ;)

I shall learn all this stuff one day. Watch this space. :)

Last edited by thebombsite (2006-02-08 20:18:59)

tinyfly · 2006-02-08 20:21:48

Make sure “button” has ‘type=“submit” as an attribute and check to see if the hidden zem_contact_nonce input is still being created with the change.

thebombsite · 2006-02-08 20:30:18

Yes , type=“submit” I had in there. In fact the tag was much as it is now except that <submit> is a wraptag so I removed “value=$label” and placed $label between the tags. I shall look at the code around zem_contact_nonce. Thanks for the pointer.

alannie · 2006-02-09 00:34:04

First let me say, what a great plugin! Thanks to all who contributed. Now, I’ve got it almost completely set up except for one thing that’s got me stumped. I can’t seem to get any kind of “thanks” page to show up. When I fill out the form and hit the submit button, an email does get sent, but the form itself just reloads with no confirmation message of any kind. I’ve set up the <code>thanks_form</code> attribute for the <code><txp:zem_contact> </code> tag and triple-checked to make sure it’s pointing to the correct form (and that the form itself exists!).

I’m sure I’m overlooking something obvious, but any ideas??

Textpattern CMS

Textpattern CMS support forum

#196 2006-02-08 01:32:48

Re: Plug-in: zem_contact_reborn

#197 2006-02-08 14:00:50

Re: Plug-in: zem_contact_reborn

#198 2006-02-08 14:46:15

Re: Plug-in: zem_contact_reborn

#199 2006-02-08 14:55:11

Re: Plug-in: zem_contact_reborn

#200 2006-02-08 15:08:17

Re: Plug-in: zem_contact_reborn

#201 2006-02-08 15:09:45

Re: Plug-in: zem_contact_reborn

#202 2006-02-08 15:24:41

Re: Plug-in: zem_contact_reborn

#203 2006-02-08 16:19:20

Re: Plug-in: zem_contact_reborn

#204 2006-02-08 16:44:06

Re: Plug-in: zem_contact_reborn

#205 2006-02-08 18:40:47

Re: Plug-in: zem_contact_reborn

#206 2006-02-08 19:51:14

Re: Plug-in: zem_contact_reborn

#207 2006-02-08 20:15:26

Re: Plug-in: zem_contact_reborn

#208 2006-02-08 20:21:48

Re: Plug-in: zem_contact_reborn

#209 2006-02-08 20:30:18

Re: Plug-in: zem_contact_reborn

#210 2006-02-09 00:34:04

Re: Plug-in: zem_contact_reborn

Board footer