I have a powermail form. I get the following error when I submit the form:
Spam recognized: uid11 This field must be filled!
Spam recognized: uid12 This field must be filled!
Spam recognized: uid14 This field must be filled!
Spam recognized: uid13 This field must be filled!
The fields uid11 ... uid14 do exist in the form - and they are transmitted to the server. For example (from Chrome network tab):
Testvalue
------WebKitFormBoundaryIIcUvgTthzftQYb6
Content-Disposition: form-data; name="tx_powermail_pi1[field][uid12]"
The 4 fields which are claimed are mandatory (required) but have no other rules added.
I have already tried to disable the spam check, but without any success:
plugin.tx_powermail.settings.setup.spamshield._enable = 0
Hat the same problem a couple of weeks ago, Disabled the spamshield helped. Later I just disabled badword filter. seems to work for me (check if spamshield is rly disabled in TypoScript Object Browser)
I found out that in table tx_powermail_domain_model_field the field for "marker"was empty. I have no idea why I have to add a marker variable, but since I added variable names (like "e_mail", "firstname", etc.) the form works.
Related
I'm building a LotusScript agent looping through a set of documents then - based on a given condition - create mail messages with formatted html text. The recipients will be mostly Non-Notes users (Outlook etc) that's why I want to make sure that subject and message body are formatted correctly. At least one copy is sent to a Domino mail-in database, though.
The code basically creates a MimeEntity, sets "To", "CC" and "Subject" headers then puts a pre-configured message into the mail body and sends it off.
In regards to the body I experimented both with a simple MimeEntity formatted as "text/html" as well as with a multipart message (Content-Type = "multipart/alternative") with 2 child entities (1: "text/plain" without any formatting, 2: "text/html" i.e. html-formatted); in my final code I plan to go for the latter method.
What is really weird is that the recipients (using Outlook as well as other mail clients like Thunderbird) see 3 "To:" and 3 "Cc:" items instead of just one. Looking at the doc in the receiving Domino mail-in database there is only one instance of each item (i.e. SendTo and CopyTo).
Here's the message's source code (taken from Thunderbird) showing those 3 instances of each item:
Return-Path: <sendername#myorg.de>
Received: (removed info here)
Subject: =?UTF-8?B?RWluIGdlbcO8dGxpY2hlcyBzaW1wbGVzIFRlc3RtYWlsIGF1cyBTT1A=?=
MIME-Version: 1.0
Auto-Submitted: auto-generated
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
To: user1#orgext1.de, user2#orgext2.de
CC: my-mail-in-db#myorg.de
Message-ID: <OFBCA50979.C1582837-ONC125856E.00548385-C125856E.0054838A#MYORG.DE>
From: Lothar Mueller <sendername#myorg.de>
This the basic code creating these mails (the simple non-multipart version):
Set docMemo = db.Createdocument()
Call docMemo.Replaceitemvalue("Form", "Memo")
Set nMimeBody = docMemo.Createmimeentity()
'SendTo
Set nMimeHead = nMimeBody.Createheader("To")
Call nMimeHead.Setheaderval("user1#otherorg.de,user2#3rdorg.de")
'CopyTo
Set nMimeHead = nMimeBody.Createheader("CC")
Call nMimeHead.Setheaderval("my-mail-in-db")
'Subject
Set nMimeHead = nMimeBody.Createheader("Subject")
Call nMimeHead.Addvaltext("Subject with ä-ö-ü-ß", "UTF-8")
'html version only for simple non-multipart MIME
Call nStream.Writetext({<p style="font-weight:bold;">Some simple formatted HTML content</p>})
Call nMimeBody.Setcontentfromtext(nStream, {text/html; charset="UTF-8"}, ENC_NONE)
Call nStream.Close()
'finally send
Call docMemo.Send(False)
Now, I can work around this behavior by simply setting the recipients as plain old Notes items, like:
Call docMemo.SendTo = recipientArray
Call docMemo.CopyTo = copyArray
instead of setting those values as MIME headers. In this case there are no more multiple instances of "To" and "CC" items at the recipients' mail clients.
I know that I did this already some years ago in a different project, and back then I didn't have those problems.
Anyone having an idea what could be the cause for this? Could it be due to the Domino version in use (now it's 10.0.1 FP4, back then it was some 9.0.1 version)?
Guess I found the cause for this, at least partially:
As I mentioned in an update to my post this behavior only can be observed when the agent is running in the client as opposed to running on the server:
examining the resulting mail through Ytria's scanEZ I find that there's a difference in regards to the fields that are created:
the run-on-server version just creates the expected fields "To:" and "Cc:" which turn up as "SendTo" and "CopyTo" in the resulting Notes document
If the code is running in the client some more fields are created in the Notes document: in addition to the standard fields there are also "INetSendTo", INetCopyTo, "AltSendTo" and "AltCopyTo". I assume that those extra fields are then rendered by the router to become addition "To:" and "Cc:" header items.
Thanks again to #DaveDelay for bringing up that idea regarding the router and mail.box
Working on a customised email template in CQ5, I have created in following text file under etc/notification. The workflow is triggered when a form is filled in by the user.
From: Order Brochure <order.brochures#gmail.com>
To: ${payload.email}
CC:
Subject: Order Brochures Confirmation ${payload.BrochureID}
Dear ${payload.Name},
Thank you for your Brochure Order, your reference is ${payload.orderBrochureID}.
Your email address is {$payload.email}.
Everything in this template works fine, except for the "To: ${payload.email}". Even the "Your email address is {$payload.email}" part displays the user inputted email fine. It also works if I input a static email address in "To:".
What am I doing wrong here? Below is the error in logs
Process execution resulted in an error:
javax.mail.internet.AddressException: Illegal address in string ``''
com.day.cq.workflow.WorkflowException: javax.mail.internet.AddressException: Illegal
address in string ``''
Remove the "CC:" it's attempting to parse the email address for this header and it's a null.
When you're dealing with these types of problems when the error is occurring within a CQ library. I recommend using a custom logger to assist with the troubleshooting.
Details of logging can be found at Logging - docs.day.com
Here's an example OSGi log configuration for your issue.
This error might be cumming because you are using a string as an Internet Address.
you need to typecast ${payload.email} to Internet Address.
I have incoming email set up for SharePoint 2010, and am sending forms from InfoPath using that method, with SMTP server set up on the SharePoint Server machine. It seems easier than elevating the permissions of an anonymous user with the InfoPath code-behind option. I also tried a custom method of sending the emails but was unable to find a way to send the form data along with the email message using the InfoPath 2010 code-behind option. So, I found another way, using the advice from SharePoint UK's website.
My problem is that while removing the x-mailer header actually solved my problem regarding whole email messages, it did not allow the attached form data to be sent to the library. The message would be imported and then just disappear if I did not have the "Save original e-mail" setting enabled. Inspecting messages in the drop folder I found they had a content type of "multipart/related" and if I edited them with NotePad++ I could change that to "multipart/mixed" and the attached form data would then be imported as desired.
So I went about trying to modify the VB Script to make this happen BUT now nothing happens with the script at all. Clearly I'm doing something wrong with it and VBScript really isn't my area of expertise. Maybe it's just not possible to edit those fields or maybe I need to attack it from a different angle. How can I get my VBScript to edit the content type for these emails?
CODE:
Set shell = CreateObject("WScript.Shell")
shell.LogEvent 4, "starting mail filter"
if instr(iMsg.Fields("urn:schemas:mailheader:content-type"), "related") > 1 then
Dim logMsg = "Mail Type: " & iMsg.Fields("urn:schemas:mailheader:content-type")
Dim tempType = Replace(iMsg.Fields("urn:schemas:mailheader:content-type"), "related", "mixed")
shell.LogEvent 4, iMsg.Fields("urn:schemas:mailheader:content-type")
iMsg.Fields.Delete("urn:schemas:mailheader:content-type")
iMsg.Fields.Item("urn:schemas:mailheader:content-type") = tempType
iMsg.Fields.Update
shell.LogEvent 4, iMsg.Fields("urn:schemas:mailheader:content-type")
end if
shell.LogEvent 4, "end mail filter"
iMsg.DataSource.Save
EventStatus = 0
I looked into this in greater detail and found that the content-type property of an email message is one of the many that is read-only using this particular vbscript library. So, I would have to find some other way of editing the file, and the work involved is more than what it would take to find an alternate solution that skipped email altogether. Therefore, I am abandoning the plan of using email in this case. If you take something away from this, let it be that there are read-only properties for the mail message object in this script.
I'm not a programmer, but I'm trying to expand an opensource Ajax contact form to include extra fields.
There are two files; index.php and send.php.
send.php contains simple form validation, and it includes a test to ensure the 'phone' field is non-empty. This test fails no matter what value is entered for Phone Number.
Why is this?
I am not an expert in PHP but you called all of your other parameters like this
$_POST['param name']
and the phone parameter like this
$POST['phone']
notice the missing
_
char. Could that be it?
I am currently extending an e-mail system with an autoresponse feature. In a dark past, I've seen some awesome mail loops, and I'm now trying to avoid such a thing from happening to me.
I've looked at how other tools ('mailbot', 'vacation') are doing this, grepped my own mail archive for suspicious mail headers, but I wonder if there is something else I can add.
My process at this point:
Refuse if sender address is invalid (this should get rid of messages with <> sender)
Refuse if sender address matches one of the following:
'^root#',
'^hostmaster#',
'^postmaster#',
'^nobody#',
'^www#',
'-request#'
Refuse if one of these headers (after whitespace normalization and lowercasing) is present:
'^precedence: junk$',
'^precedence: bulk$',
'^precedence: list$',
'^list-id:',
'^content-type: multipart/report$',
'^x-autogenerated: reply$',
'^auto-submit: yes$',
'^subject: auto-response$'
Refuse if sender address was already seen by the autoresponder in the recent past.
Refuse if the sender address is my own address :)
Accept and send autoresponse, prepending Auto-response: to the subject, setting headers Precedence: bulk and Auto-Submit: yes to hopefully prevent some remote mailer from propagating the autoresponse any further.
Is there anything I'm missing?
In my research so far I've come up with these rules.
Treat inbound message as autogenerated, ignore it and blacklist the sender if...
Return-Path header is <> or missing/invalid
Auto-Submitted header is present with any value other than "no"
X-Auto-Response-Suppress header is present
In-Reply-To header is missing
Note: If I'm reading RFC3834 correctly, your own programs SHOULD set this, but so far it seems some autoresponders omit this (freshdesk.com)
When sending outbound messages, be sure to...
Set the Auto-Submitted: auto-generated header (or auto-replied as appropriate)
Set your SMTP MAIL FROM: command with the null address <>
Note some delivery services including Amazon SES will set their own value here, so this may not be feasible
Check the recipient against the blacklist built up by the inbound side and abort sending to known autoresponders
Consider sending not more than 1 message per unit time (long like 24 hours) to a given recipient
Notes on other answers and points
I think ignoring Precedence: list messages will cause false positives, at least for my app's configuration
I believe the OP's "auto-submit" rule is a typo and the official header is Auto-Submitted
References
RFC3834
This SO question about Precedence header has several good answers
Wikipedia Email Loop Article
desk.com article
Comments welcome and I'll update this answer as this is a good question and I'd like to see an authoritative answer created.
Update 2014-05-22
To find if an inbound message is an "out-of-office" or other automatic reply, we use that procedure:
First, Find if header "In-Reply-To" is present. If not, that is an auto-reply.
Else, check if 1 of these header is present:
X-Auto-Response-Suppress (any value)
Precedence (value contains bulk, or junk or list)
X-Webmin-Autoreply (value 1)
X-Autogenerated (value Reply)
X-AutoReply (value YES)
Include a phrase like "This is an automatically-generated response" in the body somewhere. If your message body is HTML (not plain text) you can use a style to make it not visible.
Check for this phrase before responding. If it exists, odds are good it's an automated response.