Freemail átirányítás: nem jön át minden levél

Web, mail, IRC, IM, hálózatok

Sziasztok!

Édesanyámnak van egy freemail-es (tévedésből) és egy gmail-es email címe. Az egyszerűség kedvéért beállítottunk átirányítást, hogy minden levelet toljon át a freemail a gmail-es fiókba. Azonban az a cudar helyzet állt elő, hogy a reklám levelek egytől egyig megérkeznek, a számlák viszont nem. 

Ami számlánál lehetett, ott átírtuk a kapcsolattartói e-mail címet, azonban az egyik szolgáltatónál ezt nem tudjuk meglépni:

a jelenlegi email címhez tartozó aktiváló linkre nem lett kattintva és az csak 24 óráig él. Viszont megváltoztatni nem lehet az email címet, amíg a jelenlegi nincs aktiválva. Aktiváló link újra küldésére nincs lehetőség afaik. 

Sakk-matt. 

Ötlete valakinek?

Tudjuk, sz*r a freemail :)

  • 1336 megtekintés

( andrej_ v | 2023. 04. 25., k – 10:27 )

Nem is fog. Az SPF rekord megfogja, amit már manapság mindenki jó szigorúra állít, pláne aki számlát küld. NE használjatok átirányítást, hanem a GMail fiókban tessék külső fiókként felvenni.

A sikeres kézbesítést akkor vélelmezem, ha nem kapok instant reject-et. Az SPF-fakapot a fogadó oldal azonnal közli, jól tudom?

A mailbox full-t is. A címzettnemtalálható-t is.

Ha ennyit lekezel(ne) a freemail (mint ahogy állítólag a fentebb írtak szerint egy részét v. semelyiket sem teszi), akkor máris megbízhatóbb lenne a forward-then-delete logika.

Az SPF-fakapot a fogadó oldal azonnal közli, jól tudom?

Nem feltétlenül. Ha after-queue filterezés van, akkor először beesik a fogadó oldalon a quque-ba. Amikor elindul a queue feldolgozása akkor a spam szűrő dönthet úgy, hogy SPF fail miatt nem kézbesíti a címzettnek. Erről sem a feladó, sem a fogadó fél nem fog értesülni.

A--> B -nek küld emailt. "A" a feladó (ez a példa szempontjából nem kell konkrétan ismertnek lennie, azaz lehet a világ összes email címet használója), "B" pedig az eredeti címzett, aki freemail-es. "B" beállított egy olyat a freemail fiókjában, hogy tovább forwardolja a "B"-be érkező leveleit "C" címre. C legyen mondjuk egy gmail. A B email fiókot nem fogja emberünk nézegetni, ezért elkerülendő hogy beteljen a limitje, a forwardolás után a B mailboxából el kell tünjön az üzenet.

Ilyenkor az A--> B --> C útvonalon ki és mennyi ideig tárolja az üzenetet, ki forwardol és ki hogyan tudja megakasztani a lancot? Köszi.

Nincs ilyen. :)

B szerver/rendszer, ha csak sima forward van, de store nincs, akkor egy instant teljesen sima SMTP kapcsolódással fordul C felé. Namármost innentől C szerver az A feladót vizsgálja (hacsak nincs SRS, de még mindíg ritka), és így SPF rekordon, meg B szerver feketelistás állapota alapján lesz valami. Ha C szerver visszautasít, akkor B-nek illene küldenie egy visszapattanót, hogy mi történt. Se A se B nem tárol semmit, mert lement a küldési folyamat, sikertelenül és vége.

Tárolás legfeljebb a B szerveren lehet, hogy ha be van állítva, hogy egy helyi (freemail-nél vagy másnál A helyi) fiókba is kerüljön másolat, és fontos, hogy másolat. Ez technikailag úgy néz ki, hogy kettő célzottja van a továbbításnak, egy a külső/másik fiók, és a másik önmaga. Exchange-nél ez beállíŧásában kicsit máshogy néz ki, de alapvetően ugyanez a logika.

Csak azt tudom javasolni, hogy külső szerverre, fiókba továbbíttást senki se használjon, hanem ha gmail a kedvenc, akkor vegye fel ott rendesen a fiókjait külsőként.

Lehet idegeskedni, meg pezsegni, de ez így működik amióta SMTP/MTA szinten erre lehetőség van. Egy kicsit az SPF ebbe bekavart, de lett nekünk SRS, viszont nem azért, hogy mindenki összevissza mindent továbbítson.

Szerintem továbbra se értem, de ez simán betudható annak h. semennyire nem ismerem az SMTP lelkivilágát, és az Exchange szervert is csak internal rendszerben piszkáltam.

