la, 2010-10-30 kello 15:56 -0600, Frank Cox kirjoitti:
On Sun, 2010-10-31 at 01:44 +0400, Hiisi wrote:
However it's impossible to send messages from this machine to the outside world.
because
My ISP rejects all outgoing connections to port 25 except to their own smtp-server (smtp.direct.ru).
Hi, Frank! In the provided sendmail.mc file there's an option: define(`SMART_HOST', `smtp.direct.ru')dnl I thought it relays all my outgoing mail to ISP smtp server. Or am I wrong here? -- Reading is to the mind what exercise is to the body.
On 10/30/2010 06:16 PM, Hiisi Troll wrote:
In the provided sendmail.mc file there's an option: define(`SMART_HOST', `smtp.direct.ru')dnl I thought it relays all my outgoing mail to ISP smtp server. Or am I wrong here?
Try putting the smtp machine name between square brackets:
define(`SMART_HOST', `[smtp.direct.ru]')dnl
there is something about the square brackets and its use to either use or keep sendmail from using the MX or an A record instead for the listed host (sorry, I can't remember the details, only that it works!). I use it (the square brackets) for my ISP's smtp server and I can send email out through it.
On Sun, 2010-10-31 at 02:16 +0400, Hiisi Troll wrote:
In the provided sendmail.mc file there's an option: define(`SMART_HOST', `smtp.direct.ru')dnl I thought it relays all my outgoing mail to ISP smtp server. Or am I wrong here?
The smart host would be the name of the ISP's mail server. If that's correct, then you should be able to send mail via your own SMTP server, to the ISP's SMTP server, then out to the real world. Just the same as if you'd emailed directly through the ISP's SMTP server.
However, you will need to be sending *from* an address that's real to the outside world. i.e. One that anyone in the world would be able to write to, and you receive it. In as much as the domain name has to be real, and have a public IP. Either, because you wrote the message with such a "from address," or your SMTP server masquerades all outgoing mail with such a domain name in the from address.
Those are the basics, further restrictions may apply depending on how other parties do their anti-spam protections.
If I were to try to post to one of your samples, root@kello.ru my system (or another's) would be trying to work out the following:
Find the MX record for kello.ru
dig kello.ru MX ;; ANSWER SECTION: kello.ru. 86400 IN MX 10 mail.kello.ru.
So far, so good. Now, we'll have to find the IP address for mail.kello.ru, to make a connection.
dig mail.kello.ru ;; ANSWER SECTION: mail.kello.ru. 86307 IN A 212.16.23.132
Now, if that's the correct IP address, then DNS records for your tests should be all fine, and it's another problem that needs resolving. The very basics of email check out.
Here's just one thing that might be a problem: Let's try finding the domain name for that IP, as a reverse look-up, as is typically done by various mail servers as part being careful.
dig -x 212.16.23.132
And there is no answer. None at all, not even a different domain name (as is commonly the case, when you share IPs with other people). In some cases, because that's a check that many others will do, it will mean "no mail for you!" This can be a problem for, both, incoming and outgoing mail.
And if you'd Google searched "451 DNS temporary failure" as in your first posting's error message:
"stat=Deferred: 451 DNS temporary failure"
You would have found this about two down from the top returned pages:
"SMTP Service Info 23 Feb 2004 ... 451 Bad reverse DNS: This is a temporary failure indicating that you are attempting to connect from a host that does not have reverse DNS. ...
If you cannot set your own reverse DNS, you'll have to ask your ISP (or mail host) to set it for you. If they cannot, you're stuck.
Another problem with trying to send or receive mail from the outside world will depend upon what numerical IPs you have. If it's within the range of addresses handed out by an ISP to their clients, particularly a dynamic address, though still applicable to static address customers, then many other people will not be able to post to you, because their SMTP servers will refuse to make direct connections to customer IPs.
Then there's plain old internet racism - you have a .ru top level domain name in your address. Some will blackban that, just for the sake of it. Though, if you're doing local tests, I kind of doubt that other nearby neighbours would be doing that sort of banning.
su, 2010-10-31 kello 17:47 +1030, Tim kirjoitti: <--SNIP-->
If you cannot set your own reverse DNS, you'll have to ask your ISP (or mail host) to set it for you. If they cannot, you're stuck.
<--SNIP-->
Thank you for clarification, Tim! Your responses are always explain the basics of the underlying problem. I've contacted my ISP and domain name provider. They both couldn't find anything wrong in my configuration. I've changed SMART_HOST option in sendmail.mc to bracketed version. Despite it didn't helped immediately, the problem is gone now. I don't know what caused it because neither me nor ISP people did nothing to it at that moment. Strangely, mail queue released and all letters hit the rcpt to address. Probably the culprit is ISP' smtp-server, but I'm not sure here. Now everything work flawlessly and I'm pretty happy with it. As usual, this list is a grate source of quick help. Thanks to everybody.
On Sun, 2010-10-31 at 17:42 +0300, Hiisi wrote:
Despite it didn't helped immediately, the problem is gone now. I don't know what caused it because neither me nor ISP people did nothing to it at that moment. Strangely, mail queue released and all letters hit the rcpt to address.
Well, the error message said "temporary" failure, with a "deferred" status of the queue. Once the problem goes away, it can retry. Or may just keep retrying, anyway.
The obvious question occurs: Had you restarted the mailserver during these tests? You usually have to restart servers when you make configuration changes, and sometimes when networks go up and down.
I still don't get an answer if I try a reverse lookup on the IP. Perhaps other servers can do it (i.e. the record's there, but hasn't appeared in the servers that I'm querying).
On Saturday, October 30, 2010 22:30:40 Kevin J. Cummings wrote:
On 10/30/2010 06:16 PM, Hiisi Troll wrote:
In the provided sendmail.mc file there's an option: define(`SMART_HOST', `smtp.direct.ru')dnl I thought it relays all my outgoing mail to ISP smtp server. Or am I wrong here?
Try putting the smtp machine name between square brackets:
define(`SMART_HOST', `[smtp.direct.ru]')dnl
there is something about the square brackets and its use to either use or keep sendmail from using the MX or an A record instead for the listed host (sorry, I can't remember the details, only that it works!). I use it (the square brackets) for my ISP's smtp server and I can send email out through it.
The meaning of SMART_HOST is the *MX* host for the name. In other words, sendmail will look up the MX record for smtp.direct.ru to find out what host to connect to.
The MX record *could* specify another host -- not smtp.direct.ru . (In this case, there is no MX record for smtp.direct.ru so its A record will be used, which is what you want.) My ISP's relay host does specify a different host for its MX. That host refuses relay from my IP address.
To specify a host address instead of the MX host for a domain, place the host address inside of square brackets as Kevin states above. Now even if an MX record someday shows up for that domain name (smtp.direct.ru), its A record will still be used.
ma, 2010-11-01 kello 01:54 +1030, Tim kirjoitti:
Well, the error message said "temporary" failure, with a "deferred" status of the queue. Once the problem goes away, it can retry. Or may just keep retrying, anyway.
The obvious question occurs: Had you restarted the mailserver during these tests? You usually have to restart servers when you make configuration changes, and sometimes when networks go up and down.
Of course I did. And after changing to sendmail.mc I did make in mail directory before restarting the service.
I still don't get an answer if I try a reverse lookup on the IP. Perhaps other servers can do it (i.e. the record's there, but hasn't appeared in the servers that I'm querying).
The strange thing is that me too can't get an answer to reverse name resolution. Anyway, while it works I'll apply that old good method: if it works don't fix it! Thanks again.
-
Garry Williams -
Hiisi -
Kevin Cummings -
Tim