Het "aan" adres heeft niets te maken met het adres waar de mail wordt afgeleverd. Het is alleen decoratie.
Bepalend is een "envelop" adres. Het is net als met een brief. Je kunt wel een brief schrijven met "aan: pietje puk" maar als je die in een envelop stopt met daarop "jan klaassen" dan komt ie bij jan klaassen terecht en als die hem uit de envelop haalt en er staat "aan: pietje puk" op dan kan die hem weggooien of wat die er ook mee wil.


De afzender is sowieso vals. Net als het aan adres is ook het van adres volslagen ongecontroleerd.
Dus je hoeft niet bang te zijn dat de afzender iets te weten komt of dat die dat ook maar iets interesseert.
Je kunt het dus gerust doorsturen, maar dat kun je ook gerust achterwege laten want er gebeurt waarschijnlijk toch niets mee verder. Gewoon deleten.

Voor banken staan dergelijke mailadressen waar je het kunt melden op https://www.veiligbankieren.nl/meld-fraude/.

Paypal staat daar niet bij, maar op https://www.paypal.com/nl/cshelp/article/hoe-herken-ik-frauduleuze-nep--of-phishingberichten-of--websites-van-paypal---help164 staat het mailadres wel.

Doorsturen naar deze speciale mailboxen zou geen probleem moeten zijn, maar sommige mailservers willen het wel eens tegenhouden omdat ze deze mailadressen (nog) niet hebben gewhitelist.

Je stuurt normaliter een raw text format door middels bron weergeven + mailheader en die te kopieren naar ze. Indien mogelijk kun je nog een kopie in archief meegeven in bijvoorbeeld .eml format.

De reden voor het rare adres is dat ze een BCC versturing doen met het aan als dummy.

Zolang je niet op linkt hebt geklikt of script uitvoering standaard aan hebt loop je minimaal risico. Enkel zerodays specifiek aan je email client, interface kunnen dan een gevaar vormen.

Of het nut heeft het te sturen niet echt. Dit zijn campagnes die duizenden krijgen en bedrijfs netwerken kunnen dit automatisch vaak rapporteren als particulier beetje zonde van je tijd.

Als je de mail doorstuurt moet je dat in elk geval doen als bijlage. Dan blijven alle headers intact en hebben de onderzoekers van de mail de meest correcte info.

En als PayPal hiervoor een apart mailadres heeft, zullen de ontvangers wel de ervaring hebben deze mail veilig te openen.

Wat als PayPal denkt dat jij de phishing mail hebt gemaakt?
Ik zou het rapporteren als spam en dan wissen uit zowel je inbox als je prullenbak.
Waarom zou je de mail bewaren? Straks komt het in je backups en worden je backups gewist door overijverige anti-malware software. Onder andere ClamAV heeft hier een handje van.

Als je het als bijlage verstuurd, lopen jij en de ontvangen geen enkel risico. Vermeldt dat je denkt dat het een phishing mail is, dan gaan ze er voorzichtig mee om. Daar hebben ze ondertussen wel ervaring mee.


Hoe zou de afzender dat dan moeten zien?
Jij verstuurd iets vanuit jouw mailbox als bijlage.

Of heeft de verzender jouw mailbox gehackt?
Dan heb je namelijk een veel groter probleem dan een ontvangen phishingmail.



De header info (of het werkelijke emailadres onder de alias bekijken) doe je allemaal binnen jouw mailbox. De verzender merkt daar niets van.

Of heeft iemand anders (een onbekende) toegang tot jouw mailbox?
Dan heb je namelijk een veel groter probleem. :-)

Wat Briolet schrijft klopt: stuur hem door als bijlage.

Dat is heel eenvoudig. Als jij een e-mail stuurt met een adres in "To:" en een ander adres in "Bcc:" dan zal de ontvanger met het tweede adres een e-mail krijgen met in "To:" het eerste, en dus een niet kloppend adres.

Het kan ook anders tot stand komen. E-mailservers wisselen onderling e-mails uit met het SMTP-protocol, en als je ouderwets een e-mailprogramma op je eigen pc hebt geïnstalleerd in plaats van webmail te gebruiken dan kan je e-mails direct vanuit dat programma bij je provider aanleveren met datzelfde SMTP-protocol. Het is gewoon vanaf de pc te gebruiken dus.

