это не оригиналы писем, это кеш файликов => sk147432

Команда просто scrub send_orig_file и написано, что оригинальные емейлы хранятся там, но не суть) Сколько эти кеши хранятся по времени?

By default, each cache keeps up to 4000 files (worst case) in /var/log/scrub/repository/ folder for caching results.

по времени думаю пока не перезапишутся новыми или место в вар/лог не кончится)

ну, да, но есть еще и '# scrub send_orig_file {fileID} all'

хотя надо проверить, мож и мейлы там же

Спасибо, Сергей! А откуда это?

All - это он всем админам отправит?

sk146395

для всех писем The '# scrub send_orig_file {fileID} all' command will send the original attachment file cleaned by Check Point SandBlast., , для конкретного письма Or you can use the command below to recover the file from one particular email id:'# scrub send_orig_file {fileID} {emailID of the receiver}'

это из той же sk114629)

Да я вижу это, но смысл не понимаю😂

Не написано же кому он отправит

очевидно тому, кто в поле To ) Адресату

Ааа

Благодарю

Коллеги, добрый день.
подскажите, в чем может быть проблема. После обновления шлюза с R77.30 на R80.40 в одном приложении между Front-end в DMZ и backend в LAN стали копиться ошибки nginix 502. В логах вижу кучу событий "Server to client packet of an old TCP connection" для http.
Клонировал сервис, выкрутил у него таймаут в 24 часа, убрал aggressive aging - не помогло. В Inspection Settings добавил исключение для этого соединения - все равно ошибки растут.
При этом при возврате трафика на 77.30 дропов нет.
Шлюз нагружен не более 15%, таблица сессий также далека от переполнения. Кроме этого приложения жалоб ни от кого нет.

Подскажите, что еще можно сделать, чтобы митигировать негативное влияние?

как будто асинхрон маршрутизации

ну с маршрутизацией все ок, по идее. Кроме того, на этом же шлюзе но с старой прошивкой 77.30 такой проблемы не было

@oldflint подскажешь что-нибудь ?