Mail plugin issue in grails - mail not reaching destination - email

i am new to grails ,
i created a new project to check mail plugin.
In the controller i added the following command in index
sendMail {
to "my_mailid#gmail.com"
from "another_valid_id #gmail.com"
subject "link test"
body 'haiiii'
//html g.render(template:"mailtemplate",model:[code:UUID.randomUUID().toString()])
}
render "send"
when i am running the application it shows no error and display send in browser. but when i am checking the my mail inbox mail is not reached.
i didn't done any changes in config file. as it by default works in localhost and in port 25.
thankz in advance

http://grails.org/plugin/mail
By default the plugin assumes an unsecured mail server configured at localhost on port 25. However you can change this via the grails-app/Config.groovy file.
It assumes an unsecured mail server on your localhost on port 25. If there isn't one running there, it won't send mail. I'm not sure what your operating system is, but if you are on a mac or *nix system, postfix comes installed.
sudo postfix start
If you're on Windows you can find an alternative. Honestly, it's easy to simply configure to send from a gmail account which is what I have done for my clients. You can see how to do that at the link above.

Related

Local email to root should not leave the host

I am trying to set up the most simple email server on an Amazon Linux 2 host for simple outbound mail (e.g. sending system messages). Following instructions on the net, I have installed mailx and sendmail. I am not committed to either package, I just want a simple setup with a minimal footprint. I have no problem switching to postfix if that is a better solution.
For configuration I have made the following changes.
/etc/sysconfig/sendmail:
DAEMON=no
/etc/mail/submit.cf (hostname obfuscated):
D{MTAHost}smtp.******.com
This works fine, and I am able to receive mail that is sent from the system.
There is a wrinkle. The anacron process is sending mail to the root account. However, rather than the mail being kept internal to the system it is being sent to the SMTP server. The SMTP server sends the message back to my host, which doesn't accept mail, and a loop is created when an 'undeliverable' message is send back to root on the host that doesn't accept mail.
How can I configure my system so email to root stays local and is not sent to the SMTP server? Any other 'best practices' suggestions would be welcome as well. And again, if switching to postfix is better, I am willing to do so (but will need configuration guidance).

Telnet works but email doesn't

I'm setting up an Alfresco AWS instance and trying to configure inbound email.
As per the documentation I've configured it, hosted the Alfresco mail server on port 1025, set up an iptable rule to forward port 25 --> 1025, set up an folder in Alfresco with the alias 'dropoff' and added my work email as an allowed user for sending emails. I've also ensured all the ports are open on the EC2 instance
So far so good. If I test everything from my local computer with telnet:
helo mywork.com
mail from:myname#mywork.com
rcpt to:dropoff#alfresco.mywork.com
data
From: adinihan#mywork.com
Subject: test mail from command line
this is test number 1
sent from linux box
.
Then it works. I look in the Alfresco folder and there's the test email document. However, if I use Gmail and sign into myname#mywork.com and send an email through Gmail, then it doesn't work. It sends alright and there's nothing in Alfresco logging, however the document just never appears in the Alfresco folder. The from/to address is the same as the telnet command's one.
Since I can telnet from my local computer to the instance I assume it's not an issue with ports on the EC2 instance. Why would telnet work but sending it via Gmail not?
EDIT: got an email back from Google about an hour after I sent it with the error message TLS Negotiation failed: generic::failed_precondition: starttls error (0): protocol error
EDIT 2: here are my inbound emai settings in the global properties file
# Inbound #
email.inbound.unknownUser=anonymous
email.inbound.enabled=true
email.server.enabled=true
email.server.hideTLS=false
email.server.enableTLS=true
email.server.requireTLS=false
email.server.port=1025
email.server.domain=alfresco.amritmro.com
imap.server.enabled=true
imap.server.port=1143
imap.server.host=0.0.0.0

Plesk, Email with localy established domain where the mail server is external

i have a big problem with the setup for an Domain.
The Webservices are established on our Server but the Mail functions are on a Server of an other Company when we now want send an Email over our Server he tried to send it localy insted of sending it to an other server so he give back an no account here error.
Thanks for helping me out and friendly greetings.
Edit: OS Debian 6
Imap: Courier
Send: Postfix
CP: Plesk
Further to this, we are using Plesk 11.5.3 on a setup where a single mail service is activated for all domains.
So each domain cannot have the mail service turned on or off individually.
We had the same problem as Franco, and we fixed this by running the following command for each domain that had external email:
# /usr/local/psa/bin/mail --off domain.com
Works perfectly, and removes any previously created local email addresses from Postfix.
"The problem is because the server will attempt to deliver emails for the domain name locally by default. To resolve that problem you would need to set it to use the domain name's MX record."
The simple answer is to disable mail services for the subscription.
Untick the box for "Activate mail service on domain".

how to send email in joomla if my webpage is run on localhost?

i used login module in my webpage. in that by clicking on 'forgot password?' i need to give an email-address but by clicking on Send button the error is 'could not install mail function'.
so, please give suggestion, my web page is running on localhost.
It appears your computer's version of php does not have working mail. I would suggest you A: reinstall joomla, B: find the hash function in the php and replace the old password hash with a new one, or C: find a mail plugin for your version of xamp/wamp/whatever.
If you are in a Windows platform try the following:
Open the php.ini file. For XAMPP, it is located in
C:\XAMPP\php\php.ini
Change the localhost to the smtp server name of
your ISP. Leave smtp_port as 25.
Change sendmail_from from me#localhost.com to your domain email address which will be used as the from address
Restart XAMPP or WAMP (apache server)
Try to send the mail using the mail() function
I think it should solve your problem.