De grap van SMTP is dat het helemaal niet kijkt naar de e-mail en de e-mailheaders die daarin staan. De afzender en ontvangers worden als onderdeel van het communicatieprotocol doorgegeven, en dat is waar die servers mee werken. Een SMTP-dialoog is echt een soort gesprek tussen twee machines. Als je vanaf je pc een e-mail via SMTP naar een server stuurt komt het gesprek, vrij vertaald naar het Nederlands, hier ongeveer op neer:

pc: "Hoi, ik ben <computernaam van de pc>"
server: "Welkom, ik ben server <servernaam> en ik kan <zus en zo>"
pc: "Ik heb een e-mail van <afzender>"
server: "Ok"
pc: "Die moet naar <eerste email-adres>"
server: "Ok"
pc: "En naar <tweede email-adres>"
server: "Ok"
(en mogelijk nog veel meer emailadressen)
pc: "Hier komt de e-mail"
server: "Kom maar op, geef alle regels tekst en sluit af met een punt"
pc: <alle regels tekst die samen de e-mail vormen>
pc: .
server: "Ok, verzonden"
pc: "Doei"
<verbinding verbroken>

De server kan behalve "Ok" te zeggen ook adressen of andere zaken niet accepteren en een foutmelding geven. Dan mislukt het versturen van de e-mail. Maar als alles gaat zoals in dit voorbeeld dan is daarmee de e-mail verstuurd.

Het SMTP-protocol is heel grappig omdat het echt zo'n gesprek is, compleet met wat beleefdheidsvormen ("hoi" en "doei" zeggen, in het echt HELO en BYE). Het is een tekst-gebaseerd protocol en als je het zichtbaar weet te maken prima te volgen. De e-mail wordt ook helemaal als regels tekst verzonden. Zelfs binaire bijlagen, afbeeldingen, audiobestanden, noem maar op, worden in regels met teksttekens gecodeerd en dan pas verstuurd.

Zoals ik al schreef is e-mailadres dat jij te zien krijgt onderdeel is van de e-mail, van <alle regels tekst die samen de e-mail vormen> in bovenstaande dialoog. De mailservers kijken helemaal niet wat daar staat (dat is althans geen onderdeel van het SMTP-protocol, mogelijk wel van spamfilters en andere toegevoegde controles), maar ze gebruiken de in het protocol zelf opgegeven e-mailadressen voor de bezorging. Als je op dat niveau met een SMTP-server praat, en dat is helemaal niet zo moeilijk, dan kan je in de e-mail zelf een niet bestaand "aan"-adres gebruiken zonder dat de server daarover valt, want die kijkt daar helemaal niet naar, die kijkt naar wat in de dialoog is doorgegeven. Voor SMTP is de e-mail die jij ziet een verder totaal oninteressant stuk data dat alleen maar bezorgd moet worden.

Het lijkt best sterk op een papieren brief in een envelop. Daarin worden (bij een formele of zakelijke brief) in het briefhoofd de afzender en de ontvanger vermeld. Dat lijkt op de e-mail-headers die voor SMTP onderdeel zijn van de e-mail. Die brief kan in een envelop gestopt worden waarop het bestemmingsadres nog een keer wordt vermeld. Dat laatste wordt door PostNL en dergelijke gebruikt, die doen helemaal niets met wat er in het briefhoofd staat. Op dezelfde manier gebruikt SMTP alleen de adressen die in de SMTP-dialoog zijn doorgegeven. Die worden zelfs met de term "envelope" aangeduid. Een belangrijk verschil is dat bij papieren post de ontvanger de envelop te zien krijgt en de brief er zelf uithaalt, terwijl je bij e-mail als ontvanger de envelop niet te zien krijgt en een al uitgepakte brief ontvangt.

Het is overigens wel weer zo dat servers onderweg headers (bovenaan) toevoegen aan de e-mail. Als je als ontvanger alle headers bekijkt kan je dingen tegenkomen als "X-Envelope-To: <emailadres>", met het e-mailadres zoals in de SMTP-dialoog cq. de "envelope" voor jou is gebruikt, en dat kan dus anders zijn dan je in "aan" ziet staan.

(Ik heb dit allemaal uit mijn hoofd opgeschreven met twee biertjes achter de kiezen, dus ik heb vast wel ergens een steekje laten vallen. In grote lijnen klopt het beeld wel.)