$final_spam_destiny

 ( spikes | 2016. december 9., péntek - 16:19 )

Üdv!

Küzdünk a spamokkal mint mindenki:)
Az volna a kérdésem, hogy ha az alábbi config szerint a spam destinity D_DISCARD, ami a leírás szerint, nem kézbesíti a levelet, csak egy másolatot a karanténba. Tehát átírja subject és és ennek ellenére kézbesíti, pedig nem kéne.. Esetleg vmi ötlet miért is így működik?

$sa_tag_level_deflt = -999; # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 5.31; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 8.0;
$sa_dsn_cutoff_level = 12.0;
$sa_spam_subject_tag = '***Possible SPAM***';
$final_spam_destiny = D_DISCARD;
$spam_quarantine_to = "spam\@domain.hu";

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Nem írod ezt felül valahol később?
(Gondolom manapság elterjedt whatever.conf.d könyvtárban van, ami ABC szerint kerül feldolgozásra. Tehát a 00-zeller.conf-ban beállított értéket simán felülcsaphatod a 99-alma.conf file-ban. grep destiny /etc/whatever/whatever.conf.d/* )

1 helyen tudom elképzelni a 20-debian_defaults-ba, de sztem az előbb van mint 50-user, ha nem tévedek...
Mert hogy pl. a subjectet átírja, csak vmiért kézbesíti is...

20-debian_defaultsba van ilyen:
$final_virus_destiny = D_DISCARD; # (data not lost, see virus quarantine)
$final_banned_destiny = D_BOUNCE; # D_REJECT when front-end MTA
$final_spam_destiny = D_BOUNCE;
$final_bad_header_destiny = D_PASS; # False-positive prone (for spam)

Spikes

Tényleg nem kéne neki.
A kill level-t eléri a spam score?
Nincsenek /user beállítások amivel ezt felülcsaphatnád?
Nem lehet hogy bad header is van és amiatt van a pass?

Szerk: egyébként ha ez nem megy akkor header check-kel is megoldható a dolog.

Ez igaz, header checket használom, de sztem az meg előbb van mint mielőtt átírná subjectet...

Spikes

Szerintem beállítás kérdése, én így redirect-elem a spam tag-es leveleket.

Az a beállítás kérdése melyik van előbb? Ezt nem értem. Kifejtenéd?
Spikes

Egen, kifejtem. Szóval több smtpd instance vagyon, és a receive_override_options-ben szabályozható (no_header_body_checks) hogy legyen-e header check avagy ne. A main.cf-ben globálisan, de azt /instance felülírhatod a master.cf-ben.
Ha az amavis felől visszatérő (magas portos, 10025 vagy ilyesmi szokott lenni a howto-kban) smtpd-nél van header/body check ellenőrzés akkor tudod vele abuzálni a spam-nek jelölt leveleket.