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
Related
I have a 3rd party service that i've configured a webhook that triggers posting data on my url address. Now i want to restrict incoming requests to be allowed only for this service. How can i do this in Django ? Is there any trick on applying some security measures?
i'd be glad if you can provide some code snippets, please
EDITED
I can't count on the ip address of the requester, it can change in any time. I should use domain name i think
EDITED 2
I have a header called HTTP_X_REAL_IP, that contains the ip address of the service. Can i count on that header by comparing the socket ip address with properly received header ?
It appears that they don't have anything set up to easily do a test, and you aren't saying exactly what you are doing with this API, but it appears that you can query their API for information regarding a bunch of things.
What I would do is to take the information they sent you and send it back in a query to see if the information they now have matches the change they are telling you they made. If they match, it is authentic. If they don't match, discard it.
That's about the best I can tell you to do.
No, you can't use the domain name, as you don't have it when processing a request (note that normally most requesters - internet users - don't have domain names, they only have IP addresses).
The simplest solution is to add an authentication key as required parameter to your APIs. Then, you process only those API calls which provide valid authentication key.
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.
I am currently in the finishing stages of building an application and have asked the user group to perform production-level usage testing on the application. My application is a makeshift order management system that sends an email to a customer when an order is saved that includes an invoice.
I ran into a problem yesterday when I was doing some testing; this environment currently contains production-quality data, including old customer records. I processed a few orders and forgot about the functionality, and the customer who I did the orders for received emails saying the order is complete. Good that it worked, bad that it lead to this confusion.
The action I would prefer would be to set something somewhere within the application that forces all emails, regardless of the to recipient, to be sent to a specific address, though I would settle for simply being able to turn it off for this application alone. Turning it off on the server level is available not a preferred option due to the need to perform testing on other applications that process email, but are not populated with production-quality data.
Are there any specific flags or code I can use to override server settings in the application to only send email to a certain address based on how we identify our environment, or to not send email altogether?
Reference this page:
http://cookbooks.adobe.com/post_How_can_I_use_Application_level_SMTP_Server_Settin-16469.html
For testing purposes you could set the SMTP server to a non existant IP address. The cfmail routine will still work and coldfusion will move it to an undeliverable folder.
You could add <cfif> statements around it to determine if your on a production URL or dev URL so that it uses the right server while on the production server, or uses the "fake" server while on your development server. OR while on the production server, have an on/off variable that you could use to test emails through your smtp server or shut off emails and route them to the fake SMTP server.
If your on version 8.0 or older, you can setup an application level variable for your mail server and modify your cfmail tags to reference:
<cfmail server="#application.mailserver#" to="" from="" subject="">
This solution presumes you use the same mail server but just want to swap emails to a test address (perhaps yours, so you can see the result). It also presumes your live server name resolves to something that has 'www.something.somethong.' and your dev/test/qa etc servers do not.
In your Application cfc onApplicationStart() try this:
<cfscript>
if(listFirst(CGI.SERVER_NAME,'.') != 'www') {
Application.szEmailToTestEnv = 'test#somewhere.com'; // Use your test email here
}
</cfscript>
Then where you send the email have a bit of logic infront of your mail param such that:
<cfscript>
if(isDefined('Application.szEmailToTestEnv') && len(Application.szEmailToTestEnv)) {
Variables.szEmailTo = Application.szEmailToTestEnv;
} else Variables.szEmailTo = Variables.qCustomerEmail;
</cfscript>
And then in your cfmail:
<cfmail to="#Variables.szEmailTo#"....
Adjust scopes and variable names and value as necessary.
Essentially, any 'site' (say dev.yoursite.com) that is not your live site will then use the test email you set at app startup to send the email and live will continue to use the correct customer email with no code changes between your live and test code.
I have several instances in my project where I attempt to send an email within a Django view.
I want to be able to hardcode the email sender within the view. When I try to do so, though, it continues to send the emails from the default account specified in my settings file.
Here is an example:
if testform.is_valid():
beta=testform.save()
subject="Hi Beta Tester"
sender="correct#email.com"
recipient=[testform.cleaned_data['email']]
text=loader.get_template('registration/beta_email.txt')
html=loader.get_template('registration/beta_email.html')
site_name='mysite'
d=Context({'site_name':site_name})
text_content=text.render(d)
html_content=html.render(d)
#This sends two mail versions, plain text and html
msg=EmailMultiAlternatives(subject, text_content, sender, recipient)
msg.attach_alternative(html_content, "text/html")
msg.send()
return HttpResponseRedirect('/splash/')
I thought that I could send specify the sender argument explicitly here. And, yet, when I test it, the email is being sent from the address listed in my settings file, configured as the following:
EMAIL_USE_TLS=True
EMAIL_HOST='smtp.gmail.com'
EMAIL_HOST_USER='wrong#email.com'
EMAIL_HOST_PASSWORD='private'
DEFAULT_FROM_EMAIL='wrong#email.com'
Do I just have to remove the DEFAULT_FROM_EMAIL constant to make it work? I tried doing so and it seems to be working but I'm confused. In the Django documentation, it suggests that setting sender in the view should override the DEFAULT.
I've finally figured out the issue here. Unfortunately, gmail rewrites the from and the
envelope on authenticated smtp.
If you want to get around that, you have to use a third party mail server (which doesn't act like such a prissy) and then send mail to gmail users.
For the sender e-mail try putting it in < > and you can add a name:
sender = "Formal Name <correct#email.com>"
that is exactly the syntax I have in my e-mail sending view and it works.
There really shouldn't be a reason that adding the name to it would change how it's sending, but it may be worth trying and perhaps you want an easily readable name anyway.
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. ;)