The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
On 6/16/2015 10:44 AM, Steve Matzura wrote:
The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
No attempt to deliver almost always means either:
- a DNS problem; the sender can't find the destination, or finds the "wrong" destination.
- a connectivity problem; the sender can't connect to the destination. Possibly a firewall not open.
On Tue, 16 Jun 2015 11:27:58 -0500, you wrote:
No attempt to deliver almost always means either:
- a DNS problem; the sender can't find the destination, or finds the "wrong" destination.
That would be interesting, since I tried both the actual IP address and the DNS name for the test node. Neither message got through.
- a connectivity problem; the sender can't connect to the destination. Possibly a firewall not open.
Now there's a possibility, but I am not aware of running any firewall on the remote machine.
Date: Tuesday, June 16, 2015 01:13:47 PM -0400 From: Steve Matzura number6@noisynotes.com
On Tue, 16 Jun 2015 11:27:58 -0500, you wrote:
No attempt to deliver almost always means either: the "wrong" destination.
- a DNS problem; the sender can't find the destination, or finds
That would be interesting, since I tried both the actual IP address and the DNS name for the test node. Neither message got through.
- a connectivity problem; the sender can't connect to the destination. Possibly a firewall not open.
Now there's a possibility, but I am not aware of running any firewall on the remote machine.
By default, most MTAs only listen to localhost, so don't accept externally derived mail. Try telnetting to port 25 on the machine from some place off your machine's network. If you get a "hang", it's likely a firewall issue. If you get a "connection refused" message it's probably that the MTA isn't listening on the external interface.
If the MTA responds, do a manual delivery exchange and see what you get.
If you're not seeing anything in your maillog, this is very likely an issue with your MTA's configuration, not dovecot.
On Tue, 16 Jun 2015 17:31:07 +0000, you wrote:
By default, most MTAs only listen to localhost, so don't accept externally derived mail. Try telnetting to port 25 on the machine from some place off your machine's network. If you get a "hang", it's likely a firewall issue. If you get a "connection refused" message it's probably that the MTA isn't listening on the external interface.
If the MTA responds, do a manual delivery exchange and see what you get.
If you're not seeing anything in your maillog, this is very likely an issue with your MTA's configuration, not dovecot.
Now that I think about and concentrate on what you wrote, make perfect sense. Add to that the fact that I received bounces from my ISP that all said the same thing: Unable to establish an SMTP connection. The return code was 4.5.1.
Am Dienstag, den 16.06.2015, 11:44 -0400 schrieb Steve Matzura:
The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
Receiving and Sending Mail is done by the MTA like postfix or exim. Not Dovecot. It's just for the IMAP/POP access by the users to get the mails. So look at that logs. And if there's nothing in it, then make sure port 25 is actually open by the postfix/exim process.
On Tue, 16 Jun 2015 22:02:29 +0200, you wrote:
Am Dienstag, den 16.06.2015, 11:44 -0400 schrieb Steve Matzura:
The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
Receiving and Sending Mail is done by the MTA like postfix or exim. Not Dovecot. It's just for the IMAP/POP access by the users to get the mails. So look at that logs. And if there's nothing in it, then make sure port 25 is actually open by the postfix/exim process.
Well, it isn't. In fact, there is no exim process running. However, something calling itself 'master' has port 25 open according to netstat, and that process has a subprocess running something called qmgr. I'd give more information, such as path to these programs, but it isn't shown. Time to check my Postfix config a little more closely.
Date: Tuesday, June 16, 2015 07:21:06 PM -0400 From: Steve Matzura number6@noisynotes.com
On Tue, 16 Jun 2015 22:02:29 +0200, you wrote:
Am Dienstag, den 16.06.2015, 11:44 -0400 schrieb Steve Matzura:
The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
Receiving and Sending Mail is done by the MTA like postfix or exim. Not Dovecot. It's just for the IMAP/POP access by the users to get the mails. So look at that logs. And if there's nothing in it, then make sure port 25 is actually open by the postfix/exim process.
Well, it isn't. In fact, there is no exim process running. However, something calling itself 'master' has port 25 open according to netstat, and that process has a subprocess running something called qmgr. I'd give more information, such as path to these programs, but it isn't shown. Time to check my Postfix config a little more closely.
Those pieces are all part of the postfix MTA (you haven't indicated your OS, but postfix is the current default on most current linux distributions).
As I indicated earlier, by default most (current) MTA installs only listen on localhost, not on the external interfaces, so don't accept off-host mail.
There is extensive postfix documentation and also a postfix mailing list if you need assistance.
On Tue, 16 Jun 2015 23:45:25 +0000, you wrote:
Those pieces are all part of the postfix MTA (you haven't indicated your OS, but postfix is the current default on most current linux distributions).
Fedora 20. Soon upgrading to 22.
As I indicated earlier, by default most (current) MTA installs only listen on localhost, not on the external interfaces, so don't accept off-host mail.
Unless I'm mistaken, which it appears that I am, I set Postfix up to receive off-host mail. I'm on the other email list, will carry this over there.
can you:
$ telnet yourhost.com 25 (obviously replacing yourhost.com with whatever your domain/ip actually is)
from the machine you are sending the mail from? If not make sure the service is running and make sure there isn't a firewall rule preventing this.
On 06/16/15 10:44, Steve Matzura wrote:
The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
On Tue, 16 Jun 2015 15:31:20 -0500, you wrote:
can you:
$ telnet yourhost.com 25 (obviously replacing yourhost.com with whatever your domain/ip actually is) from the machine you are sending the mail from? If not make sure the service is running and make sure there isn't a firewall rule preventing this.
Connect failed.
On 06/16/15 10:44, Steve Matzura wrote:
The next phase of my testing procedure involves the simple act of delivering mail to my test box. When I send a message to either a valid or relayed user at my remote machine's address, it never gets there. I know this virtually for sure because I'm tailing /var/log/maillog and nothing new has been added for the past hour. I'm thinking eventually my ISP will send the message back to me as undeliverable, and in that bounced message there may be some information about why it was undeliverable, but maybe someone has a thought as to why I'm not even seeing anything attempt to connect?
participants (5)
-
Edgar Pettijohn
-
Felix Zielcke
-
Noel
-
Richard
-
Steve Matzura