Re: google spamszűrő kérdés/probléma

2022-05-21 bef zés Vertike László


2022. 05. 21. 10:57 keltezéssel, Kiss Gabor írta:


On 5/21/22 10:46, Vertike László wrote:

Ahogy most utánaolvastam, elhűltem miféle módszereket ajánlanak a 
probléma orvoslására:


Sajnos sok választásunk nincs. Vagy SRS-el forwardolunk, vagy 
sehogy... Viszont az SRS-sel a "nevedre veszed" a továbbított 
levelet, ezért nagyon meg kell válogatni, mit továbbítunk; de 
gondolom, hogy a bejövő levelek eleve szűrve vannak? Ha nem, akkor az 
SRS-el valóban könnyű út vezethet a saját levelező szerverünk 
RBL-ekre felíratásához...


Nem azért húzom a szám szélét. Az RBL-re a sima forwardolással is 
felkerül az ember. (IP címet listáznak, nem a feladót.)


Az zavar, hogy itt lényegében egy tunnelt hozok létre. Na de ehhez a 
fogadó oldalon is kell infrastruktúra, ami kicsomagolja az elrejtett 
feladót és helyreállítja az eredeti headert. Ez meg nem tipikus. 
Lefogadom a Gmail nem teszi meg ezt a szívességet! :-)


Az SRS emlékeim szerint csak az envelope from / return-path 
módosításával foglalkozik, a From-hoz nem nyúl (az a DKIM aláírt 
leveleknek is ártana). Tehát a GMail által megjelenített levélen nem fog 
látszani, hogy az SRS hozzányúlt. A módosított envelope from-mal 
leginkább csak bounce esetén kell foglalkozni, de az meg úgyis nagy 
valószínűséggel átmegy az átírást végző szerveren/szervezeten a 
visszaúton is.


VL


_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux


Re: google spamszűrő kérdés/probléma

2022-05-21 bef zés Vertike László

Szervusztok!

2022. 05. 21. 6:53 keltezéssel, Kiss Gabor írta:


On 5/20/22 20:54, Sörös Zoltán wrote:

Bocsánat, ha az eredeti levélből nem lett volna egyértelmű, 'mi' a 
filmjus.hu domain vagyunk, a val...@valahol.hu küld egy levelet a 
bar...@filmjus.hu címre, ami /etc/aliases -ből továbbítódik pár 
címre, többek között az egyik kolléga @gmail.com -os, mobilos címére is.


És ezzel pont hatástalanítja az SPF-et, amint azt már Ervin is taglalta.
Ez volt a legnagyobb kifogás a módszerrel szemben már kezdettől fogva.
Ahogy most utánaolvastam, elhűltem miféle módszereket ajánlanak a 
probléma orvoslására:


http://www.open-spf.org/Best_Practices/Forwarding/ -> 
http://www.open-spf.org/SRS/


Sajnos sok választásunk nincs. Vagy SRS-el forwardolunk, vagy sehogy... 
Viszont az SRS-sel a "nevedre veszed" a továbbított levelet, ezért 
nagyon meg kell válogatni, mit továbbítunk; de gondolom, hogy a bejövő 
levelek eleve szűrve vannak? Ha nem, akkor az SRS-el valóban könnyű út 
vezethet a saját levelező szerverünk RBL-ekre felíratásához...


VL



kissg
_
linux lista  - linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux


Re: nvidia

2007-12-31 bef zés Vertike László
 Ha ujra telepitem a gyari scriptet mukodik a kovetkezo ujrainditasig.Van
 valakinek otlete?Elore is koszi.

modprobe nvidia; echo nvidia  /etc/modules

Üdv,

Tike

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux


Re: exim, sikeres kikuldes eseten kulso script meghivasa

2007-12-20 bef zés Vertike László
 Hello!

 Van arra mond exim-mel, hogy egy sikeres remote kezbesites eseten
 el tudjak indintani egy kulso scriptet? Ami mondjuk megkap par hasznos
 infot a mailrol, pl. message-id, from, to, subject esetleg. Fontos,
 hogy ezt csak akkor kellene, amikor tenylegesen sikerult kikuldeni a
 levelet, s atvette 2xx-as koddal a tuloldal. Ha nem sikerult a kuldes,
 mert pl. unknown user, vagy mar 7 napja visszautasitja a fogado fel
 atmeneti hibaval, s az exim feladja a probalkozasokat, akkor ne induljon
 el a script.

 Nem nagyon tudom merre induljak, a spec.txt-t mar parszor atneztem, de
 nem talaltam tampontot.

Exim4 specifikáció Generic options for transports részében láttam egy
ilyet:

shadow_transportUse: transports Type: stringDefault: unset

A local transport may set the shadow_transport option to the name of
another local transport. Shadow remote transports are not supported.

Whenever a delivery to the main transport succeeds, and either
shadow_condition is unset, or its expansion does not result in the empty
string or one of the strings #8220;0#8221; or #8220;no#8221; or
#8220;false#8221;, the message is also passed to the shadow transport,
with the same delivery address or addresses.

a shadow_transport meg lehetne pipe transport, ami a scriptedet hívja.

Üdv,

Tike

_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux