Per **Retpoŝta plusendado** (en la angla *Email forwarding*) ĝenerale oni celas la operacion re-sendi retpoŝtan mesaĝon (liverita al unu retpoŝta adreso), al alia aŭ aliaj **retpoŝtaj** adresoj.

La termino *plusendado*, uzita por poŝto ekde longe antaŭ la ekzisto de elektronikaj komunikadoj, havas ne-specifan teknikan signifon, sed ĝi implicas ke la retpoŝto estis movita "antaŭen" al nova celloko.

Retpoŝta plusendado ankaŭ povas redirekti poŝton iranta al iu adreso kaj sendi ĝin al unu aŭ pli da aliaj adresoj. Inverse, retpoŝtaj eroj iranta al pluraj malsamaj adresoj povas konverĝi per fina plusendado al ununura adreso.

Retpoŝtaj uzantoj kaj administrantoj de retpoŝtaj sistemoj uzas la saman terminon parolante de ambaŭ servilo-bazita kaj kliento-bazita plusendado.

Servilo-bazita plusendado
-------------------------

La domajno nomo (la parton aperanta dekstre de @ en retpoŝta adreso) difinas la celan servilon (aŭ serviloj) por la responda klaso de adresoj.

```
Domajno ankaŭ povas difini rezervajn servilojn; ili havas neniujn leterkestojn kaj  *plusendas* mesaĝojn sen ŝanĝi ajnan parton de iliaj kovertoj.
```

Kontraŭe, *primaraj serviloj* povas liveri mesaĝon al la leterkesto de uzanto kaj/aŭ plusendi ĝin ŝanĝante kelkajn kovertajn adresojn. ~/. *plusendado-*dosieroj (vidu malsupre) provizas tipan ekzemplon de servilo-bazita plusendado al diversaj ricevintoj.

Retpoŝtaj administrantoj foje uzas la terminon **redirektado** kiel sinonimo por servilo-bazita retpoŝto-plusendado al diversaj ricevintoj. Protokolaj inĝenieroj foje uzas la terminon **Mediaciilon** rilate al plusendad-servilo.

Pro spamo, estas ĉiam pli sekure plusendi poŝton tra diversaj domajnoj kaj kelkaj rekomendas eviti ĝin se tio estas ebla.

### Uzoj de servilo-bazita plusendado al diversaj ricevintoj

Rolo-adresoj
info, vendoj, postmaster kaj similaj nomoj povas aperi maldekstre de @ en retpoŝtaj adresoj.

Organizo povas plusendi mesaĝojn celitaj por donita rolon al la adreso de la persono(j) nuntempe funkcianta en tiu rolo aŭ oficejo.

Pseŭdonimo-adresoj
Plejparto de domajn-nomoj gastigantaj servoj provizas servojn por poŝto-plusendado al alia retpoŝta adreso kiel leterkesto ĉe la Interreta Serva Provizanto de la uzanto; estas ankaŭ apartaj provizantoj de poŝto-plusendad-servojn. Tio ĉi permesas al uzantoj havi retpoŝtan adreson kiu ne ŝanĝas se ili ŝanĝas leterkestan provizanton.
Multoblaj aŭ ĉesigitaj adresoj
Kiam uzantoj ŝanĝas ilian retpoŝtan adreson aŭ havas plurajn adresojn, la uzanto aŭ administranto povas aldoni plusendadon de ĉi tiuj adresoj, se ankoraŭ validaj, al ununura, por eviti perdadon de mesaĝoj.
### Plusendado kontraŭ resendado

Simpla mesaĝ-plusendado ŝanĝas la kovertan ricevinton(j) kaj lasas la sendinto-kampon malplena. La "koverto-sendinto" kampo ne egaligas al la "De" kampo kiu Retpoŝta kliento-softvaro kutime montras: ĝi reprezentas kampon uzita en la fruaj stadioj de la SMTPa protokolo kaj poste konservita kiel *Reven-Voja* titolon. Ĉi tiu kampo tenas la adreson, al kiu poŝto-sistemoj devas sendi automatajn mesaĝojn — raportantaj livero-malsukceson (aŭ sukceson): Livera Stato-Sciigo.

Kontraŭe, la terminoj *resendado* aŭ *redistribuo* povas foje celi re-sendado de la mesaĝo kaj ankaŭ reverkado de la "kovertan sendinton" kampon. Elektronikaj poŝtaj listoj donas tipan ekzemplon. Aŭtoroj submetiĝas mesaĝojn al *reflektilo* kiu resendas al ĉiu lista adreso. Tiamaniere, aŭtomataj mesaĝoj (kiu raportas malsukceson liverante mesaĝon al ajna listo-abonanto) ne atingos la aŭtoron de mesaĝo.

