1 of 1 people found this helpful
Most likely culprit is the name field in the SMTP server parameters, but there could be other issues such as with authentication. You really just have to play around with the various settings until you find the correct combination.
and this one is even better: http://www.savvydata.com/blog/2009/11/fixing-smtp-send-mail-error-1506/
The Savvy Data article has a link to a download file that I have found very helpful in the past. It is a FMP file that you feed in a few values and it goes off and tries sending SMTP email to your target server using a whole bunch of variations. If it finds one that works, it stops and notifies you of what combo of settings works.
Thanks. I found the tip about the name field in the SMTP parameters in another post and the client will be testing it today. I have downloaded the Savvy Data file. I will try it tonight, if the name fix doesn't work.
1 of 1 people found this helpful
One thing to check in to is the client's mail server. These days most Mail servers have the SMTP service turned off or set to accept SMTP traffic from a specific set of hosts/ip Addresses. I did this for an organization that used an Exchange sever and it took both the Exchange admin and the Active Directory admin to set things up so that a number of computers in the organization could send SMTP mail.
I have also been able to get around this by using Google as the SMTP gateway and setting up an account for the out going e-mail.
This client is using Verizon FIOS, which is currently using an SMTP server on port 495. I think we are okay on that front.
The problem seems to be that the server is having a problem with some records and not with others. If I understand my client correctly, when it encounters a problem record, the script aborts and generates the 1506 error code. Turning Error Capture on or off doesn't allow the script to simply ignore errors and continue. Initially, I thought that the records of contacts whose email address was left blank were triggering the error. But removing those records from the found set did not resolve the issue.
My best guess at this point is that something else is causing Verizon's SMTP to time out or reject the mailing based on another factor. Since we are below the client's limit of 200 records per mailing, it has to be something other than the number of records in her found set. I have removed the name in the SMTP setup dialog, as described above and elsewhere. The client will be testing it today. If that does not remedy the problem, I am going to use the Savvy Data file to try to diagnose the probable cause.
If all else fails, I may have to restort to Google or some other mail server as a work around.
My client is reporting that removing the name from the SMTP server properties did not resolve the problem.
I ran the Savvy Data app, testing all possible combinations. The test message did not go through. The script returned the following error code for each attempt:
Again, not a terribly helpful answer.
I am going to attempt this again with a gmail account.
You don't really say much about the Verizon FIOS server or the operating system of your client.
I do see a compatibility upgrade notice from Verison
I can tell you that I went through this when first switching to FMS 11 and a (client managed) Windows mail server set to TSL. I got the same error using either TSL and SSL however when I set FMS to SSL the email would go out in spite of still giving me the error message. The client's IT guys assured me that all this was happening inside their firewall and security was not effected. So I suppressed the error message.
This was a while back and no further complaints. So while my circumstances were different (FMS vs FMP), see if this is a path for you.
try expressing the account name as the whole email address...
The account name is and always has been expressed as the whole email address, as per Verizon's specifications. I have used the same settings for the SMPT server (SSL, etc.) that Verizon specified for the users' email client.
Users are running Windows XP and 7. I am testing here on Windows 7.
The solution file is on a remotely hosted WAN.
The data source for the recipients' email addresses and other content is in a SQL table.
When the script to send mail is run, some of the messages go through and are either delivered or bounced back from the recipient if the email address is no longer valid. Other messages are neither sent nor returned. The messages that are being rejected have nothing in common with each other.
When I ran the Savvy Data test, it returned an error code of 1502 (connection refused by SMTP server).
I am trying a gmail account now.
First test with gmail (34 records) was a success. Second test (100 records) generated error codes 1501, 1503 and 1506.
Does anyone have an idea about what may be going on? Is there a limit to the number of records that can be sent?
Any other suggestions?
I'd say so.. many smtp servers will have a limit... probably around the 100-200 mark is normal. You can either negotiate to have this limit removed for you or do as I have to do in one project which is to break up the sends to more batches.
The account name is and always has been expressed as the whole email address, as per Verizon's specifications.
So perhaps try the opposite... ie just the account name not the full address. None of the servers I sending mail to require the full email address for the account... but I have seen it before on older servers.
"So perhaps try the opposite... ie just the account name not the full address. None of the servers I sending mail to require the full email address for the account... but I have seen it before on older servers."
Yes, tried that as well, even though I know better. No luck. Verizon FIOS does require the full addresss. I remember that from when I was a Verizon customer and it is stated as required in their current online help. The records from which messages can be successfully sent seems to be arbitrary when the full addresses is included. If I use just the account name, no messages are sent.
With gmail, a set of 34 records is sent without a problem. A set of a little over 100 sends no messages at all. The gmail online help says the limit is 500 messages.
We are going back to using the client's default email app, rather than specifying SMTP settings in the Send Mail dialog. The client has installed Eudora open source version 1, which appears to be built on Eudora + Thunderbird code. FMP says it supports Eudora, but doesn't support Thunderbird. Don't know what to expect at this point.
Client is getting totally fed up with this, as am I. If the above doesn't work, we're going to just export fields from FMP, import them into Eudora, then use a plug-in to do a mail merge in Eudora. (Client hates this approach, but is willing to settle for it, as there is no clear end in sight to making this process work another way.)
Before the latest "security" changes to Outlook & Windows, I used to do bulk email scripts from FMP all the time without any of these problems.
You can go through the throws of figuring out why you have misconfigured your SMTP settings and it is a pain. I've done it for many people and you can make it work. But I quit messing with that a long time ago and I set up my server machines to always have the mail service on and to allow auto-relay from itself via IP 127.0.0.1. Then whenever I have the server sending out emails, I don't have to authenticate as long as I point the SMTP to send mail via 127.0.0.1. Also, since it is your own mail server, you won't have email limits to worry about hitting. Using the 127.0.0.1 IP assures you that only applications and services on your server can use the auto-relay feature since you obviously don't want to open that up to the world. Then my FileMaker scripts are much easier to manage for sending mail. Also, whenever you get limited by the FileMaker Send Mail limitations, checkout some of the plugins that give you many more features. I personally like the CNS SMTPit. One more thing, I have been assuming you are using FileMaker Server to host the database.
One issue is your client is reporting that the script aborts when the Send Mail hits an error. If Allow User Abort[Off] and Set Error Capture[On] is true, that shouldn't happen, even on Server. That's most likely an misunderstanding on your client's part.
Also, I've seen different limits for Gmail sends. My guess is they either change them or keep them deliberately vague to discourage spamming.
For both Gmail and Verizon, it could be you're connection is getting flagged because you're trying to send too many per minute or something similar. Try putting a short Pause after each send. I'd recommend a random length pause of 1-5 seconds.
I've seen false 1506 errors on Gmail where the e-mail actually did go through. Could that be happening?
Finally, could it be a problem with the address? Maybe an extra space at the end? Have you logged the addressed that go through and those that get rejected and looked closer at those?
Actually, it isn't our own mail server. The client is a very small non-profit organization, run from the founder's home. It's WAN is on a server farm run by another company and rented by the month. Its SQL server is on another machine, hosted by a different company, which also handles their web site, web apps, and web sales. Email is sent through the client's ISP (Verizon FIOS) at the client's residence. So, no, we don't have a lot of control over this.
I am using the same SMTP settings in the FMP SMTP Setup dialog that the client has been using successfully for years when manually sending mail through Thunderbird. I can see no reason why these same settings should work only intermittently when sending mail through FMP. Nor have I been able to find any reason why gmail should work okay on one set of records and not on another. Rightly or wrongly, the client is blaming FMP because it is only when FMP is in the equation that we have had these problems.