Был сервер.
На ем стоял днс и сендмейл.
Сендмейл работал как непосредственно почтовый сервер и почтовый релей
для двух офисных почтовиков.
Конфиги named(/etc/namedb) и sendmail(/etc/mail) бекапились
Сервер умер (страйп йок)
Поднял новый сервер и перенес бекапы конфигов на него.
Вроде бы все поднялось корректно.
Но при попытке отослать через этот сервер в мир письмо — вылазит ошибка
Реальный айпи сервер — *.*.*.133
Делаю тестовое мыло на гмайловский ящик с консоли
Dec 26 00:55:59 ut4 sm-mta[1886]: oBPMtxGg001884: SYSERR(root): relay1.domen.ua. config error: mail loops back to me (MX problem?)
Dec 26 00:55:59 ut4 sm-mta[1887]: oBPMtxKF001887: ut4.domen.ua [*.*.*.133] did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
Dec 26 00:55:59 ut4 sm-mta[1886]: oBPMtxGg001884: to=<maxim@pma.net.ua>, ctladdr=<maxim@domen.ua> (1008/1008), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=30346, relay=relay1.domen.ua. [*.*.*.133], dsn=5.3.5, stat=Local configuration error
Dec 26 00:55:59 ut4 sm-mta[1886]: oBPMtxGg001884: oBPMtxGg001886: DSN: Local configuration error
В конфиге зоны релей сидит на этом же айпи
IN MX 10 relay1.domen.ua.
IN MX 20 relay2.domen.ua.
......
relay1 IN A *.*.*.133
relay2 IN A *.*.*.132
конфиг resolv.conf
[root@ut4 ~]# cat /etc/resolv.conf
domain mydomen.ua
nameserver 127.0.0.1
конфиг сендмыла
[root@ut4 /etc/mail]# cat ut4.MYDOMEN.ua.mc
divert(-1)
divert(0)
VERSIONID(`2008/02/01')
OSTYPE(`freebsd6')
DOMAIN(`generic')
FEATURE(`access_db', `hash -o -T<TMPF> /etc/mail/access')
FEATURE(`blacklist_recipients')
FEATURE(`local_lmtp')
FEATURE(`smrsh')
FEATURE(`mailertable', `hash -o /etc/mail/mailertable')
FEATURE(virtusertable)
FEATURE(`use_cw_file')
define(`confCW_FILE', `-o /etc/mail/local-host-names')
DAEMON_OPTIONS(`Port=25, Name=IPv4, Family=inet')
O MaxMessageSize=11000000
FEATURE(`limited_masquerade')
FEATURE(`local_no_masquerade')
FEATURE(`masquerade_envelope')
MASQUERADE_AS(`MYDOMEN.ua')
MASQUERADE_DOMAIN(`ut4.MYDOMEN.ua')
MASQUERADE_DOMAIN(`office.MYDOMEN.ua')
define(`confBAD_RCPT_THROTTLE',`1')
define(`confMAX_RCPTS_PER_MESSAGE', `10')
define(`confRECEIVED_HEADER', `$?sfrom $s $.$?_
$.$?{auth_type}(authenticated$?{auth_ssf} bits=${auth_ssf}$.)
$.by $j ($v/$Z)$?r with $r$. id $i$?{tls_version}
(version=${tls_version} cipher=${cipher} bits=${cipher_bits} verify=${verify})$.$?u
for $u; $|;
$.$b')
define(`confDEF_USER_ID',`26:26')
define(`confMAX_MIME_HEADER_LENGTH', `256/128')
define(`confRRT_IMPLIES_DSN', `False')
define(`confBIND_OPTS', `WorkAroundBrokenAAAA')
define(`confNO_RCPT_ACTION', `add-to-undisclosed')
define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy,needmailhelo,noreceipts,noverb,noetrn,nobodyreturn')
define(`confQUEUE_SORT_ORDER', `host')dnl
define(`confTO_CONNECT', `10s')dnl
define(`confTO_ICONNECT', `10s')dnl
define(`confTO_HELLO', `10s')dnl
define(`confTO_RCPT', `20s')dnl
define(`confTO_DATAINIT', `30s')dnl
define(`confTO_DATABLOCK', `60s')dnl
define(`confTO_DATAFINAL', `30s')dnl
define(`confTO_IDENT', `0')dnl
define(`confTO_COMMAND', `30s')dnl
define(`confMAX_DAEMON_CHILDREN', 64)dnl
define(`confQUEUE_LA', `10')dnl
define(`confREFUSE_LA', `16')dnl
MAILER(`local')
MAILER(`smtp')
dnl INPUT_MAIL_FILTER(`milter-regex',`S=unix:/var/run/milter-regex/sock, T=S:30s;R:2m')
[root@ut4 /etc/mail]# cat local-host-names
mydomen.ua
ut4.mydomen.ua
[root@ut4 /etc/mail]# cat access
#
*.*.*.133 RELAY
127.0.0.1 RELAY
* REJECT
[root@ut4 /etc/mail]# hostname
ut4.domen.ua
Я не понимаю где проблема. Гугл говорит на проблемы с конфигом днс. Но ничего ж не менял — конфиги же из бекапа.
Или может быть днс поднялся некорректно?
Помогите советом пожалуйста.
I’m running some servers for some time now and everything was fine until I updated from 12.1 to 12.2.
For some reason, the automatic «daily security run output» / «daily run output» mails didn’t show up anymore then. Mail was never configured by myself but used out of the box, as it is ok to have those local mails only.
So I fiddled a little with sendmail, when mails about the delay of log-mails suddenly became delivered but not the log-mails themselves, as they couldn’t be delivered due to «Deferred: Connection refused by xxx.yyy.de.».
Trying to send mail always ends up (in /var/log/messages) with:
sm-mta[64691]: 13R95I9X064689: SYSERR(root): xxx.yyy.de. config error: mail loops back to me (MX problem?)
and in the mails about the delivery failures:
553 5.3.5 xxx.yyy.de. config error: mail loops back to me (MX problem?)
554 5.3.5 Local configuration error
The original mails never get through. And this only happens, when I restart sendmail at least once — directly after reboot, not even the mails about the failure to deliver mails appear.
So, I’m rather confused.
— For one, there is no sendmail_enable=»YES» or similar in rc.conf, but service sendmail onestatus tells me, it’s running fine:
root@is129:/etc/mail # service sendmail onestatus
sendmail is running as pid 1961.
sendmail_submit is running as pid 1961.
sendmail_msp_queue is running as pid 1964.
— There are no mail deliveries after reboot, but when I restart sendmail, notification mails about unsuccessful mail delivery appear — but never the original mails.
— I checked for differences in mail related configuration with another freebsd 12.2 server, which is running fine, but I didn’t find any.
Has anyone an idea about what might be the problem?
Thomas Mack
День добрый.
В сети есть хост, на котором поднят свой (хоста) домен, настроен DNS (A и MX) записи этого хоста, также хост прописан в hosts.
На данном хосте установлено 2 MTA (так нужно). Zimbra (postfix) крутится на 25 порту, sendmail на 26 порту.
Sendmail настроен как relay для zimbra (postfix)
При попытке отослать письмо (telnet localhost 26) на домен который держит zimbra или c zimbra переслать письмо в мир получаю такое:
Код: Выделить всё
Aug 27 13:29:15 mail sm-mta[17177]: o7RASVIb017177: from=test@mail.ru, size=29, class=0, nrcpts=1, msgid=<201008271029.o7RASVIb017177@mail.bd.local>, proto=SMTP, daemon=SendMail, relay=mail.bd.local [10.10.10.14]
Aug 27 13:29:15 mail postfix/smtpd[17773]: connect from mail.bd.local[10.10.10.14]
Aug 27 13:29:15 mail sm-mta[17772]: o7RASVIb017177: SYSERR(root): [10.10.10.14] config error: mail loops back to me (MX problem?)
Aug 27 13:29:15 mail postfix/smtpd[17773]: disconnect from mail.bd.local[10.10.10.14]
Aug 27 13:29:15 mail sm-mta[17772]: o7RASVIb017177: to=test@mail.domain.ua, delay=00:00:07, xdelay=00:00:00, mailer=relay, pri=120029, relay=[10.10.10.14] [10.10.10.14], dsn=5.3.5, stat=Local configuration error
Если указать sendmail пересылать почту не на себя (26 порт), а на тестовый комп в сети (тоже с zimbra), то все работает, почта отлично ходит в обе стороны.
Помогите пожалуйста побороть «config error: mail loops back to me (MX problem?)»
Когда делаю так » echo /mx mail.bd.local | /usr/lib/sendmail -bt «
Вроде получаю нормальный ответ:
Код: Выделить всё
echo /mx mail.bd.local | /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> getmxrr(mail.bd.local) returns 2 value(s):
mail.bd.local.
mail.bd.local.
Nslookup type=mx вроде тоже видит mx запись нормально.
Код: Выделить всё
/var/log# nslookup
> set type=mx
> mail.bd.local
Server: 127.0.0.1
Address: 127.0.0.1#53
mail.bd.local mail exchanger = 10 mail.bd.local.
Уже весь google обгрыз, не могу найти решения.
Заранее спасибо за помощь.
ITworld.com – Many systems administrators have run into errors in their syslog files that complain that mail is looping back, suggesting a possible MX problem. The common cause of this problem is that a server is receiving email for a domain that it doesn’t recognize as its own. Then, when the server looks up the MX address for the intended target (in order to send the mail on its way), it notices that the MX record is one that identifies the mail exchanger as the system itself.
Here’s an example of this type of message from the syslog file:
553 5.3.5 mail1.elsewhere.com. config error: mail loops back to me (MX problem?)
The cure for this type of problem is to configure the server to understand that it should accept mail for the particular domain. This can be done for sendmail by adding the domain to the /etc/mail/local-host-names file and restarting the sendmail service.
Recently, however, I ran into a situation in which this familiar scenario did not describe what was happening. Instead of running into «loops back to me» errors for domains for which the server should legitimately have been receiving mail, the server in question was collecting the errors for numerous unfamiliar domains. For most modern Unix servers, this issue rarely occurs because all recent versions of sendmail do not relay mail by default (i.e., they do not accept mail from outside the domain that is also destined for outside the domain). In this case, however, the server was configured to relay mail for authenticated users, so it was required to attempt delivery.
To understand why «loops back to me» errors occur, it is useful to think about the way that mail servers go about sending mail. Most email is addressed to user@domain. For example, sstocker@itworld.com. The server then needs to figure out what mail server is responsible for accepting mail for the particular domain. To do this, it requests the MX (mail exchanger) records for the domain in question. You can look up MX records yourself with nslookup or a similar tool as shown below.
> nslookup Default Server: ns1.local.com Address: 10.1.1.11 > set querytype=mx > elsewhere.com Server: ns1.local.com Address: 10.1.1.11 elsewhere.com MX preference = 20, mail exchanger = mail2.elsewhere.com elsewhere.com MX preference = 10, mail exchanger = mail1.elsewhere.com mail1.elsewhere.com internet address = 123.4.5.6 mail2.elsewhere.com internet address = 123.4.5.7 > exit
In this example, the system «mail1.elsewhere.com» is the primary mail exchanger identified for the domain elsewhere.com. The system «mail2.elsewhere.com» is a lower priority mail exchanger (with a preference of 20) and will receive mail when the higher priority server is unavailable.
Once our mail server has looked up this information on mail exchangers, it can initiate a connection with the indicated mail exchanger and send the components — sender, recipient, message contents and such — to the intended system.
In the case of the server with the «loops back to me» errors, however, there was a slight twist to this normal sequence of events. The MX record for the target domain, instead of identifying a legitimate mail server, contained the loopback address, 127.0.0.1. As a result, any mail delivery attempted for the domain would be directed back to the system trying to make the delivery. It’s as if the mail server, in Pogo-like fashion, were saying «I have identified the target system and it is me». Let’s look at a couple examples (using nslookup).
Our first example is for trib.com.
> nslookup Default Server: ns1.local.com Address: 10.1.1.11 > set querytype=mx > trib.com Default Server: ns1.local.com Address: 10.1.1.11 Non-authoritative answer: trib.com MX preference = 10, mail exchanger = mail.trib.com mail.trib.com internet address = 127.0.0.1
Notice that the mail exchanger is set to mail.trib.com and the IP address provided for trib.com is the loopback — 127.0.0.1. Continuing in nslookup, we see the same configuration being used for the domain version.net below:
> version.net Default Server: ns1.local.com Address: 10.1.1.11 Non-authoritative answer: version.net MX preference = 3, mail exchanger = mail.version.net mail.version.net internet address = 127.0.0.1 > exit
The «loops back to me» errors would likely appear in your syslog file (depending, of course on the configuration of your /etc/syslog.conf file) and rejected mail will probably end up in the inbox of whichever user is assigned the role of postmaster.
While it’s relatively easy to repair configuration problems on your mail server — such as when you need to configure an additional domain that you should be accepting mail for, there’s absolutely nothing that you can do to change the configuration on other organizations’ mail servers.
You’ll get the same result if someone sends mail directly to a particular host (as opposed to sending it to the domain), such as mail1.elsewhere.com whose hostname is set to the loopback. For example, if you were to try to send mail to the host, localhost.fabulous.com, your server would look up the IP address of the intended system and find out that it’s set to 127.0.0.1. Again, we find ourselves with an address that simply points back to the local server.
Can you use this trick yourself? Well, yes. If you want to set up a domain or a single system to which mail cannot be sent (at least not without knowing its public IP address), this is one way to accomplish the task. However, in next week’s column, we’ll examine a more elegant way to refuse mail on a single system.
This story, «Unix Tip: Mail loops back to me» was originally published by
ITworld.
Sandra Henry-Stocker has been administering Unix systems for more than 30 years. She describes herself as «USL» (Unix as a second language) but remembers enough English to write books and buy groceries. She lives in the mountains in Virginia where, when not working with or writing about Unix, she’s chasing the bears away from her bird feeders.
Copyright © 2007 IDG Communications, Inc.
-
- Forums
-
- Advancing Life & Work
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Latin America
- HPE Blog, Poland
- HPE Blog, Hungary
- HPE Blog, UK, Ireland, Middle East & Africa
- Blogs
- Information
-
Forums
-
Blogs
- Advancing Life & Work
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Latin America
- HPE Blog, UK, Ireland, Middle East & Africa
- HPE Blog, Poland
- HPE Blog, Hungary
-
Information
-
English
Hi,
I am getting the below messsage in /var/adm/message after patching but sendmail is working after restoring the old configuration file.
sendmail[14775]: [ID 801593 mail.crit] q4G7U1Cj014774: SYSERR(root): 127.0.0.1 config error: mail loops back to me (MX problem?)
sendmail[25828]: [ID 801593 mail.crit] q4G801cw025824: SYSERR(root): 127.0.0.1 config error: mail loops back to me (MX problem?)
sendmail[5196]: [ID 801593 mail.crit] q4G8U1YQ005195: SYSERR(root): 127.0.0.1 config error: mail loops back to me (MX problem?)
Thanks.
Read these next…
Green Brand Rep Wrap-Up: January 2023
Spiceworks Originals
Hi, y’all — Chad here. A while back, we used to feature the top posts from our brand reps (aka “Green Gals/Guys/et. al.) in a weekly or monthly wrap-up post. I can’t specifically recall which, as that was approximately eleven timelines ago. Luckily, our t…
Help with domain controller setup
Windows
I just got a new job as the only IT person for a business with around 270 employees (I would say probably less than half use computers) They don’t have any policies or procedures when it comes to IT, as they have never had an IT person. My background cons…
Malicious URLs
Security
We have firewall, we have endpoint protection, we have Safe links and Attachments for Office 365 (Microsoft Defense for Office 365 Plan 1), and still receiving links that lead to malicious web sites.It seems like security companies still didn’t develop a …
Snap! — Old Batteries, Lovable Bots, Quantum Breakthrough, Should We Trust AI?
Spiceworks Originals
Your daily dose of tech news, in brief.
Welcome to the Snap!
Flashback: February 8, 1996: The massive Internet collaboration “24 Hours in Cyberspace” takes place (Read more HERE.)
Bonus Flashback: February 8, 1974: Americans end outer spa…
Large collection of Mac Minis
Best Practices & General IT
We are getting rid of a lot of older equipment that doesn’t have a purpose anymore on our campus. Most of it is 2010 and 2014 Mac Minis. When they were purchased, they were the absolute base model, so nothing special about them. I’ve reached out to multip…