Tipe, simpla mesaĝ-plusendado faras alinom-vastigon, dum vera, norma mesaĝ-plusendado, ankaŭ nomita *plusendado tout-court* oni utiligas por dissendolistoj. Kiam suplementaj modifaĵoj al la mesaĝo estas efektivigitaj, kiel por ŝajnigi la agon de Retpoŝtilo submetiĝanta novan mesaĝon, la termino *plusendado* fariĝas trompa kaj resendado ŝajnas pli taŭga.

Per la metodo de autentikigado de la sendinto nomata SendintPolitiko-Kadro (SPF), la domajno-nomo en la koverta sendinto restas submetata al ĝiaj reguloj. Sekve, SPF ĝenerale malaktivigas simplan mesaĝ-plusendadon. *Intra-domajna* redirektado kongruas kun SPF se la rilataj serviloj kundividas konsekvencan konfiguracion. Poŝtaj serviloj kiuj praktikas *inter-domajna* mesaĝ-plusendado povas rompi SPF eĉ se ili mem ne efektivigas SPF, t.e. ili nek aplikas SPFajn kontrolojn nek publikigas SPFajn rekordojn.

```
SendintReverkado-Plano ĝenerala plusendad-mekanismo kongrua kun SPF.
```

Kliento-bazita plusendado
-------------------------

Klienta plusendado povas okazi aŭtomate uzante ne-interaktiva kliento kiel poŝta rehaviga agento. Kvankam la rehaviga agento uzas klientan protokolon, ĉi tiu ekspedado similas *servilan plusendadon* pro tio ke ĝi tenas la saman mesaĝon-identeco. Koncernoj pri la koverto-sendinto indas.

### Mana kliento-bazita plusendado

Fina uzanto *mane* povas plusendi mesaĝon uzante retpoŝtan klienton. Plusendado *enteksta* citas la mesaĝon sub la ĉefa teksto de la nova mesaĝo kaj kutime konservas originalajn alligitaĵojn tiel kiel elekto de elektita titolojn (ekz. la originalo De kaj *Respondo-Al*.) La ricevinto de mesaĝo plusendita ĉimaniere ankoraŭ povas esti kapabla respondi al la originala mesaĝo; la kapableco tiel fari dependas de la la ĉeesto de la originalaj titoloj kaj povas implici mane kopiado kaj almetado de la rilatajn celadresojn.

Plusendanta *kiel alligitaĵo* preparas MIMEan alligitaĵon (de tipa mesaĝo/rfc822) kiu enhavas la plenan originalan mesaĝon, inkluzivanta ĉiuj titoloj kaj ajna alligitaĵo. Notu ke inkluzivante ĉiujn titolojn ĝi sciigas multe da informojn pri la mesaĝo, kiel la servilojn kiu elsendis ĝin kaj ajnan kliento-etikedon aldonita sur la leterkesto. La ricevinto de mesaĝo plusendita ĉi-maniere povas do malfermi la alligita mesaĝon kaj respondi rekte al ĝi.

Ĉi tiu speco plusendi efektive konsistigas *resendado* de la vidpunktoj koverto-sendinto kaj de la ricevinto(j). La mesaĝ-identeco ankaŭ ŝanĝas.

Historia evoluado de retpoŝta plusendado
----------------------------------------

RFC 821, Simpla Poŝta Translokigo Protokolo, de Jonathan B. Postel en 1982, provizis plusend-vojo por ĉiu ricevinto, en la formo de, ekzemple, @USC-ISIE.`ARPA, @USC-ISIF.ARPA: Q-@SMITH@ISI-VAXA.ARPA` — Nedeviga listo de gastigantoj kaj necesa celloko-leterkesto. Kiam la listo de gastigantoj ekzistis, ĝi servis kiel plusend-vojo, indikanta ke ĉiu gastiganto devis transsendi la poŝton al la sekvanta gastiganto sur la listo. Alie, en la kazo de nesufiĉa voj-informo sed kie la servilo sciis la ĝustan cellokon, ĝi povus preni la respondecon liveri la mesaĝon respondante kiel sekvas: 

```
S: RCPT TO:<Postel@USC-ISI.ARPA>
      R: 251 User not local; will forward to <Postel@USC-ISIF.ARPA>

```
La koncepto ĉe tiu tempo antaŭvidis la elementojn de la plusend-vojo movante al la *reven-voja* koverto de la sendinto dum la mesaĝo estis transsendita de unu SMTPa servilo al alia. Eĉ se la sistemo malinstigis la uzon de fonto-entrudado.

La enkonduko de la MXa rekordo, faris fonto-entrudado nenecesa. En 1989, RFC 1123 rekomendis akcepti fonto-entrudado nur por postiĝinta-kongrueco. Ĉe tiu punkto, simpla mesaĝa plusendado fariĝis la rekomenda ago por alinomo-vastigo.

