Sziasztok!
Adott egy "buta" eszköz, ami SMTP-vel tud levelet küldeni. Ezt a levelet kellene módosítanom az SMTP-n, majd átadnom egy másik SMTP-szervernek.
Ezeket kell módosítani:
- feladó neve és e-mail címe
- tárgy egy része
- ki kell venni a fejlécből a tényleges küldőre vonatkozó adatokat, úgy kell látszania, mintha a levelet az a szerver küldené, amin az SMTP van
- reguláris kifejezésekkel definiált szabályok szerint kellene tudnom módosítani a PLAIN TEXT üzeneteket
Ötlet? Javaslat?
- 3855 megtekintés
Hozzászólások
A buta eszkozon a cimzett modosithato?
Kuldheted az okos eszkozre, es akkor csak egy procmailre lesz szukseged az adatok (es a body) kinyeresehez, utana modositod ezeket, es kuldesz egy uj levelet az eredetitol teljesen fuggetlenul.
ui: csak nalam doglodik most a hup?
--
ezt tényleg ennyire nem értitek? - turdus :)
- A hozzászóláshoz be kell jelentkezni
Írj rá egy sajáát kis buta SMTP szervert ami az eszköz által használt funkciókat implementálja csak. Wireshark-kal rögzíts pár kommunikációt. Valószínűleg nem sokban fog eltérni két levél küldése. Nem kell 100%-osnak lennie az SMTP szerverednek.
Én valószínűleg Java-ban esnék neki a problémának. Amikor a kliens kapcsolódna, akkor megnyitnék egy kapcsolatot a másik SMTP felé és csak azokat a sorokat módosítanám a kommunikációban amik ténylegesen érdekelnek. Minden más szempontból átlátszó lenne a program.
- A hozzászóláshoz be kell jelentkezni
Helyedben saját miltert írnék rá. Nekem szűrő feltételek alapján történő subject és sender átírásra bevált. Mondjuk regex nincs benne, azzal már nem komplikáltam. A string kezelés miatt a debug-olása letarthat egy ideig.
Üdv:
Dw.
"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."
- A hozzászóláshoz be kell jelentkezni
- ki kell venni a fejlécből a tényleges küldőre vonatkozó adatokat, úgy kell látszania, mintha a levelet az a szerver küldené, amin az SMTP van
Ezt Te nem akarod, mert Direct-to-MX sendingnek minosul es azonnal megy a spam folderbe a level. Egyebkent az Exim szerintem meg tudja oldani neked a fenti kereseket.
- A hozzászóláshoz be kell jelentkezni
A probléma pont ez. Extrém helyen van a "buta eszköz", és nem szeretném, hogy emiatt spam mappába kerüljenek a levelei. Ehelyett úgy kellene kinéznie a levélnek, mintha azt a szerveremről küldtem volna (ezen lesz telepítve az SMTP)
--
Kum G.
Linux pólók HUP pólók Linux tanga
- A hozzászóláshoz be kell jelentkezni
Direct-to-MX sendingnek minosul es azonnal megy a spam folderbe a level
tessek?
- A hozzászóláshoz be kell jelentkezni
Ha nincs egyetlen Received sor sem a leveledben, akkor ugy nez ki, mintha kozvetlenul a levelezo szervernek kuldted volna. Na, ezert mostanaban buntipontok jarnak pl. a SpamAssassinben is.
In fact, direct-to-MX is really no longer considered an acceptable practice, or even a tolerable one. Many MX hosts are now programmed to detect attempts at direct-to-MX mailing, and may either reject such mailings or else tag them as spam. Also, many internet services publish information about which hosts within their domains are allowed to send mail (via a mechanism known as Sender Policy Framework), and hosts that don't appear on these lists are likely to have their mail rejected by an MX that subscribes to SPF. So, even well-intentioned users of direct-to-MX mailing must face the possibility that their mail won’t go through, or else it may be reported as spam and their address blacklisted (see "Countermeasures" below). Forras: SpamCop
- A hozzászóláshoz be kell jelentkezni
ez nem tul szofisztikalt modja annak eldontesere, hogy spam vagy sem. Ha nagyon kell, tehetek bele fake Received: sorokat is, es sok szerencset, hogy eldontsd, fake vagy sem. Masreszt ez azert sem tul ugyes megoldas (SA buntipontok LOL), mert mi van akkor, ha egy ceg smtp szervere kiszedi a kliensek privat cimet a fejlecbol? Akkor ugy tunik, hogy "direct to mx", pedig megsem. Masreszrol egy relay szervernek miert is kellene barki mast beiktatni a cel MX koze?
Ennel imho sokkal ertelmesebb az a megkozelites (mondjuk egy megpatkolt postgrey kepeben, amit en is csomagolok egy spamszuro melle), hogy az smtp kliens ptr rekordjat nezed meg, nem-e ugy nez ki, mintha egy broadband dsl/cable/whatever gep lenne.
- A hozzászóláshoz be kell jelentkezni
"Ennel imho sokkal ertelmesebb az a megkozelites (mondjuk egy megpatkolt postgrey kepeben, amit en is csomagolok egy spamszuro melle), hogy az smtp kliens ptr rekordjat nezed meg, nem-e ugy nez ki, mintha egy broadband dsl/cable/whatever gep lenne."
+1
De önmagában kevés a boldogsághoz, még elfér mögötte egy SA.
- A hozzászóláshoz be kell jelentkezni
De önmagában kevés a boldogsághoz, még elfér mögötte egy SA.
nyilvan, de ez csak egy elotet, ami kiszor valamennyi szemetet, kimelve az eroforras igenyesebb tartalomelemzest, ami foleg az SA-nak nagy segitseg.
- A hozzászóláshoz be kell jelentkezni
Nem azt mondom, hogy okos a megoldas, csak azt, hogy ha erre figyelni kell, mert spambe mehet miatta a level.
- A hozzászóláshoz be kell jelentkezni
"Ezt Te nem akarod, mert Direct-to-MX sendingnek minosul"
Miért?
- A hozzászóláshoz be kell jelentkezni
Anno mintha a TIS fwtk toolkitben lévő smap/smapd párossal játszottam volna ilyesmit, de az "hűderégen" volt. Egyébként meg a hülyén levelező kütyüd felől érkező smtp-forgalmat én is egy saját kis programmal fogadnám (iptables-ben szűrve, hogy csak onnan): amit a kütyü küld, azt megmogyorózás után tolnám rá a localhoston futó normál smtp-szerverre, amit meg a szerver válaszol, azt egy az egyben vissza a kütyünek. Ha elviseled/szereted a Python-t, akkor meg Zorp, és szinte csak a mogyorózást kell megírnod :-D
- A hozzászóláshoz be kell jelentkezni
Szerintem az utóbbi lesz, köszönöm a tippet.
--
Kum G.
Linux pólók HUP pólók Linux tanga
- A hozzászóláshoz be kell jelentkezni
Es a relay? Csak mert errol kapasbol a 'sok huho a semmiert' jutott eszembe :)))
/* Signature
while true; do echo -e "cat your_reply > /dev/null"; done;
Signature */
- A hozzászóláshoz be kell jelentkezni