Azt hogy érted h. "Nincs ilyen"? Az "A" csak annyit tud h. neki "B"-hez kell küldenie egy levelet. Be is csatlakozik "B"-hez smtp-n. Na innentől nem bírlak követni h. mi történik ha "B"-nél forward van beallítva "C" irányába. B visszaszól A-nak hogy C rendszeréhez lesszíves átmenni, és erre A engedelmesen felveszi a kapcsolatot C-vel?

Nem. :) A szerver nem tud semmit a C-ről. Az eredeti küldő annyit tud, hogy a címzett domain MX rekord szerint hova kell próbálkoznia. Innentől minden a címzetten múlik. Ha a címzettnél továbbítás van beállítva csak önmagában, nincs helyi fiók, nincs semmi, akkor ebből lesz a C szerverre csatlakozás, ahova B csatlakozik. Ha szerencsés eset van, akkor B szerveren kb. egy sessionben ez végigmegy, és lesz valami. A C szerver szempontjából az látszik, hogy az eredeti feladóval küldene B szerver, de közben ha van SPF elllenőrzés, akkor meg azt is megtudja, hogy igenám, de a feladó domainen a B szerver nincs engedélyezve...

A szerver > B szerver (recipient lookup > külső cím) > C szerver

Hogy visszafelé milyen hibaüzenetek, állapototok mennek az már egy külön dolog.

Az újra hangsúlyozom, hogy ha bárhogy van a B szerveren helyi fiókos tárolás, akkor az gyakorlatilag kettőzi a kézbesítést.

A Freemail tovabbitasa szerintem jol mukodik. Ha allitassz be egy tovabbitast, es lekapcsolod a cel SMTP-t, akkor szepen ott lesznek a Freemail weben a levelek (1-2 eve ez meg igy mukodott). Majd ha beinditod, par ora mulva beesnek a cel szerverre, a Freemail webrol meg eltunnek. Szoval, szerintem, csak azutan tavolitjak el a leveleket, miutan a celszerver atvette. Viszont, en nem nagyon szoktam latni fogadasi idoben spamszurest, inkabb az a jellemzo, hogy a bejovo queuebol megy a spamellenorzes, igy az SPF miatti kidobasrol nem ertesul a tovabbitast vegzo szerver. Ami level meg ugye fennakadt a spamszuron, arrol semmilyen esetben sem dobunk vissza bounce mailt.

( kroozo v | 2023. 04. 25., k – 11:46 )

Aktiváló link újra küldésére nincs lehetőség afaik. 

Telefonos vagy személyes üf. 

( Fisher v | 2023. 04. 25., k – 11:50 )

"a jelenlegi email címhez tartozó aktiváló linkre nem lett kattintva és az csak 24 óráig él"

Ebbol en azt remelnem, hogy elobb-utobb ujbol lehet regisztralni azt a cimet.

( ricsip v | 2023. 04. 25., k – 12:21 )

Szerkesztve: 2023. 04. 25., k – 12:21

jó is h. mondtad, beléptem a freemail fiókomba. Évek óta nem voltam ott, átiranyítas volt beállítva már legalább 10 éve a másik email címemre. Amúgy csodalkoztam is régebben, h. nem nagyon jöttek freemail-es levelek a másikba, pedig évekig megkaptam perfektül. Most belépéskor egy totál üres inbox fogadott. Illetve 1 rendszerüzenet h. mivel 90 napnál régebben léptem be utóljára, minden régi levelemet törölték és passziválták a fiókomat. Ez utóbbi azt jelentette h. mindenkinek aki küldött erre a címre nekem levelet, visszapattant az üzenet. De most a mai belépés örömére ismét aktív lett a mailboxom.

( Ebcsont | 2023. 04. 25., k – 12:30 )

2 frímél+ 1dzsímél+Thunderbird kombót használok. A frímélesekről levetettem az automata IMAP frissítést, az egyiknél megmaradt az átirányítás. Töredékére esett vissza a szpem. A kecske is megmaradt és a káposzta is jól lakott.

( pch v | 2023. 04. 26., sze – 07:30 )

Nekem az alis email nem akar mgjönni freemail-re. Már mindenütt ahol tudtam hanyagoltam a freemail-t, de az alin a kód se jön meg, hogy átírjam a mailcímet :(

Gmail-ba meg a fizetési bizonylatom nem jön meg. Pedig ugyanarról küldött sima mail meg megjön..

pch
SB-soft online ügyviteli rendszer

( zoyo | 2023. 04. 26., sze – 13:36 )

A Freemailemet hónapok óta, mióta átraktak IMAP-ra nem tudja elhozni a GMail. Akkor eljátszottam vele 1-2 órát, de hiába, úgyhogy elengedtem. Érdekes, hogy Edison-nak nem okoz gondot.