» Все о MDaemon (#5)

Добрый день. Мне требуется ваша помощь.
Я использую внутри MDaemon Securty Plus v3.5. И тут у меня возникла проблема.
База антивируса не обновляется, хотя я поменял ключ и у нас в запасе 730 дней. В приложенных скриншотах это видно. Что вы можете посоветовать в этой ситуации? Как решить эту проблему?

Всего хорошего.

-------------------------------------------------------------------------------
MDaemon Server:

SMTP/POP/IMAP server: v9.6.2
WorldClient HTTP server: v9.6.2
WorldClient DLL: v9.6.2
ComAgent client: v9.6.2
Content filter server: v9.6.2
Content filter DLL: v9.6.2
Content filter GUI: v9.6.2
-------------------------------------------------------------------------------
SecurityPlus for MDaemon:

AV overall system: v3.0.5
AV engine source: Alt-N Technologies, Ltd
AV known viruses: 29946940
AV last virus update: 19997624/-1/19974624
Outbreak Protection (MDOP.dll): v1.2.0
RPD and Zero-Hour (ASAPSDK.dll): v5.3.0.14
-------------------------------------------------------------------------------


[img] [/img]

[img] [/img]

[img] [/img]

hasanovi Может проще наплевать на Securty Plus v3.0.5 и поставить 4.1.2 ? В нем правда есть один глюк, но он устраняется, как именно - написано в шапке - Устранение ошибки 'Could not initialize KLAV!' для SecurityPlus 4.1.x , инструкция от ALTN.

У меня MDaemon Server: SMTP/POP/IMAP server: v9.6.2

Новая версия Securty Plus v4.1.2 будет работать?

Не будет конфликт?

hasanovi http://www.altn.com/Products/SecurityPlus-Antivirus-MDaemon/SystemRequirements/
MDaemon 9.5 or greater
Оказывается уже есть SecurityPlus is 4.1.3, так что можно ставить сразу ее, качать отсюда
http://www.altn.com/Downloads/FreeEvaluation/#SecurityPlus
4.1.2 отсюда - http://archive.altn.com/antivirus/Archive/4.1.2/

Добрый день. подскажите почему не доходят два следующих письма... кидаю логи

Thu 2012-01-12 09:25:47: ----------
Thu 2012-01-12 09:25:49: [8017:2] Session 8017; child 2; thread 4936
Thu 2012-01-12 09:25:49: [8017:2] Принимаю SMTP подключение от [129.9.40.25:60505]
Thu 2012-01-12 09:25:49: [8017:2] Performing PTR lookup (25.40.9.129.IN-ADDR.ARPA)
Thu 2012-01-12 09:25:49: [8017:2] * D=25.40.9.129.in-addr.arpa TTL=(60) PTR=[odbmap01.out.extra.chrysler.com]
Thu 2012-01-12 09:25:49: [8017:2] * Gathering A records...
Thu 2012-01-12 09:25:49: [8017:2] * D=odbmap01.out.extra.chrysler.com TTL=(60) A=[129.9.40.25]
Thu 2012-01-12 09:25:49: [8017:2] ---- End PTR results
Thu 2012-01-12 09:25:49: [8017:2] --> 220 ai.ryazan.ru ESMTP MDaemon 9.6.4; Thu, 12 Jan 2012 09:25:49 +0400
Thu 2012-01-12 09:25:49: [8017:2] <-- EHLO odbmap01.extra.chrysler.com
Thu 2012-01-12 09:25:49: [8017:2] Performing IP lookup (odbmap01.extra.chrysler.com)
Thu 2012-01-12 09:25:49: [8017:2] * D=odbmap01.extra.chrysler.com TTL=(14) A=[129.9.40.24]
Thu 2012-01-12 09:25:49: [8017:2] ---- End IP lookup results
Thu 2012-01-12 09:25:49: [8017:2] --> 501 This server will not accept forged credentials; you are not 'odbmap01.extra.chrysler.com'
Thu 2012-01-12 09:25:49: [8017:2] SMTP сессия отменена (Байт принято/передано: 34/166)
Thu 2012-01-12 09:25:49: ----------

и второе....

Fri 2012-01-13 00:37:54: ----------
Fri 2012-01-13 00:39:33: [7712:1] Session 7712; child 1; thread 5356
Fri 2012-01-13 00:39:30: [7712:1] Принимаю SMTP подключение от [194.114.62.76:61196]
Fri 2012-01-13 00:39:30: [7712:1] Performing PTR lookup (76.62.114.194.IN-ADDR.ARPA)
Fri 2012-01-13 00:39:30: [7712:1] * D=76.62.114.194.IN-ADDR.ARPA TTL=(258) PTR=[mr2.volkswagen.de]
Fri 2012-01-13 00:39:30: [7712:1] * Gathering A records...
Fri 2012-01-13 00:39:30: [7712:1] * D=mr2.volkswagen.de TTL=(4) A=[194.114.62.76]
Fri 2012-01-13 00:39:30: [7712:1] ---- End PTR results
Fri 2012-01-13 00:39:30: [7712:1] --> 220 ai.ryazan.ru ESMTP MDaemon 9.6.4; Fri, 13 Jan 2012 00:39:30 +0400
Fri 2012-01-13 00:39:30: [7712:1] <-- EHLO mr2.volkswagen.de
Fri 2012-01-13 00:39:30: [7712:1] Performing IP lookup (mr2.volkswagen.de)
Fri 2012-01-13 00:39:30: [7712:1] * D=mr2.volkswagen.de TTL=(4) A=[194.114.62.76]
Fri 2012-01-13 00:39:30: [7712:1] ---- End IP lookup results
Fri 2012-01-13 00:39:30: [7712:1] EHLO/HELO response delayed 1 seconds
Fri 2012-01-13 00:39:31: [7712:1] --> 250-ai.ryazan.ru Hello mr2.volkswagen.de, pleased to meet you
Fri 2012-01-13 00:39:31: [7712:1] --> 250-ETRN
Fri 2012-01-13 00:39:31: [7712:1] --> 250-AUTH=LOGIN
Fri 2012-01-13 00:39:31: [7712:1] --> 250-AUTH LOGIN CRAM-MD5
Fri 2012-01-13 00:39:31: [7712:1] --> 250-8BITMIME
Fri 2012-01-13 00:39:31: [7712:1] --> 250 SIZE 30000000
Fri 2012-01-13 00:39:32: [7712:1] <-- MAIL FROM:<autopart@volkswagen.ru> SIZE=3165
Fri 2012-01-13 00:39:32: [7712:1] Performing IP lookup (volkswagen.ru)
Fri 2012-01-13 00:39:32: [7712:1] * D=volkswagen.ru TTL=(671) A=[89.111.188.208]
Fri 2012-01-13 00:39:32: [7712:1] * P=010 S=000 D=volkswagen.ru TTL=(11) MX=[mail.volkswagen.ru] {62.105.137.68}
Fri 2012-01-13 00:39:32: [7712:1] ---- End IP lookup results
Fri 2012-01-13 00:39:32: [7712:1] Performing SPF lookup (volkswagen.ru / 194.114.62.76)
Fri 2012-01-13 00:39:32: [7712:1] * Result: none; no SPF record in DNS
Fri 2012-01-13 00:39:32: [7712:1] ---- End SPF results
Fri 2012-01-13 00:39:32: [7712:1] --> 250 <autopart@volkswagen.ru>, Sender ok
Fri 2012-01-13 00:39:32: [7712:1] <-- RCPT TO:<autopart@chehia-avto.ru>
Fri 2012-01-13 00:39:32: [7712:1] Производится поиск DNS-BL (194.114.62.76 – соединение с IP)
Fri 2012-01-13 00:39:32: [7712:1] * cbl.abuseat.org - прошло
Fri 2012-01-13 00:39:32: [7712:1] * bl.spamcop.net - прошло
Fri 2012-01-13 00:39:32: [7712:1] * sbl-xbl.spamhaus.org - прошло
Fri 2012-01-13 00:39:32: [7712:1] * zen.spamhaus.org - прошло
Fri 2012-01-13 00:39:33: [7712:1] * smtp.dnsbl.sorbs.net - прошло
Fri 2012-01-13 00:39:33: [7712:1] * combined.njabl.org - прошло
Fri 2012-01-13 00:39:33: [7712:1] ---- Конечные результаты DNS-BL
Fri 2012-01-13 00:39:33: [7712:1] --> 250 <autopart@chehia-avto.ru>, Recipient ok
Fri 2012-01-13 00:39:33: [7712:1] <-- DATA
Fri 2012-01-13 00:39:33: [7712:1] Creating temp file (SMTP): c:\mdaemon\queues\temp\md50000241881.tmp
Fri 2012-01-13 00:39:33: [7712:1] --> 354 Enter mail, end with <CRLF>.<CRLF>
Fri 2012-01-13 00:39:33: [7712:1] Message size: 2142 bytes
Fri 2012-01-13 00:39:33: [7712:1] Performing DomainKeys lookup (Sender: autopart@volkswagen.ru)
Fri 2012-01-13 00:39:33: [7712:1] * File: c:\mdaemon\queues\temp\md50000241881.tmp
Fri 2012-01-13 00:39:33: [7712:1] * Message-ID: VWRUMOSN000001YX1oH0000d334@VWRUMOSX000001.vw.vwg
Fri 2012-01-13 00:39:33: [7712:1] * Querying for policy: volkswagen.ru
Fri 2012-01-13 00:39:33: [7712:1] * Querying: _domainkey.volkswagen.ru ...
Fri 2012-01-13 00:39:33: [7712:1] * DNS: * Сервер имен сообщает, что имя домена не опознано
Fri 2012-01-13 00:39:33: [7712:1] * Result: neutral
Fri 2012-01-13 00:39:33: [7712:1] ---- End DomainKeys results
Fri 2012-01-13 00:39:33: [7712:1] Performing Sender ID lookup (volkswagen.ru / 194.114.62.76)
Fri 2012-01-13 00:39:33: [7712:1] * Result: none; no SPF record in DNS
Fri 2012-01-13 00:39:33: [7712:1] ---- End Sender ID results
Fri 2012-01-13 00:39:33: [7712:1] Passing message through AntiVirus (Size: 2142)...
Fri 2012-01-13 00:39:33: [7712:1] * Сообщение чистое (вирусов не обнаружено)
Fri 2012-01-13 00:39:33: [7712:1] ---- End AntiVirus results
Fri 2012-01-13 00:39:33: [7712:1] Passing message through Spam Filter (Size: 2142)...
Fri 2012-01-13 00:39:33: [7712:1] * 1.0 NO_REAL_NAME From: does not include a real name
Fri 2012-01-13 00:39:33: [7712:1] * 1.7 SUBJECT_ENCODED_TWICE Subject: MIME encoded twice
Fri 2012-01-13 00:39:33: [7712:1] * 2.2 INVALID_DATE Invalid Date: header (not RFC 2822)
Fri 2012-01-13 00:39:33: [7712:1] * 3.1 BAD_ENC_HEADER Message has bad MIME encoding in the header
Fri 2012-01-13 00:39:33: [7712:1] * 0.2 SUBJ_HAS_UNIQ_ID Subject contains a unique ID
Fri 2012-01-13 00:39:33: [7712:1] * 2.0 DATE_IN_FUTURE_03_06 Date: is 3 to 6 hours after Received: date
Fri 2012-01-13 00:39:33: [7712:1] * -4.7 BAYES_00 BODY: Bayesian spam probability is 0 to 1%
Fri 2012-01-13 00:39:33: [7712:1] * [score: 0.0000]
Fri 2012-01-13 00:39:33: [7712:1] * 0.0 SUBJECT_EXCESS_QP Subject: quoted-printable encoded unnecessarily
Fri 2012-01-13 00:39:33: [7712:1] ---- End SpamAssassin results
Fri 2012-01-13 00:39:33: [7712:1] Spam Filter score/req: 5.40/12.0
Fri 2012-01-13 00:39:33: [7712:1] Создание сообщения successful: c:\mdaemon\queues\inbound\md50001033577.msg
Fri 2012-01-13 00:39:33: [7712:1] --> 250 Ok, message saved <Message-ID: VWRUMOSN000001YX1oH0000d334@VWRUMOSX000001.vw.vwg>
Fri 2012-01-13 00:39:33: [7712:1] <-- QUIT
Fri 2012-01-13 00:39:33: [7712:1] --> 221 See ya in cyberspace
Fri 2012-01-13 00:39:33: [7712:1] SMTP сессия успешна (Байт принято/передано: 2262/457)
Fri 2012-01-13 00:39:33: ----------

xXxJurneoxXx
Цитата:

подскажите почему не доходят два следующих письма...

Ну, судя по логам, второе должно было дойти. Если его SpamAssassin куда-нибудь в чулан не засунул.
А с первым все понятно. Клиент [129.9.40.25] поздоровался EHLO odbmap01.extra.chrysler.com. Сервер проверил EHLO, и получил айпи не 129.9.40.25, а 129.9.40.24. Поэтому сервер клиента отшил. Если тебя такое не устраивает, ищи в настройках что-то типа "verify HELO" и снимай эту галку.

xXxJurneoxXx vlary прав, во втором логе письмо твоим сервером принято, если клиент его якобы не получил, то смотри почту у клиента, возможно попала в Нежелательную почту, если клиент микрософт аутлук. По-первому логу нарушение тем сервером RFC 1912 2.1, для почтовиков имя в прямой и обратной зоне должно совпадать, чего в данном случае не наблюдается:
- коннект идет с ip 129.9.40.25
- mdaemon делает запрос на запись с типом А для этого айпи и получает имя odbmap01.out.extra.chrysler.com
- mdaemon делает запрос на IP на это имя nslookup odbmap01.out.extra.chrysler.com
и получает IP - 129.9.40.24
129.9.40.24 не равно 129.9.40.25 - нарушение RFC 1912 2.1 - имеет полное право брить, что он и делает!
Или отключай проверку PTR или плюй на этот почтовик нарушающий RFC. Если этот почтовик очень важен для вас, то заноси его в белый список Reverse lookup в демоне, но лучше пнуть того админа за его нерадивость, отслав инфу на емайл клиента или на postmaster.

да первый я пробил по nslookup. попробую добавить в исключения. а со вторым не понятно, вроде бы сессия успешна, а письма нет... клиент TheBat.

xXxJurneoxXx по твоему логу втрое письмо твоим сервером принято, куда его дел клиент the bat - вопрос не сюда. Можно отследить это письмо по логам демона ALL, ROUTING и в редких случаях RAW - всё ищется по ID письма, еще частично по примерному размеру входящего письма на примерное это же время отследить лог POP3 на того клиента. По моему опыту, в 98% случаев клиент письмо по pop3 получал, но якобы его не видел в почте.
Советую поглядеть лог POP на время +- 15-30 минут на того юзера (зависитт от того каокй у него стоит интервал проверки) и на размер письма 2262 +- 60 байт

Доброго времени суток.

Проблема возникла. MDaemon вроде бы письма принимает, во временной папке они мелькают - а в инбоксы не садятся. Отправляет исправно. Подскажите, пожалуйста, где копать

Вот лог последней входящей сессии.

Mon 2012-01-16 14:50:34: Session 151; child 1
Mon 2012-01-16 14:50:34: Accepting SMTP connection from [209.85.214.180:51655] to [*.*.*.*:25]
Mon 2012-01-16 14:50:34: --> 220 *.org ESMTP MDaemon 12.5.0; Mon, 16 Jan 2012 14:50:34 +0400
Mon 2012-01-16 14:50:34: <-- EHLO mail-tul01m020-f180.google.com
Mon 2012-01-16 14:50:34: --> 250-*.org Hello mail-tul01m020-f180.google.com, pleased to meet you
Mon 2012-01-16 14:50:34: --> 250-ETRN
Mon 2012-01-16 14:50:34: --> 250-AUTH LOGIN CRAM-MD5 PLAIN
Mon 2012-01-16 14:50:34: --> 250-8BITMIME
Mon 2012-01-16 14:50:34: --> 250 SIZE
Mon 2012-01-16 14:50:34: <-- MAIL FROM:<*@*.ws>
Mon 2012-01-16 14:50:34: Performing PTR lookup (180.214.85.209.IN-ADDR.ARPA)
Mon 2012-01-16 14:50:34: * D=180.214.85.209.IN-ADDR.ARPA TTL=(1414) PTR=[mail-tul01m020-f180.google.com]
Mon 2012-01-16 14:50:34: * Gathering A records...
Mon 2012-01-16 14:50:34: * D=mail-tul01m020-f180.google.com TTL=(1414) A=[209.85.214.180]
Mon 2012-01-16 14:50:34: ---- End PTR results
Mon 2012-01-16 14:50:34: Performing IP lookup (mail-tul01m020-f180.google.com)
Mon 2012-01-16 14:50:34: * D=mail-tul01m020-f180.google.com TTL=(1414) A=[209.85.214.180]
Mon 2012-01-16 14:50:34: ---- End IP lookup results
Mon 2012-01-16 14:50:34: Performing IP lookup (*.ws)
Mon 2012-01-16 14:50:34: * D=*.ws TTL=(22) A=[184.168.62.1]
Mon 2012-01-16 14:50:34: * P=010 S=003 D=*.ws TTL=(1409) MX=[aspmx.l.google.com] {74.125.79.27}
Mon 2012-01-16 14:50:34: * P=020 S=004 D=*.ws TTL=(1409) MX=[alt1.aspmx.l.google.com]
Mon 2012-01-16 14:50:34: * P=030 S=000 D=*.ws TTL=(1409) MX=[alt2.aspmx.l.google.com]
Mon 2012-01-16 14:50:34: * P=040 S=001 D=*.ws TTL=(1409) MX=[aspmx2.googlemail.com] {74.125.43.27}
Mon 2012-01-16 14:50:34: * P=050 S=002 D=*.ws TTL=(1409) MX=[aspmx3.googlemail.com] {74.125.127.27}
Mon 2012-01-16 14:50:34: * D=*.ws TTL=(22) A=[184.168.62.1]
Mon 2012-01-16 14:50:34: * D=*.ws TTL=(22) A=[184.168.62.1]
Mon 2012-01-16 14:50:34: ---- End IP lookup results
Mon 2012-01-16 14:50:34: Performing SPF lookup (*.ws / 209.85.214.180)
Mon 2012-01-16 14:50:34: * Result: none; no SPF record in DNS
Mon 2012-01-16 14:50:34: ---- End SPF results
Mon 2012-01-16 14:50:34: --> 250 <*@*.ws>, Sender ok
Mon 2012-01-16 14:50:35: <-- RCPT TO:<*@*.org>
Mon 2012-01-16 14:50:35: --> 250 <*@*.org>, Recipient ok
Mon 2012-01-16 14:50:35: <-- DATA
Mon 2012-01-16 14:50:35: Creating temp file (SMTP): e:\mdaemon\temp\md50000000195.tmp
Mon 2012-01-16 14:50:35: --> 354 Enter mail, end with <CRLF>.<CRLF>
Mon 2012-01-16 14:50:35: Message size: 903 bytes
Mon 2012-01-16 14:50:35: Performing DKIM lookup
Mon 2012-01-16 14:50:35: * File: e:\mdaemon\temp\md50000000195.tmp
Mon 2012-01-16 14:50:35: * Message-ID: CAAnLVG16iih-cEySv-yXcQCGDxML_V+o5_JC9ZD31zz8fZMCuw@mail.gmail.com
Mon 2012-01-16 14:50:35: * Result: neutral
Mon 2012-01-16 14:50:35: ---- End DKIM results
Mon 2012-01-16 14:50:35: Performing DomainKeys lookup (Sender: *@*.ws)
Mon 2012-01-16 14:50:35: * File: e:\mdaemon\temp\md50000000195.tmp
Mon 2012-01-16 14:50:35: * Message-ID: CAAnLVG16iih-cEySv-yXcQCGDxML_V+o5_JC9ZD31zz8fZMCuw@mail.gmail.com
Mon 2012-01-16 14:50:35: * Querying for policy: *.ws
Mon 2012-01-16 14:50:35: * Querying: _domainkey.*.ws ...
Mon 2012-01-16 14:50:35: * DNS: * Name server reports domain name unknown
Mon 2012-01-16 14:50:35: * Result: neutral
Mon 2012-01-16 14:50:35: ---- End DomainKeys results
Mon 2012-01-16 14:50:36: Message creation successful: e:\mdaemon\inbound\md50000005827.msg
Mon 2012-01-16 14:50:36: --> 250 Ok, message saved <Message-ID: CAAnLVG16iih-cEySv-yXcQCGDxML_V+o5_JC9ZD31zz8fZMCuw@mail.gmail.com>
Mon 2012-01-16 14:51:06: <-- QUIT
Mon 2012-01-16 14:51:06: --> 221 See ya in cyberspace
Mon 2012-01-16 14:51:06: SMTP session successful (Bytes in/out: 1028/471)

diabolitto
смотри лог all а не smtp-in
там после лога сессии приёма идет подробных разбор что с письмом происходит дальше.

Да уж... Локальные сессии были заморожены :'-((( Отморозились о пошли Глупость - эт трагедия для всех окружающих её носителя

Добрый день
Мдаемон не отвечает корректно на HELO

с локалки всё нормально:
220 domen.by ESMTP MDaemon 12.0.3; Mon, 16 Jan 2012 15:22:29 +0300
HELO Domen.com
250 domen.by Hello domen.com, pleased to meet you


А с внешнего IP (есть только один)
220*************************
helo domen.com
500 What? I don't understand that.


Почта с mail.ru и большинства почтовых серверов нормально доходит.
Кто рубит? в логах на даймоне Domen.com заменяется иксами(ХХХХХХ)
Что может мешать?

MKaptsevich
скорее всего был нечитаемый символ в этом helo
П.С. написание helo маленькими буквами не запрещается, но не используется нормальными почтовыми серверами. Рискну предположить что с вероятностью 99.9% эта сессия - от спамерского бот-софта. Тогда и то что в строке приветствия был нечитаемый символ - наиболее вероятно. Иными словами - на такие сессии можно смело забивать.
П.П.С. почти все нормальные сервера вовсе не используют сейчас HELO, а используют расширенный EHLO

MKaptsevich если заменяется иксами, то и приводи кусок лога лог с этими иксами полностью.

Удалось воспроизвести с домашнего компа. Итого:

telnet c локальной сети:

220 domen.by ESMTP MDaemon 12.0.3; Mon, 16 Jan 2012 15:22:29 +0300
HELO Domen.com
250 domen.by Hello domen.com, pleased to meet you

telnet c домашнего:
220 ******************************************************************
HELO domen.com
500 What? I don't understand that.

и лог на сервере подключения с дома:
Session 3000; child 1
Tue 2012-01-17 08:55:21: Accepting SMTP connection from [93.125.13.214:1090] to [zzz.zzz.zzz.zzz:25]
Tue 2012-01-17 08:55:21: --> domen.by ESMTP MDaemon 12.0.3; Tue, 17 Jan 2012 08:55:21 +0300
Tue 2012-01-17 08:55:29: <-- XXXX XXXXXXXXX
Tue 2012-01-17 08:55:29: --> 500 What? I don't understand that.
Tue 2012-01-17 08:55:30: <--
Tue 2012-01-17 08:55:30: --> 500 What? I don't understand that.
Tue 2012-01-17 08:55:30: <--
Tue 2012-01-17 08:55:30: --> 500 What? I don't understand that.
Tue 2012-01-17 08:55:31: <--
Tue 2012-01-17 08:55:31: Обнаружено слишком много ошибок
Tue 2012-01-17 08:55:31: SMTP session terminated

Записи в логе для mail.ru и др. полностью вменяемые. Почта ходит со всего мира...

Но есть сервак наших партнеров, с чего всё и началось. Их админ получает 500 What? I don't understand that. И вполне обоснованно кивает на нас Почту от них не получаем.

И почему звёздочки в телнете с дома?

MKaptsevich
Цитата:

<-- XXXX XXXXXXXXX

Блин, шифратор ты наш! Твой почтовый сервер знает весь интернет, а там, где ты ищешь помощи, пишешь всякую XXXXю?
При таком подходе тебе помогут только здесь: Клуб телепатов

vlary
Я ж писал выше... в логах на даймоне Domen.com заменяется иксами
<-- XXXX XXXXXXXXX - это в логе сервера я ничего не менял.
И это только для подключения с ОДНОЙ дружественной организации и как оказалось для моего дом компа

vlary
ты кажется просто не очень понял суть его проблемы.
похоже он не "шифрует", а его мдемон действительно из его дома получает кривые символы и транслирует их в XX...


MKaptsevich
вероятно дома чтото вмешивается в поток траффика и преобразует и до мдемона доходят косяки. Возможно какой то потоковый файрвол на домашнем компе вмешивается в траффик SMTP или даже оборудование провайдера домашнего интернета.
Такое вполне возможно, т.к. провайдеры часто обязывают своих домашних клиентов для отправки почты юзать исключительно свой smtp-сервер, обрубая или преобразую каким либо образом smtp-трафикдо любых других smtp в интернете.

Вариант - не тестировать smtp-подключение с домашнего компа (оно в общем то особо и не нужно какбе)
Ведь со всех остальных внешних почтовиков (типа тогоже майл.ру, гугломайл) на мдемон почтовые сессии приходят же нормально.

Итого:
1. Сам MDaemon не причем.
2. Скорее всего оборудование наше или дружественной организации вмешивается в поток SMTP трафика и косячит.
3. Возможно это оборудование провайдера.

Но как проверить? или доказать? Уходить в глухую защиту говоря "Это у вас проблемы у меня всё работает" не очень красиво...

MKaptsevich
для прояснения ситуации нужно накопить статистику.
т.е. смотреть на остальные входящие сессии мдемона в логах на предмет похожих ситуаций. Скорее всего такое поведение будет наблюдаться только при коннектах из дома.
Однако отмечу что иногда похожие "проблемные сессии" наблюдаются от некоторых из многочисленных спам-сессий, когда спамерский бот-софт некорректно общается с почтовиками (иногда сам наблюдаю такие сессии, совершенно на них не обращаю внимания, ибо за всеми спамерами не уследить, главное чтобы они блочились и все).

Если статистика покажет что от нормальных почтарей проблем не наблюдается - значит дело действительно либо в шибко умном файрволе на домашнем компе либо в оборудовании провайдера дома. Тогда и париться собственно и не нужно будет. Довольно сложно представить жизненную необходимость смтп-коннектов из дома на работу.
Рабочую почту из дома можно отправлять и с помощью smtp-провайдера, он для того и делается.
У меня МДемон вообще не принимает клиентские smtp-коннекты (работает как фронт-релей перед Exchange). Принимает smtp-коннекты только для приёма почты с других почтовиков. А клиенты все сидят по родному MAPI-over-RPC(-over-HTTPS если снаружи) и по ActiveSync с разных девайсов на эксчендже.

MKaptsevich Полагаю, где-то на пути стоит рутер, бреющий расширенный протокол ESMTP или вообще некорректно фильтрующий и простой протокол SMTP. Такое было на Cisco PIX или ему подобном, не пропускал ESMTP. Лечение на самом циско рутере:
fixup protocol smtp 25
заменить на
no fixup protocol smtp 25

на Cisco 871, там немного другая команда:
no ip inspect name smtp

Если у тебя другой рутер или фаер или антивир с фаером , то гляди в них и отключай фильтрацию SMTP или 25 порта

fly_indiz
Цитата:

ты кажется просто не очень понял суть его проблемы.

Я ее понял очень хорошо, ибо уже неоднократно помогал подобным "шифровальщикам" устранить глюки в работе их почтовых серверов после того, как они раскрывали "Большую Военную Тайну" - реальное имя своего почтового домена.
MKaptsevich
Цитата:

XXXX XXXXXXXXX   - это в логе сервера я ничего не менял.

А " to [zzz.zzz.zzz.zzz:25]" и "domen.by ESMTP MDaemon" тоже в логе сервера?
Я не понимаю, какой резон все это шифровать? Чтобы скрыть тот факт, что доменом domen.by управляет неквалифицированный админ?

Цитата:

А " to [zzz.zzz.zzz.zzz:25]" и "domen.by ESMTP MDaemon" тоже в логе сервера?
Я не понимаю, какой резон все это шифровать? Чтобы скрыть тот факт, что доменом domen.by управляет неквалифицированный админ?

Не всегда и не ВСЕМ ВСЕ можно показывать.
Т.к. такие как Вы могут сделать НЕПРАВИЛЬНЫЕ выводы. Зачем? Потешить Ваше самолюбие?

fly_indiz
ipmanyak
Вам спасибо
У меня аса сегодня её подправят.

Добрый вечер!

Не подскажите куда покпать, на наш почтарь посылают письмо, в результате посылающий получает отлуп в виде следующей ошибки:

company.ru #550 Domain company.ru does not accept mail from
ip77-245-1-82.zaindata.jo ##

Заранее спасибо!


Добавлено:
Спасибо, ipmanyak
Нашел ваш ответ мохнатого года =) "Это бреет ваш фильтр Host screening "

