I was able to add a recipient to an envelope with a recipientId that was the HASH of the recipient's email address (50a5ae9b6d8889c1fda3f140621b448b). However, I was not able to add tabs to that recipient. I was able to edit the recipient name and email address, so the system seems to be able to recognize the recipientId. It appears to be a problem with the recipientId in the URL since adding tabs is the only REST API call that uses the recipientId in the URL.
After more testing, I found that there is a limit of 32 characters to the length of the recipientId but you can still edit the recipient and assign a recipientId that is not valid (alphanumeric and/or greater than 32 characters).
I'm seeing different results, and seeing the system act as expected here. First off, if I try to add a 32 digit number for the recipientId such as
12345678901234567890123456789012
I'm able to add the recipient just fine, then subsequently modify their tabs. Next, if I try an alpha numeric string, such as (notice the z at the end)
1234567890123456789012345678901z
The system generates an error stating INVALID_RECIPIENT_ID - A recipient ID is missing or invalid. I also get this error if I try a completely numeric number that is greater than 32 digits in length.
Please re-test and confirm your results, as this appears to be functioning as designed.
Related
I'm trying to add my email address in Store Email Address, But it is saying "Invalid email address "admin#mydomain"."
Note that my tld is uncommon.
I think that is the reason for the error message.
I can add .com email address easily btw.
Is there any way to add the email?
Thank you.
in validation.js you have
['validate-email', 'Please enter a valid email address. For example johndoe#domain.com.', function (v) {
return Validation.get('IsEmpty').test(v) || /^([a-z0-9,!\#\$%&'\*\+\/=\?\^_`\{\|\}~-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z0-9,!\#\$%&'\*\+\/=\?\^_`\{\|\}~-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*#([a-z0-9-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+(\.([a-z0-9-]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF])+)*\.(([a-z]|[\u00A0-\uD7FF\uF900-\uFDCF\uFDF0-\uFFEF]){2,})$/i.test(v)
}],
You will have to play with this regular expression.
if you look into this expression you will find a . jsut remove every thing excluding ] from . till end and should solve.
I had the same issue, but your suggestions were misleading.
The error message comes up not from this java script, but app/code/core/Mage/Adminhtml/Model/System/Config/Backend/Email/Address.php
The error is generated from lib/Zend/Validate/EmailAddress.php, because it calls hostname verification from Hostname.php in the same directory.
There you can find in row nr. 117 an array called $_validTlds
there put your domain ('works' or in my case 'wien'), take care alphabetical order, and quotes and commas. save and try again,
it will work. Good luck.
There's a pub in my town whereby, if you sign up to their newsletter using their website and provide a "unique" email address, you get a free drink. On a whim, I decided to sign up a second time using myemail+one#gmail.com. It let me. I'm now sitting on a nice comfy pile of free drink vouchers.
This got me thinking about a system we have here, where the email address is considered the unique identifier. Checking the code, sure enough, if we were offering vouchers in our business, someone else would be sitting pretty.
The basic, stab-in-the-dark, fix is to check for the "+" character and ignore everything after it (up to the #), and compare using that. But I am unsure if this was the intent for the + character. Would that work?
Secondly, are there any other caveats that would allow a user to sign up multiple times with a seemingly different email address, but which actually would always end up in the same mailbox?
This question is language-agnostic.
While using a plus sign as an e-mail address alias is a known feature of gmail, other mailers do either not allow it or use a minus sign instead. '+' is a legitimate character to be used as part of an email address according to the RFC.
The use of '.' is also a gray area. john.doe#gmail.com and johndoe#gmail.com send also both to the same email address and look different.
In order to validate the uniqueness of an email address you will have to prepare a rule base for your application, keep it up to date and still expect surprises...
Mavericks has been pretty good so far, but one truststy Applescript I'd been using for years decided it didn't wan to work anymore. The script is here:
tell application "Mail"
set the clipboard to (content of first message of ¬
inbox whose subject contains "2013-11-05") as string
end tell
The job of the script is to get the content from an email with a subject "J-List Reports 2013-11-05") (obviously this changes each day). If I change the script to look for "J-List reports" with no date it works fine, but it gets the wrong email since I can't specify the date (it looks for the first message that happens to have this string in the subject). If any numbers are in the Applescript, trying to force it to find the correct email, I get
"Mail got an error: can't get message 1 of inbox whose subject
contains 2013-11-05"
even though nothing else has changed.
Can anyone suggest a way to specify the correct mail, perhaps any mail whose subject contains "J-List reports" and whose month is 11 and whose day is 5? I spent a couple hours but couldn't get it to work for me.
This worked for me:
tell application "Mail"
content of message 1 of mailbox "[Gmail]/All Mail" of account "Gmail" where subject contains "2013-11-05"
end tell
set the clipboard to result
The messages are sorted from newest to oldest, so message 1 should be the newest message.
tell application "Mail" to messages of inbox and tell application "Mail" to messages of mailbox "INBOX" of account "Gmail" returned an empty list for some reason.
this works fine for me
tell application "Mail"
try
set the clipboard to (content of first message of ¬
inbox whose subject contains "2013-11-05") as string
on error errMsg
display dialog "an error: " & errMsg
end try
end tell
Try changing the string to something you know exists , I get the same error when I search for an email message where there are no matches. I suspect that you are not including the full error message here either
rror "Mail got an error: Can’t get message 1 of inbox whose subject contains \"2013-11-05\". Invalid index." number -1719
invalid index is important to a diagnosis because it tells us exactly what the problem is. There is no message that can be identified where the subject contains 2013-11-05
so you should use a try statement and then decided what to do from there.
Mail Version 7.0 (1816)
OS 10.9 build 13a603
My software is working with incoming e-mail from the one and only particular sender (let it be SantaClaus#hetnet.nl). According to RFC-2616 section 14 "From" header
MAY be used for logging purposes and
as a means for identifying the source of invalid or unwanted
requests.
That's exactly what I needed, so I wrote a code, which ignores all the messages where "From" field doesn't equal SantaClaus#hetnet.nl. It worked good, but one day things changed, and now all the messages form Santa Claus contains a different string in "From" field (exactly <SantaClaus#hetnet.nl>).
I already fixed my code, but I just wonder, is this header legal? Because the same RFC-2616 section 14 says:
The address SHOULD be machine-usable,
as defined by "mailbox" in RFC 822 [9]
as updated by RFC 1123 [8]:
From = "From" ":" mailbox
An example is:
From: webmaster#w3.org
Note the absense of angle brackets. But at the same time, many e-mail messages I receive on my Gmail account has something like this in the "From" field: "Santa Claus" <santaclaus#hetnet.nl>
RFC-822 allows email addresses to be specified either by a pure email-style address, called an "addr-spec" (e.g., name#host.domain); or by using a nickname ("phrase") with the email-style address (the "addr-spec") enclosed in angle brackets (Foo Bar <foobar#host.domain>). Your sender has gone from the first format to the second format, although here the nickname part seems to be empty.
By the way, RFC-2616 is for HTTP; you're looking at the definition of an optional, and (I imagine) rarely-used, From: header in the HTTP protocol. That doesn't seem to have any direct relevance on email formats.
My application uses sendmail to send outbound email. I set the 'From:' address using the following format:
Fred Dibnah <fred#dibnah.com>
I'm also setting the Reply-To and Return-Path headers using the exact same format.
This seems to work in the vast majority of cases but I have seen at least one instance in which this fails, namely when the name part of the above string contains a period (full stop):
Fred Dibnah, Inc. <fred#dibnah.com>
This fails deep inside the TMail code (I'm using Ruby) but it seems like a perfectly valid thing to do.
My question is, should I actually be setting the Return-Path and Reply-To headers using only the email address as opposed to the above Name + Email format? E.g.
fred#dibnah.com
Thanks.
In a situation like this, it is best to turn to the RFCs.
Upon reading up on your question, it appears as if You shouldn't be setting the Return-Path value ever. The final destination SMTP server is supposed to be setting this value as it transitions the message to your mailbox (http://www.faqs.org/rfcs/rfc2821.html starting at 4.4).
According to http://www.faqs.org/rfcs/rfc2822.html the Reply-To field can have the following formats
local-part "#" domain (fred#dibnah.com for example)
display-name (Fred Dibna for example)
I would recommend using option 1 as it seems to be the most basic, and you will likely have less issues with that format. In choosing option 1, your Reply-To field should look like the following:
Reply-To: fred#dibna.com