>I ook ben met u totaal het ermee eens dat Y geen e-mail „zou moeten opslaan“, maar eerder „Store&Forward“ zoals u vermeldde.
Ik veronderstel die ben wat u van plan was te zeggen?
---
Om een beetje aan mijn vorige commentaar meer enkel toe te voegen terwijl ik hier ben: -
Als het domein fred.com toen was zou u opstelling kunnen
10 mail.fredx.com
20 mail.fredy.com
waar 10, 20 MX prioriteiten en mail.fredx.com punten aan X zijn; en mail.fredy.com punten aan Y. U registreert het domein fredy.com en reeks dat tot punt slechts aan Y.
(1) wanneer een post nu het fred.com domein raakt, wordt het of verpletterd aan X (normale stand van zaken), of het gaat naar de opslag en de voorwaartse server op Y.Y is opstelling die e-mail door:sturen op fred.com terug naar X worden ontvangen wanneer X om wordt bewezen omhoog te zijn.
(2) wanneer een post correct door X wordt behandeld, is er daar een globale Regel in die exemplaren al post aan Y. Zo als iemand een e-mail aan
[email protected] heeft geschreven zal het gekopi�ërd aan Y worden, maar zal doen dat de domeinnaam in fredy.com (anders zal het op zich vouwen, kon u e-mailadressen in feite gebruiken die domeinliterals om rechtstreeks aan Y gebruiken te richten b.v., jim@ [a.b.c.d] moet worden veranderd waar a.b.c.d het IP adres is waar mail.fredy.com verblijft). Zo zal de regel post aan
[email protected] aan
[email protected] kopiëren. Y ontvangt e-mail en neemt het waar om verschillend van zijn „Opslag te zijn &“ rol door:sturen en zal daarom het in de aangewezen brievenbus afleiden (Jim).
Ik dacht de manier om post te behandelen die aan Y met „recipient=fred.com“ kwam aan opstelling een regel zou zijn die „zei als de post duidelijk is aangezien recipient=fred.com dan een exemplaar naar de zelfde ontvanger in fredy.com“ verzenden. Dit zou dan alle eventualiteiten behandelen.
De zwakke verbinding in de ketting zou nu de Gastheer van uw DNS verslagen zijn.
