I can't get redmine's email notifications to work. I am running my own mailserver with postfix using some mysql backend for the accounts. I added an account for redmine and tested it successfully using thunderbird. It is configured on port 25 using STARTTLS.
This is my config/configuration.yml of redmine:
production:
email_delivery:
delivery_method: :smtp
smtp_settings:
tls: true
address: www.mydomain.org
port: 25
authentication: :login
domain: mydomain.org
user_name: tracker#mydomain.org
password: PASSWORD
As I said, the credentials work for sure. The port is 25 and the address is correct as well. Redmine is running on the same server, but using localhost as address doesn't work either.
The error message redmine is giving me reads
... (Connection timed out - connect(2)).
In the postfix log files, I can find nothing, not even an attempt to login or send an email. I am using Ruby 1.8.7 patchlevel 3xx and Rails 2.3.5. It seems like there is a problem with the connection in general, and not with my mailserver.
What can I do to find the source of the problem? I am not very familiar with how ruby works.
I figured it out... Below the commented, suggested configuration blocks in the configuration.xml file is another, uncommented email block, that reads
default:
email_delivery: ...
Even though I thought that by uncommenting the production: block these settings would be overridden, it started working the moment I inserted the email settings into this default block. This is a bit weird, but anyway - it does work now like a charm.
Related
I am using gerrit 3.2.1
After I tried everything I can do to configure my gerrit.sendemail, I failed to send a verification mail
[sendemail]
enable = true
smtpServer = smtp.offce365.com
smtpServerPort = 587
smtpEncryption = ssl
sslVerify = false
smtpUser = gerrit#gerritserver.com
smtpPass = pswd
I refered to https://groups.google.com/forum/#!msg/repo-discuss/RWvdXR-Z4nA/1USSK1F6AAAJ\
but seems I met different problem,
For the encryption, according with office 365, the SMTP uses STARTTLS, but seems it always fail. I tried ssl, tls, neither works.
I also tried port 25.
[2020-06-16T14:33:53.834+0800] [WorkQueue-2] INFO com.googlesource.gerrit.plugins.deleteproject.fs.RepositoryCleanupTask : Cleaning up expired git repositories... Done
[2020-06-16T14:35:32.927+0800] [plugin-manager-preloader] INFO com.googlesource.gerrit.plugins.manager.OnStartStop : 66 plugins successfully pre-loaded
[2020-06-16T14:36:13.420+0800] [HTTP PUT /accounts/self/emails/name%40emailhost.com (flynn from 127.0.0.1)] ERROR com.google.gerrit.server.restapi.account.CreateEmail : Cannot send email verification message to name#emailhost.com
com.google.gerrit.exceptions.EmailException: Mail Error: Connection timed out (Connection timed out)
at com.google.gerrit.server.mail.send.SmtpEmailSender.open(SmtpEmailSender.java:437)
at com.google.gerrit.server.mail.send.SmtpEmailSender.send(SmtpEmailSender.java:207)
at com.google.gerrit.server.mail.send.OutgoingEmail.send(OutgoingEmail.java:225)
at com.google.gerrit.server.restapi.account.CreateEmail.apply(CreateEmail.java:164)
at com.google.gerrit.server.restapi.account.CreateEmail.apply(CreateEmail.java:121)
at com.google.gerrit.server.restapi.account.CreateEmail.apply(CreateEmail.java:71)
Is this related to this question on the mailing list?
Also, when I check the office365 smtp settings it looks like it should use tls instead of ssl:
SMTP Host: smtp.office365.com
SMTP Port: 587
SSL Protocol: OFF
TLS Protocol: ON
SMTP Username: (your Office365 username)
SMTP Password: (your Office365 password)
Try to change your settings to tls and maybe you need to implement the workaround for java11.
1 more tip when I come back to this 3 years later...
I met another problem with similar phenominal.
It turns out some mail server requires the field 'from' must be equal to 'smtpUser'.
In ejabberd 18.01-2, installed in lxc container Ubuntu 18.04 Bionic LTS using apt, I'm trying to setup mod_http_upload.
In the section listen, I have
listen:
-
port: 5444
module: ejabberd_http
tls: true
request_handlers:
"/upload": mod_http_upload
In the configuration file, commented port was 5444, however, in the current documentation, it is 5443, so I am not sure which one is right.
In the modules section, I have
modules:
mod_http_upload:
host: "upload.ejabberd.forumanalogue.fr"
max_size: infinity
thumbnail: true
put_url: "https://ejabberd.forumanalogue.fr:5444/upload"
docroot: "/ejabberd/upload"
When I start the service, I can see an odd message in the logs
2019-11-11 21:02:35.287 [warning] <0.367.0>#ejabberd_pkix:handle_call:255 No certificate found matching 'upload.ejabberd.forumanalogue.fr': strictly configured clients or servers will reject connections with this host; obtain a certificate for this (sub)domain from any trusted CA such as Let's Encrypt (www.letsencrypt.org)
It is strange because I have a signed wildcard certificate.
certfiles:
- "/etc/letsencrypt/live/forumanalogue.fr/*.pem"
I can see the service with my client (Gajim) but when I try to send a file to another local account, I receive an error Access denied by service policy, see the complete log:
<iq xml:lang='en' to='foo#forumanalogue.fr/gajim.HCLJ4BZI' from='upload.ejabberd.forumanalogue.fr' type='error' id='1dd35274-90e9-4b3b-9608-0fab59afe34e'>
<request xmlns='urn:xmpp:http:upload'>
<filename>a.out</filename>
<size>27232</size>
<content-type>application/octet-stream</content-type>
</request>
<error code='403' type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>Access denied by service policy</text>
</error>
</iq>
I had to enable debug logging in order to see something. It is quite verbose, but I think that the relevant part, which is non redundant with the client message, is
2019-11-11 20:53:08.329 [debug] <0.501.0>#mod_http_upload:process_slot_request:544 Denying HTTP upload slot request from foo#forumanalogue.fr/gajim.HCLJ4BZI
Thank you for your help.
I tried with ejabberd 18.01, a configuration similar to yours, and it works for me.
Looking at the source code, that "process_slot_request:544 " error means that the account attempting to use the upload feature is not allowed by the "local" Access rule in the vhost it sended it to. Probably it's a remote account. Remote to that upload service. In other words, the service upload.whatever can only be used by accounts like user12#whatever.
In your case, you are attempting to use upload.ejabberd.forumanalogue.fr from account foo#forumanalogue.fr, which is not local to that upload service.
Several ideas, I hope one of them suits your specific setup:
A) don't mess with vhosts. If it's forumanalogue.fr, keep it that everywhere
B) use #HOST# in host and put_url options
C) Or if you really want to mess with hosts, then add Access rights so accounts in that vhost are considered "local" to the upload service.
I'm currently trying to run a mastodon server I've installed everything correctly and I haven't gotten an error till now
I'm setting up my SMTP this is the info I've put in
SMTP server: smtp.mailgun.org
SMTP username: mastodon#notifications.example.com
SMTP password:
SMTP authentication: plain
SMTP OpenSSL verify mode: peer
Then when I try to send a test e-mail it throws this error
E-mail could not be sent with this configuration, try again.
SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate)
Ahh! So someone just pointed out on this thread (https://mastodon.social/#slackz/99772551531768277) that authentication SMTP_AUTH_METHOD and SMTP_OPENSSL_VERIFY_MODE should be commented out in the config. The mastodon:setup rake task automatically adds them (gonna look into making a PR to change that), but if you:
comment out the two lines in .env.production with the above env variables
ensure all your mailgun account records are verified, that you can send email with a curl command they supply on their site
restart the mastodon processes:
sudo systemctl restart mastodon-*
Opened an issue about the behavior here:
https://github.com/tootsuite/mastodon/issues/6975
I have a local SMTP email server I use for testing purposes running on my machine. It listens for SMTP on port 25. I am able to send and receive emails to it using a regular email client.
When I build a Node-RED flow that contains an e-mail output node and configure its properties with:
to: <email address>
server: localhost
port: 25
and submit a flow, I get the error:
25 Feb 16:43:24 - [error] [e-mail:<email address>] Error: 101057795:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:openssl\ssl\s23_clnt.c:794:
I am at a loss on how to proceed. Looking at the messages, it almost appears that there is some form of SSL negotiation/test at play here. Switching on trace on my SMTP server, I find the following logs each time I try and run a flow:
"TCPIP" 10708 "2016-02-25 16:43:08.294" "TCP - 127.0.0.1 connected to 127.0.0.1:25."
"DEBUG" 10708 "2016-02-25 16:43:08.298" "Creating session 22"
"SMTPD" 10708 22 "2016-02-25 16:43:08.298" "127.0.0.1" "SENT: 220 WIN7-X64 ESMTP"
"DEBUG" 9772 "2016-02-25 16:43:08.299" "Ending session 22"
It appears that the Node-RED node is sending a connection request, getting back the SMTP 220 response and then failing immediately after that.
I came across the same problem and have a nasty hack that will enable mail to go via my local exchange server's plain SMTP, with no auth.
Edit the .../61-email.js file and change it thusly:
var smtpTransport = nodemailer.createTransport({
host: node.outserver,
port: node.outport,
secure: false,
ignoreTLS: true //,
// auth: {
// user: node.userid,
// pass: node.password
// }
});
I see Dave has replied to the github issue but just to close the loop on this question.
At this time (Feb 2016) the node assumes SSL is always available and enabled, at some point we need to go back to the email node and find a simple way to expose a lot more of the nodemailer options to allow connections to a wider range of email providers both public and private.
I recently uploaded a Symfony2 project to GoDaddy and I'm having trouble accesing it because I get the message:
An exception occured in driver: SQLSTATE[HY000] [1045] Access denied for user 'root'#'127.0.0.1' (using password: NO)
Obviously the message is clear, so I checked and rechecked my parameters.yml, and the message don't even match what I have there, which I have changed several times to try to fix. This is my parameters.yml:
parameters:
database_driver: pdo_mysql
database_host: localhost
database_port: null
database_name: database1
database_user: database1user
database_password: mytestpassword
mailer_transport: smtp
mailer_host: 127.0.0.1
mailer_user: null
mailer_password: null
locale: en
secret: RandomTokenThatWillBeChanged
debug_toolbar: true
debug_redirects: false
use_assetic_controller: true
So, the error message doesn't tell me what is my real problem, or it is loading the parameters from some cached version that I haven't found yet. Any ideas of what else could cause or where could a cached version of this data be?
One of the best practice when developing a Symfony application is to
make it configurable via a parameters.yml file. It contains
information such as the database name, the mailer hostname, and custom
configuration parameters.
As those parameters can be different on your local machine, your
testing environment, your production servers, and even between
developers working on the same project, it is not recommended to store
it in the project repository. Instead, the repository should contain a
paramaters.yml.dist file with sensible defaults that can be used as a
good starting point for everyone.
Then, whenever a developer starts working on the project, the
parameters`.yml file must be created by using the parameters.yml.dist
as a template. That works quite well, but whenever a new value is
added to the template, you must remember to update the main parameter
file accordingly.
As of Symfony 2.3, the Standard Edition comes with a new bundle that
automates the tedious work. Whenever you run composer install, a
script creates the parameters.yml file if it does not exist and allows
you to customize all the values interactively. Moreover, if you use
the --no-interaction flag, it will silently fallback to the default
values.
http://symfony.com/blog/new-in-symfony-2-3-interactive-management-of-the-parameters-yml-file
So, is it not possible that your paramaters.yml is overwritten by paramaters.yml.dist?
You can also try to completely clear the cache
In Dev:
php app/console cache:clear
In Production:
php app/console cache:clear --env=prod --no-debug