sendmail and MX records when mail server is not on web host

This is a problem I'm sure is easy to fix, but I've been banging my head on it all day.
I'm developing a new web site for a client. The web site resides at (this is an example) website.com. I have a PHP form script to email visitors' requests to requests#website.com.
When I coded this on a staging server on a different domain, all worked fine. When I moved it to website.com, the mail messages never arrived. The web server is on a virtual host with a major ISP.
Here's what I've learned since then: My client's mail server is Microsoft Exchange on a box physically in their office. Whenever someone on the outside world emails requests#website.com, the mail arrives. But if the web server sends to the same email address, it fails every time. This is not a PHP problem. I secure shell in to the web server and have tested this both with sendmail and the UNIX mail application. I've also tested it by emailing various email accounts from the shell. I can email myself, for example, just nobody at the website.com domain.
In short, when I'm logged in to website.com, mail to requests#website.com, user#website.com, another_user#website.com all fail. All other addresses work fine. What I've discovered is those dropped emails are routed to the web server's "catchall" account where they sit in its inbox.
I've done an MX lookup on website.com. The MX record points to mailsec.website.com. I can telnet to mailsec.website.com port 25 and see the SMTP server.
It appears to me that website.com isn't doing an MX lookup when it's sending mail to requests#website.com. My theory is that it recognizes the domain as local, sees that there's no "requests" user account to deliver it to, and drops the mail into the catchall account. What I want is to force sendmail to do the MX lookup and send the message on to the Exchange server. I'm at wit's end here. I can't figure out how to do this.
For that matter, I may be way off base here and have misdiagnosed this entirely. Internet mail and MX has always seemed a black art to me, and my ignorance is certainly showing in this question.
I think the problem is that sendmail (your process) is talking to the local sendmail daemon. The local sendmail daemon thinks that because it is website.com, it should know how to deliver the email. Unfortunately, the actual address in the to field does not exist on the web server and thus it dumps it in the "catchall" mail box. You should talk to your ISP and have them update their sendmail configuration so that mail addressed to ...#website.com gets forward to the mail exchanger instead of being handled locally.
Sendmail by default guesses list of local email domains.
It can be turned off using the following line in your sendmail.mc file:
define(`confDONT_PROBE_INTERFACES',`True')
As root list local email domains before and after the change using:
echo '$=w' | sendmail -Am -bt
You will see which domains should be added "manually" to (usually) /etc/mail/local-host-names file after disabling auto-guessing.
After changing sendmail.mc:
Generate/compile new sendmail.cf file
Restart sendmail daemon (or send HUP signal)
tvanfosson basically has it, but as a temporary workaround, you should be able to change your script so that it mails 'user#mailsec.website.com', and then the mail will get delivered to the actual mail server.
Edit the tsm.cf file (in /etc/mail/ or similar) to include
FEATURE(relay_entire_domain)
between the DOMAIN() and MAILER() lines. Since you're editing the file, you may want to also improve security with
define(`confPRIVACY_FLAGS',``noexpn,novrfy'')
After changing the tsm.cf file (or any sendmail config file), restart or SIGHUP the sendmail process.
This change is necessary because the WWW and MX servers for the domain do not exist in the same process space; this FEATURE triggers sendmail to process messages for the domain using it's external delivery mechanism.
The edited portion of the tsm.cf file should look similar to this:
DOMAIN(website.com)dnl
FEATURE(relay_entire_domain)dnl
define(`confPRIVACY_FLAGS',``noexpn,novrfy'')dnl
MAILER(smtp)dnl
MAILER(procmail)dnl
What worked for me was to add an MX record on the webserver hosting the website, that points to the host assigned on the original domain name server. In the case presented here would be an mx record pointing to: mailsec.website.com
I'm new here. Wanted to extend RB_CWI answer, but I am not allowed to comment.
His solution worked great.
You are not required to define the DOMAIN().
However, on my system I was required to install the sendmail-cf package.
The instructions below were done on CentOS 6.5
First, install sendmail-cf
sudo yum install sendmail-cf
Then, edit the senmail.mc
sudo vi /etc/mail/sendmail.mc
At the bottom of the file add FEATURE(relay_entire_domain)dnl, so it looks like:
...
FEATURE(relay_entire_domain)dnl
MAILER(smtp)dnl # right above this line
MAILER(procmail)dnl
dnl MAILER(cyrusv2)dnl
Save the file, and restart sendmail.
sudo service sendmail restart
Got stuck on the same problem. MX points to an external Exchange server but php/sendmail did not lookup this record. Instead mails posted by WordPress on this webserver dropped in the catchall-mailbox.
Solution was to delete ALL mailboxes on the webserver. Now sendmail was interested in the MX and all mails went to the Exchange.
However, the Exchange uses the webspace's mail server as SmartHost for outgoing mails. As solution for this, we were able to use the FTP credentials for accessing the mail server. I assume this solution does not work on every provider on this planet, but in our case (all-inkl.com) it worked out.