Nem tudod eldonteni mikor atveszed, (ha valid destination vagy erre a domainra) hogy kezbesitheto, vagy sem a 2, vagy a tizedik hop utan, ha mailhubot uzemeltetsz. Ne induljunk mar ki a pistike2 -bol.

Annyi penzert amennyibe kerul az exchange mar nem fert bele az, hogy "valamilyen hasznalhato" ellenorzest vegezzen a mogotte levo szerverre vagy szerverekre?

--
maszili

Utalom a loncshust:)

erre gondoltam en is, csak ez a legegyszerünn módja ... csere

amúgy jó lenne, ha már dolgoznék olyan vállalatnál ...
mivel akkor már végeztem volna az egyetemmel :)

Bizonyos szemszögből előnyös is lehetne ez a mellékhatás... :)

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Minimum egy nullát nyugodtan mögé tehetsz, de ha egy kicsit állítgatsz rajta az így kapott értéket akár kétszerezheted is.

Ki fogom próbálni, jól hangzik :)

En nem hasznalok azt, de a spamkonyvben jo eredmenyt ert el, ill. en csak jokat hallottam rola.

ASK Me No Questions, I'll Tell You No Lies

- igaz, be lehet vezetni egy számlálót (szerintem 10-20-nál nem érdemes nagyobbra állítani)
- az eddigi tapasztalataim szerint a userek 99%-a jobb, ha egyáltalán nem kap bounce-ot, mert nem érti, így lehet, hogy ez annyira nem izgat (memcached helyett lehet valami állapottartót is használni, ha úgy tartja a kedved :)

értem, csak fáradt vagyok, erre ez jó megoldásnak tűnik, először azt hittem, a spanyol viaszt akarod feltalálni. :)

mi van mondjuk a greylist rendszerekkel, azok is envelope from alapján szoktak pl auto whitelist-elni stb. ?

Az ures feladoval erkezok ellen most ezt a negysorost probalgatom (exim, az acl_check_rcpt-ben):

deny senders = :
condition = ${if ! eq{$recipients_count}{1}{1}}
message = Bounces must have only a single recipient
log_message = Another denied due to backscatter check

Aztan ha bevalik, es nem dob el olyasmit, amit nem kene, marad.. Esetleg valaki nalam okosabb megmondja, miert rossz nekem :)

Legegyszerűbb megoldás például az exim add_header ACL-je, és ellenőrzés spamassassinnel (és persze pluszpontok, ha nem stimmel).
---
;-(

Sender-ID?

ASK Me No Questions, I'll Tell You No Lies

pedig a megoldás, - még ha nem is ez-, olyan lesz, ami kényelmetlenségekkel fog járni a megoldás mellett mint mellékhatás. addig maradnak a tűzoltogatások. sajnos...

--
xterm

Erősen leegyszerűsítve írtam a lényegét. Természetesen a domain tulajdonosa ennél részletesebben szabályozhatja, hogy honnan lehet levelet küldeni.
Egyébként mi a gond vele?

Adnék három példát ki hogy használja:
t-online: sehogy
invitel: ha a saját levelező szervere küldi, azt engedélyezi. Ha más küldi, akkor puhán elutasítja.
g-mail: ha a saját levelező szervere küldi, azt engedélyezi. Ha más küldi, akkor nem mond rá semmit.

Ha a fogadó mail szerver kezeli az SPF-et, akkor elutasítás esetén elutasítja a levelet, egyébként a domaintől kapott infót beteszi a levél fejlécébe és a spam szűrők további infót tudnak kapni arról, hogy a levél tényleg onnan jött-e, mint ahonnan kellett volna.

Tettem egy próbát. gmail-es levelet küldettem az inviteles levelező szerverrel.
A mi levelező szerverünk kezeli az SPF-et, ezért a következő került a fejlécbe:
Received-SPF: Neutral (access neither permitted nor denied)
Ugyanaz gmail-lel küldetve:
Received-SPF: Pass (sender SPF authorized)

Olvasd el a hírt még egyszer! :-)
Ezek olyan levelek, amit x nevében küldetnek y domainről.

a sajat domainjaba mindenki olyan spf rekordot ir, amit akar.
az enyembe en is, oszt akkor az en nevemben kuldott level nem kap minusz pontot a szuron, joesetben el sem jut odaig, mert mar a mailszerver eldobja.

valoban nem a spam ellen, de itt eppen hamisitasrol beszelunk, es az spf erre a visszapattintott szarra tok jo lenne, mert ha en aszondom, hogy nemkuldhet a nevemben; akkor az a mailszerver ahova allitolag kuldtem, eldobhatja a levelet mindenfele bounce es szivfajdalom nelkul, megaztan ha letezo cimre ment a cucc,a bayes elemzesre sem kell eroforrast pazarolni...