AkeHayc
Цитата:

company.ru #550 Domain company.ru does not accept mail from
ip77-245-1-82.zaindata.jo

Я бы от таких хостов тоже почту не принимал. 99% вероятность спама.

AkeHayc
угу. видать в хостскрине какая нить замечательная запись типа
*#-#-#-#*
режущая юзерпулы (читай - рассадники спама и вирья) почти всия мира.

ipmanyak
Цитата:

Полагаю, где-то на пути стоит рутер, бреющий расширенный протокол ESMTP или вообще некорректно фильтрующий и простой протокол SMTP. Такое было на Cisco PIX или ему подобном, не пропускал ESMTP. Лечение на самом циско рутере:
fixup protocol smtp 25
заменить на
no fixup protocol smtp 25

на Cisco 871, там немного другая команда:
no ip inspect name smtp

Если у тебя другой рутер или фаер или антивир с фаером , то гляди в них и отключай фильтрацию SMTP или 25 порта

Да, вы оказались правы, спасибо, АСУ подправил теперь при подключении с дома всё ок.

Но если косячила циска как вся остальная почта ходила(более 200 писем в день)?

MKaptsevich ты же сам сказал, что трабла дома, а не на работе?
Цитата:

и лог на сервере подключения с дома:
Session 3000; child 1
Tue 2012-01-17 08:55:21: Accepting SMTP connection from [93.125.13.214:1090] to [zzz.zzz.zzz.zzz:25]
Tue 2012-01-17 08:55:21: --> domen.by ESMTP MDaemon 12.0.3; Tue, 17 Jan 2012 08:55:21 +0300
Tue 2012-01-17 08:55:29: <-- XXXX XXXXXXXXX
Tue 2012-01-17 08:55:29: --> 500 What? I don't understand that.

Цитата:

ты же сам сказал, что трабла дома, а не на работе?

Я с дома телнетом на сервак на работе подключался (лог подключения с дома) .

Так в том то и дело что проблем небыло(и нет) с включенным fixup на циске. Почта бегает.
Не были доставлены пару сообщений к нам. При начальной проверке с их сервера было обноружено, что подключившись на 25 порт телнетом на наш сервак MDAEMON не понимает HELO. Но почта с маил ру и.д. исправно доставляется пользователям.

Т.е. подключившись на 25 порт телнетом с конкретного сервера дружественной организации, и как оказалось с моего домашнего компа (а может и со всех компов в мире ) MDAEMON не понимает HELO.
no fixup решает эту проблему.