simpla plusendado povas montri la fina cel-addreso eĉ kiam tio ne estis la intenco de la sendinto, sed ĝi povas esti utile uzita por alinom-vastigo ene de la sama servilo aŭ aro de kunordigitaj serviloj.

### ~/.`Antaŭaj` dosieroj

La referenca SMTPa efektivigilo en la frua 1980aj jaroj estis sendmail, kiu estis provizita per ~/.`Antaŭaj` dosieroj, kiuj povas enteni la celan retpoŝt-adresojn por donitaj uzantoj. Ĉi tiu speco de servilo-bazita plusendado estas foje nomita *punkto-plusendado*. Oni povas agordi retpoŝt-programaj filtriloj por aŭtomate realigi plusendadon aŭ respondajn agojn tuj post ricevado. Plusenddosieroj ankaŭ povas enhavi skriptojn, kiuj fariĝis fonto de multaj sekurecaj problemoj. Antaŭe nur fidataj uzantoj povis utiligi la komand-linian ŝaltilon por fiksi la kovertan sendilon, `-f` `*arg*`; kelkaj sistemoj malfunkciigis ĉi tiun ĉefan kaŭzon de sekurecaj problemoj.

Retpoŝto ekaperis antaŭ la formaligado de kliento–servilaj arkitekturoj en la 1990aj jaroj.
Sekve, la distingo inter kliento kaj servilo ŝajnas trudita. Origine oni distingis inter dajmonoj kaj uzanto-kontrolitaj programojn, kurantaj sur la sama maŝino. La dajmono sendmail estis uzata kun radikaj privilegioj, do ĝi povis agi kiel ajna uzanto kies poŝton ĝi devis administri. Aliflanke, uzantoj povas aliri ilian propran individuan poŝto-dosieron kaj agordajn dosierojn, inkluzive ~/.`Forward`. Klientaj programoj povas helpi en redaktado de la servilaj agordo-dosieroj de donita uzanto, tiel kaŭzante konfuzon pri kiu rolo ĉiu programo ludas.

### Virtualaj uzantoj

La termino "virtualaj uzantoj" rilatas al retpoŝtaj uzantojn kiu neniam konektiĝas al poŝto-servila sistemo kaj nur aliras iliajn leterkestojn uzante forajn klientojn. Poŝto-servila programo povas labori por ambaŭ virtualaj kaj regulaj uzantoj aŭ ĝi povas postuli negravajn modifaĵojn utiligante la fakton ke virtualaj uzantoj ofte kundividas la saman sisteman *identigaĵon*. La lasta cirkonstanco permesas la servilan programon efektivigi kelkajn operaciojn pli facile, ĉar ĝi ne devas obei sistemon-aliraj restriktoj. La samaj principoj de operacioj aplikas. Tamen, virtualaj uzantoj havas pli da malfacileco en aliri iliajn konfiguraciajn dosierojn, kun avantaĝoj kaj malavantaĝoj.

Komercaj produktoj faciligantaj poŝtan plusendadon
--------------------------------------------------

* Forwardemail
* Emailforward
* Improvmx
* Forwardmx

Vidu ankaŭ
----------

* Retpoŝta Ĉenletero
* Dissendolisto
* Retpoŝta alinomo
* Retpoŝta Hibrida letero
* Listo de mallongigoj en retletera temo
* Retpoŝta spamo
* Poŝta uzanto agenta (MUA) .K.. Retpoŝta kliento
* Mesaĝa translokigo agenta (MTA)
* Retpoŝta ŝtormo

Notoj
-----

1. ↑  En sekcio 3.9.2 *List* of RFC 5321, la termino *forwarding* estas uzita ambigue. Ĝi notas ke "*la ĉefa diferenco inter mastrumi alinomoj (Section 3.9.1) kaj "forwarding" estas la ŝanĝo al la [*Reven-Pado *kapo]*." Tiu diraĵo, new w.r.t. RFC 2821, povus esti interpretita kiel la difino de *forwarding*, se la sama termino ne estus uzita je la komenco de la sama subsekcio kun la mala signifo. Kiel kontribuanto de RFC 5321 konsentis, [*rompita ligilo*]
2. ↑  La primara MX datenopo de la gravaj domajnoj kutime entenas la nomo de la poŝtservilo.
3. ↑  La *koverto* de mesaĝo estas la datumoj senditaj en SMTP transigo antaŭ la sendado de la *enhavo* de la mesaĝo.
4. ↑   2008-10-15
5. ↑  RFC 2142, *"Mailbox Names for Common Services, Roles and Functions"*, 1997, mencias ankaŭ *marketing*, *support*, *abuse*, *security*, *webmaster*, kaj aliaj.
6. ↑  
ISBN=0-596-00334-X