Вопросы Теги

Shkëmbimi nuk vendos postë në Junk pavarësisht vlerës së titullit SCL

Problemi

Po vendos vlerën SCL përmes rregullave të bazuara në Exchange. Rregullat zbatohen në mënyrë korrekte kur përputhen kushtet e dëshiruara dhe vlera SCL është vendosur siç duhet, siç dëshmohet në kokat e mesazheve. Gjithashtu, grupi i vlerës së SCL (6) përputhet me pragun e Junk SCL (vlera e paracaktuar, 5).

Sidoqoftë, serveri Exchange nuk e vendos mesazhin në dosjen Junk.

Unë jam duke kërkuar ose informacion për atë që mund të jetë gabim, çfarë mund të prishë rrjedhën e duhur të punës, gjithçka. Ose ndonjë këshillë mbi hapat shtesë diagnostikues që duhet të kryhen.

Skenari

Tani jam duke organizuar një migrim në Exchange 2016 në një skenar vijues (shembuj të vlerave):

enter image description here

  1. Regjistrimi DNS MX drejton dërguesin në serverin e vjetër,
  2. serveri i vjetër kryen analiza të postës së bezdisshme përmes SpamAssassin dhe shton koka përkatëse në mesazhe, përfshirë mesazhet X-Spam-Score ,
  3. te marrësit që nuk janë të njohur për serverat e vjetër (dmth. Kutitë postare të migruara) përcillen te Exchange,
  4. Exchange zbaton një rregull mbi X-Spam-Score vlerën e kokës, modeli që përputhet [+] {4} (katër ose më shumë + karaktere, të cilat janë ekuivalente me rezultatin 4.0+ , duke vendosur nivelin e SCL në 6 .

Konfigurimi i saktë për rregullin (bazuar në Ekzistoni-TransportRule ): 

HeaderMatchesMessageHeader                    : X-Spam-Score
HeaderMatchesPatterns                         : {[+]{4}}
SetSCL                                        : 6

Unë e di që kjo funksionon deri më tani, pasi mesazhet e marra me X-Spam-Score që përputhen me modelin DO marrin X-MS- Exchange-Organisation-SCL: Titulli 6 .

Megjithatë, mesazhi përfundon në Inbox në vend që të përcillet në dosjen Junk: (

Shembulli i grupit rezultues të kokave në mesazhin e dorëzuar: 

X-Spam-Score: 8.0 (++++++++)
X-MS-Exchange-Organization-SCL: 6
X-MS-Exchange-Organization-AuthSource: mbx-a.example.com
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Transport-EndToEndLatency: 00:00:01.0250276
X-MS-Exchange-Processed-By-BccFoldering: 15.01.1531.003

Informacion shtesë

Konfigurimi i mësipërm është në thelb një analog i konfigurimit standard të Mbrojtjes Online Exchange, në të cilin serveri EOP mund të shihet si një ekuivalent i serverit të vjetër me SpamAssassin. Në këtë drejtim, Dokumentacioni i EOP sugjeron një konfigurim shumë të ngjashëm, që ndryshon vetëm në kokat e burimit të përdorura për të përcaktuar statusin e mesazhit. Orari i mëtejshëm i vendosjes supozon vendosjen e EOP para serverit të vjetër, dhe më pas heqjen e serverit të vjetër me rolin e tij të mbrojtjes ndaj postës së padëshiruar. Get-OrganizationConfig: 

SCLJunkThreshold                                          : 4

Get-ContentFilterConfig: 

SCLRejectThreshold                    : 7
SCLRejectEnabled                      : True
SCLDeleteThreshold                    : 9
SCLDeleteEnabled                      : False
SCLQuarantineThreshold                : 9
SCLQuarantineEnabled                  : False

Konfigurimi i Exchange nuk përfshin serverat Edge Transport dhe AntiSpam Agents nuk janë instaluar / aktivizuar në serverat Mailbox, por dokumentacioni i Microsoft nuk përmend askund një kërkesë të tillë, p.sh .:

Azhurnimi 1

Unë kam instaluar Agjentë Antispam në të gjitha nyjet dhe kam kryer testet e mëposhtme:

  1. dërgimi i një poste të trilluar për të shkaktuar dështimin e SenderID;
  2. dërgimi një postë e fabrikuar për të shkaktuar rezultat të lartë SCL pa shkaktuar refuzim paraprak.

Të dy testet rezultuan në mesazhin SCL6 duke elivuar, por përsëri, në Inbox në vend të dosjes Junk.

Kjo dëshmon se çështja nuk është e rëndësishme për Rregullat e Transportit. Pavarësisht se cili mekanizëm ngre / cakton nivelin e SCL, mesazhi përfundon në Inbox.

0
задан 21 February 2019 в 16:43
2 ответа

Я обнаружил прямую причину проблемы.

Нежелательные сообщения перемещаются в папку нежелательной почты с помощью механизма правил для папки «Входящие», эквивалент правил транспорта, но в почтовом ящике уровень - тот, который настраивается через Почта> Автоматическая обработка> Входящие и правила очистки карта параметров.

Каждый почтовый ящик по умолчанию имеет скрытое Правило для папки «Входящие» с именем Правило нежелательной почты - его существование может быть обнаружено с помощью PowerShell: 

PS > Get-InboxRule -Mailbox "test@contoso.com" -IncludeHidden

Name             Enabled Priority RuleIdentity
----             ------- -------- ------------
Junk E-mail Rule True    1        4028702183896383681

В случае нашего сервера в значительном количестве почтовых ящиков (75% учетных записей, созданных с помощью одного пакета PowerShell) не было этого правила.

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

Set-MailboxJunkEmailConfiguration $MailBox -Enabled $False
Set-MailboxJunkEmailConfiguration $MailBox -Enabled $True

Это может быть применено ко всем затронутым почтовым ящикам: 

Get-Mailbox -ResultSize Unlimited | %{

    $Rule = Get-InboxRule -Mailbox $MailBox -IncludeHidden | ? Name -eq "Junk E-mail Rule"

    If ( $Rule -eq $null ) {
        Set-MailboxJunkEmailConfiguration $MailBox -Enabled $False
        Set-MailboxJunkEmailConfiguration $MailBox -Enabled $True
    }
}

Обратите внимание, что до тех пор, пока основная проблема решается, эту процедуру необходимо будет внедрить во все рабочие процессы r создание биржевых аккаунтов.

1
ответ дан 4 December 2019 в 15:46

Все получатели получают нежелательные письма в папке «Входящие» или в определенных?

Пожалуйста, войдите в OWA и проверьте правильность конфигурации, как показано на скриншоте ниже.

enter image description here

0
ответ дан 4 December 2019 в 15:46

Теги

Похожие вопросы