My company just turned on sender validation for the SMTP relay. So in the old days, I could send an email to nobody#company.com and it would not result in any error. Now, that email results in this:
"Error","scheduler-2","10/31/16","09:04:49",,
"com.sun.mail.smtp.SMTPSendFailedException:
250 2.0.0 xxxxxxxx-1 Message accepted for delivery ;
nested exception is: com.sun.mail.smtp.SMTPAddressFailedException:
550 5.1.1 User Unknown on Mail Relay"
Is there anything I can do via JVM arguments or anything else to ignore these errors and consider the email sent? There's a box where we send out 2-3K emails a day and there's about 1K of "undelivered" emails now on a daily basis. :(
The exception SMTPAddressFailedException is a result of a failed authentication on the mail server, so this is not related to the JVM configuration at all. ColdFusion simply builds mail content and adds it to the mail spooler. Due to the async. nature of a spooler, you cannot catch these errors at runtime.
Your only option is to communicate with the actual mail server before using cfmail (and ask if the sender is legit). However, as far as I know there is no built-in function/tag/tool in CF to do so.
Related
I've checked with the cfmail tag. But, if we use failto attribute. It doesn't work to me. So, what can I do? Could you please provide an exact answer to me?
There are many variables at play here but we rely on failto to function for a high volume email system so I can confirm it works. The underlying thing that is happening is that it lets you specify the envelope FROM for the message (what the email server sees) separately from the header FROM (what the receiving user sees). Envelope from can be considered like the reply address on a physical envelope and the header FROM like an address on the letter inside the envelope. If failto is not included in the cfmail tag then they are one in the same.
If the failto is being ignored for some reason or a mail server chooses to ignore it then then the header From address (cfmail from attribute) should be getting the bounce.
If the From address is not getting a bounce then your email is likely just not going out. The message has to reach the mail server for the bounce to occur. If ColdFusion is just failing to reach the mail server then mail will end up in the undelivr folder in your CF instance Mail directory. If that is happening then go into your CF admin interface and ensure the mail server can connect. To retry a message you can just move from undelivr to spool directory.
None of the above an issue? Make sure that you can send an email through your mail server to the failto address you are trying to use, otherwise there is no point in putting that address in the failto attribute.
If you're not getting a return email for failures, it's probably because the target email's server isn't set up to return a notification of failed delivery.
See here: https://community.adobe.com/t5/ColdFusion/CFMail-How-do-I-know-if-email-is-bounced/td-p/2001466
I have some development and test servers, that are only used for internal testing and development, but they often use setup from live solutions, including email addresses of customers and customers customers.
I would like to avoid the dev-solutions sending emails to customers, but allow them to send emails to developers, so that they can test the email part of the solution. I have tried a header_checks rule like this:
/^To:.*#(myowndomaion.com|myotherdomain.com|athirddomain.net)/ DUNNO
/^To:.*#/ REDIRECT mytestemail#myowndomain.com
And this works fine. If I send an email to test#gmail.com it will be forwarded to mytestemail#myowndomain.com and not be sent to test#gmail.com. But if I however send an email to myuser#myowndomain.comit will be send straight to the correct user. That is all fine.
The problem arises if I send emails to several email addresses!
So, if I send an email to test#gmail.com and myuser#myowndomain.com in the same email, they will both get the email (which they should not). The order does not matter, both will get emails in both cases.
So, does anyone have a better regex or some other better way to solve this?
Note: We use Postfix on Debian. (pretty standard Debian 6 and Debian 8)
I've configured a Sentry (https://github.com/getsentry/sentry) server to log and manage all the uncaught exceptions on my Django application, that uses Boto to send e-mail via Amazon SES. It is working well and sending e-mail alerts whenever something wrong occurs.
The problem is, almost everytime an error happens and Sentry sends me an alert, it also notifies me of another error (an exception on Boto while sending an email), but it doesn't show me what is the e-mail. I've tried all the bits of my code that send e-mail, and they are all ok. My SES config is also fine, since my application is sending e-mails to a lot of different customers daily
The error reported by Sentry is:
boto in _handle_error
<ErrorResponse xmlns="http://ses.amazonaws.com/doc/2010-12-01/">
<Error>
<Type>Sender</Type>
<Code>MessageRejected</Code>
<Message>Email address is not verified.</Message>
</Error>
<RequestId>4a085303-817a-11e4-b846-79819d3408ac</RequestId>
</ErrorResponse>
After this, i usually receive another error, but all it says is
boto in _handle_error
400 Bad Request
But besides all this MessageRejected warnings, when i go to my AWS Dashboard to check on SES, it shows no Rejects or Complaints, and just a really small number of Bounces (smaller than the amount of warnings i receive)
If i could at least see what email is he trying to send, it would help me debug this, but i can't find any clue about what's happening.
Boto config
The Boto section is used to specify options that control the operation
of boto itself. This section defines the following options:
debug: Controls the level of debug messages that will be printed by
the boto library. The following values are defined:
0 - no debug messages are printed
1 - basic debug messages from boto are printed
2 - all boto debugging messages plus request/response messages from httplib
Make sure you restart your Django server for the log level to take effect
The problem was the default email that Django sends to the emails on the ADMINS setting. Everytime we had an exception, it was trying to email root#localhost (the default value for ADMINS), but since this emails does not exists, it was failing to do so.
I have posted this question on the Amazon AWS Forums, but figured I might get a quicker, better answer here. I apologize if you see it twice.
My company uses an Amazon AWS SMTP server to send emails via a Java-based web interface. This is just a small part of our application, intended to allow users to invite other users to our application.
We have discovered on a very few number of occasions that certain email addresses are not receiving the invitations. Initially we thought it was related to hyphens in the email addresses, but now I've determined that this isn't necessarily the case. I have been troubleshooting this for some time using my own email domains, and I have determined that the following two email addresses NEVER receive any emails sent using the AWS SMTP server (email-smtp.us-east-1.amazonaws.com), but there are no errors reported during the sending process -- the emails just never arrive. The second list shows similar email addresses that always DO receive invitations sent using our system. Note that the addresses on the first list NEVER receive emails, I have tried from all of our deployed instances many, many times.
ADDRESSES THAT DO NOT RECEIVE EMAIL:
jeremygoodell#jeremygoodell.com
jeremy-goodell#jeremygoodell.com
ADDRESSES THAT DO RECEIVE EMAIL:
test#jeremygoodell.com
jeremy-goodell#pinkymcberry.com
jeremy-goodell#hotmail.com
jeremygoodelk#jeremygoodell.com
There are very, very few email addresses that end up with this problem. I was somewhat lucky to find two in my own domain that are exhibiting the problem. I have of course verified that this has nothing to do with spam filtering.
The application is written in Java using the play framework. Play uses Apache Commons Email library under the hood. You can read more about this here: http://www.playframework.com/documentation/1.1/emails.
Here are some of the steps I have taken during my troubleshooting efforts:
1) Try with a different SMTP server (using my personal ISP SMTP -- smtp.gvtc.com) -- ALL addresses DO receive emails when I use this SMTP server. This would seem to isolate the problem as being specific to the AWS SMTP server.
2) Set up my own AWS account and use the SMTP settings for this account (after verifying the addresses in question) -- I have the exact same issues using my own AWS SMTP account settings. This would seem to indicate that the problem is not specific to our company's AWS account.
3) Turn on the play email debug setting (mail.debug=true in the configuration file). A great deal of information is shown in the console for each email sent by the system, but there is absolutely no difference between emails sent to good addresses and those sent to bad addresses. There is no indication whatsoever of any errors.
Here is the contents of the log for one of the emails that never arrived. Note that this is using the AWS server I set up for myself. It looks exactly the same when I use our company's AWS SMTP server except that the from email address is different. I have removed the actual email content, since it's in HTML, somewhat confidential, and not relevant to the problem.
May 15, 2013 8:44:47 AM play.Logger info
DEBUG: getProvider() returning javax.mail.Provider[TRANSPORT,smtp,com.sun.mail.smtp.SMTPTransport,Sun Microsystems,
Inc]
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: useEhlo true, useAuth true
DEBUG SMTP: trying to connect to host "email-smtp.us-east-1.amazonaws.com", port 465, isSSL false
220 email-smtp.amazonaws.com ESMTP SimpleEmailService-376766033
DEBUG SMTP: connected to host "email-smtp.us-east-1.amazonaws.com", port: 465
EHLO 0.1.0.5
250-email-smtp.amazonaws.com
250-8BITMIME
250-SIZE 10485760
250-AUTH PLAIN LOGIN
250 Ok
DEBUG SMTP: Found extension "8BITMIME", arg ""
DEBUG SMTP: Found extension "SIZE", arg "10485760"
DEBUG SMTP: Found extension "AUTH", arg "PLAIN LOGIN"
DEBUG SMTP: Found extension "Ok", arg ""
DEBUG SMTP: Attempt to authenticate
DEBUG SMTP: check mechanisms: LOGIN PLAIN DIGEST-MD5 NTLM
AUTH LOGIN
334 VXNlcm5hbWU6
QUtJQUk3WDNURUI0NEVKNlRSU1E=
334 UGFzc3dvcmQ6
QXJwZjl4eU1FTVc1WFNFR3ZxVXVPODNhRjFkcG8xMFpSeURXY0ZsNGVHQXM=
235 Authentication successful.
DEBUG SMTP: use8bit false
MAIL FROM:<jeremy-goodell#hotmail.com>
250 Ok
RCPT TO:<jeremygoodell#jeremygoodell.com>
250 Ok
DEBUG SMTP: Verified Addresses
DEBUG SMTP: "jeremygoodell#jeremygoodell.com" <jeremygoodell#jeremygoodell.com>
DATA
354 End data with <CR><LF>.<CR><LF>
Date: Wed, 15 May 2013 08:44:47 -0500 (CDT)
From: "jeremy-goodell#hotmail.com" <jeremy-goodell#hotmail.com>
Reply-To: "jeremy-goodell#hotmail.com" <jeremy-goodell#hotmail.com>
To: "jeremygoodell#jeremygoodell.com" <jeremygoodell#jeremygoodell.com>
Message-ID: <2322287.7.1368625487826.JavaMail.UGOODJ3#SAOTXWL-9X913M1>
Subject: Please join the ACT Aspire Hari AV test delivery portal
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_6_16196755.1368625487826"
------=_Part_6_16196755.1368625487826
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
>>>> HTML EMAIL BODY REMOVED <<<<
------=_Part_6_16196755.1368625487826--
.
250 Ok 0000013ea86fb2de-0bd70205-8e9a-4042-972f-ad94b28c3101-000000
QUIT
221 Bye
I'm going to follow up here with what turned out to be the solution to the problem. The Amazon AWS SMTP service maintains a "14-Day Suppression List" which is a list of email addresses that have bounced during the last 14 days. Any email sent via the Amazon SMTP service will fail when attempting to send to an address on the Suppression List. Unfortunately, they don't report the error, but instead, send an "Undeliverable" reply to the sender. So, if you have an automating sending service, you'll never know.
I happened to find it because when I set up my own AWS SMTP server, I put in one of my own email addresses as the sender of the automated email. When I logged into that email account, I saw the Undeliverable messages, which explained that the target email is on the Supression List.
Amazon does allow you to log into your Email Service Console and remove email addresses from the Suppression List. You just put in the email address, click Remove, and the address is immediately removed from the list. You have no way to see which email addresses are on the Suppression List, but you can remove any address you want.
So, in the case of my email failures, I believe what happened was that I tried to email to them before the email creation was complete, resulting in a bounce. Once the email address bounces, it goes on the Supression List. For the next 14 days any email sent via ANY AWS SMTP server (not just mine) would fail. After 14 days (apparently) the email address is removed from the Suppression List until the next bounce is encountered.
This Amazon software is very new, they actually just announced this Suppression List service in early May. So they may still need to work out a few kinks. This particular issue seems to present a somewhat serious issue for automated senders like ours. After all bounces do occur on occasion for reasons beyond our control.
I can't believe I've never noticed this before, but it seems that CFMail won't send to an email address that isn't explicitly set up on the destination mailserver.
This means that if I'm using 'info#somedomainorother.com' and have that set up to catch all email on the domain, CFMail won't send to 'test#somedomainorother.com'.
This causes a massive amount of problems for me, as I'm using CFMail to send out order confirmations, member activations and all manner of other bits and pieces.
Whatever your views on using catchall addresses, it can't be denied that people do use them So, in any case that a user enters a made-up address into one of my sites, they won't receive their email.
There must, simply MUST be a way around this - can anyone help?
For refernece, the message that appears in the logs when sending to a catchall address is 'Invalid Addresses'.
EDIT: Here's the CFMail syntax I'm using -
<cfmail to="#Arguments.sEmailAddress#" from="#Application.sAppEmailAddress#" subject="Stock reminder confirmation: #Local.qGetProductDetails.sProductName# - #Application.sCompanyName#" type="HTML" server="#Application.sAppEmailServer#" username="#Application.sAppEmailAddress#" password="#Application.sAppEmailPassword#">
Translates into:
<cfmail to="thisisatest#somedomainorother.com" from="application#mydomainname.com" subject="Stock reminder confirmation: Some product - My Company" type="HTML" server="mail.mydomainname.com" username="application#mydomainname.com" password="XXXXXX">
All works fine for info#somedomainorother.com but not for randombunchofcharacters#somedomainorother.com.
Important to note of course, that the catch-all is working correctly in all other respects, test emails from mail clients work perfectly.
Its not ColdFusion that cares about email validity, its the SMTP server. CF only cares about well formed email addresses.
If you initiated a telnet session to your mail server and tried to use the same address, I'm sure it would have the same result.
Debugging tips for SMTP Connectivity:
http://www.talkingtree.com/blog/index.cfm/2004/11/22/debug-smtp
Can I see your CFMAIL tag setup? CFMAIL doesn't care as long as the email address is properly formatted.
Urgh!
Turns out it was an issue with the server. For some reason, catchall email accounts serverwide had stopped working properly. After an email to my hosting provider, it's all working fine with no code changes.
They're somewhat cagey as to what caused the issue, and I was still able to use an email client to send mail out to the addresses...
Thanks for the help in any case. ;)