Skip to main content

Vandaag een mail gekregen van “Rablobank <bericht-klantenservice@kpnmail.nl> “

Geachte  xxxxxxxxxxxxxx

 

Er staat een nieuw bericht voor u klaar.

 

Klik hier (…) om het bericht te lezen.

 

Alvast bedankt voor uw medewerking.

 

Met vriendelijke groet,

Rabo klantenservice

 

M.vr.gr.  Jos

 

*Admin: link verwijderd i.v.m. onveilige site

*Admin: topic verplaatst naar juiste board

Waarom plaatst iedereen toch altijd maar die links naar dergelijke malafide sites?

Ik zal de moderators van KPN gaan vragen om de link te verwijderen.


@Spiediie, wat is het domein (alles achter @) van het e-mail adres waar je deze mail ontvangen hebt?


Rablobank? Werkelijk? Met de EL ertussen? En een bank zou natuurlijk altijd zijn eigen naam na het @ hebben.
Deze is wel heel doorzichtig.

Verder zal een bank vragen in te loggen op je eigen omgeving zonder daar de link van i.d. mail te zetten.

ABNAMRO doet overigens niets met e-mail. Alleen via bankmail i.d. bankomgeving.


ABNAMRO doet overigens niets met e-mail. Alleen via bankmail i.d. bankomgeving.

Maar niet iedereen zit bij de ABNAMRO.


Deze email is verzonden door bericht-klantenservice@kpnmail.nl.

Ik heb uiteraard ook een email adres van kpnmail.nl.

Bij mijn weten was dit de eerste keer dat ik zon mail kreeg vanuit kpnmail.nl. En dat vond ik opvallend.

Al tientallen pishing mail gekregen zogenaamd vanuit alle bekende banken. Nog niet gezien dat hier rablobank staat. Nu maakt dat ook weinig uit. Reageer nooit op dit soort berichten. Als je email adres nu eenmaal bekend is dan krijg je er elke dag. Daarom heb ik ook een ander email adres voor betrouwbare email verkeer. Denk ook niet dat banken zoals de ABN, ING en Rabo er iets tegen kunnen doen. Daarom moet iedereen ook ontzettend goed opletten.

Groeten  Spiediie


Deze email is verzonden door bericht-klantenservice@kpnmail.nl.

Dat wist ik inderdaad al.

 

Ik heb uiteraard ook een email adres van kpnmail.nl.

Zo vanzelfsprekend is dat niet, je had deze mail natuurlijk ook op een gmail of ander account binnen kunnen krijgen. Het is echter wel cruciale informatie immers de mail servers van KPN maken gebruik van spf, dmarc en dkim en dat betekent dat die mail ofwel als spam gekenmerkt had moeten zijn ofwel verstuurd is via een mailserver van KPN en dus gebruik makend van een KPN login.

 

@Dennis ABD, heb jij hier een andere verklaring voor?


Ik weet het niet precies.... wat ik wel weet: ik beheer een paar websites die bij diverse hosters staan. Ik daar in PHP ook mails versturen. Als afzender kan ik gewoon mn eigen persoonlijke kpn email adres gebruiken. En dat werkt gewoon. Mensen ontvangen die mail gewoon, kunnen gewoon op "beantwoorden" klikken in hun email programma en dan krijg ik die reactie gewoon in mn mailbox van KPN.


Ik weet het niet precies.... wat ik wel weet: ik beheer een paar websites die bij diverse hosters staan. Ik daar in PHP ook mails versturen. Als afzender kan ik gewoon mn eigen persoonlijke kpn email adres gebruiken. En dat werkt gewoon. Mensen ontvangen die mail gewoon, kunnen gewoon op "beantwoorden" klikken in hun email programma en dan krijg ik die reactie gewoon in mn mailbox van KPN.

Als die mails door de PHP functionaliteit via de smtp servers van KPN verstuurd worden, dan is er inderdaad geen enkel probleem. Worden die mails echter verzonden via een andere mailserver en is het domein van de afzender een KPN domein (@kpnmail.nl, @planet.nl, @hetnet.nl, etc.) dan voldoen die niet aan de spf (Sender Policy Framework) regels en zouden als spam gekenmerkt moeten worden.


Ik weet het niet precies.... wat ik wel weet: ik beheer een paar websites die bij diverse hosters staan. Ik daar in PHP ook mails versturen. Als afzender kan ik gewoon mn eigen persoonlijke kpn email adres gebruiken. En dat werkt gewoon. Mensen ontvangen die mail gewoon, kunnen gewoon op "beantwoorden" klikken in hun email programma en dan krijg ik die reactie gewoon in mn mailbox van KPN.

Als die mails door de PHP functionaliteit via de smtp servers van KPN verstuurd worden, dan is er inderdaad geen enkel probleem. Worden die mails echter verzonden via een andere mailserver en is het domein van de afzender een KPN domein (@kpnmail.nl, @planet.nl, @hetnet.nl, etc.) dan voldoen die niet aan de spf (Sender Policy Framework) regels en zouden als spam gekenmerkt moeten worden.

Gewoon via de mailserver van de hoster. Ik gebruik daar in die scripts niet mn gebruikersnaam en wachtwoord van KPN hoor 😁


Ik weet het niet precies.... wat ik wel weet: ik beheer een paar websites die bij diverse hosters staan. Ik daar in PHP ook mails versturen. Als afzender kan ik gewoon mn eigen persoonlijke kpn email adres gebruiken. En dat werkt gewoon. Mensen ontvangen die mail gewoon, kunnen gewoon op "beantwoorden" klikken in hun email programma en dan krijg ik die reactie gewoon in mn mailbox van KPN.

Als die mails door de PHP functionaliteit via de smtp servers van KPN verstuurd worden, dan is er inderdaad geen enkel probleem. Worden die mails echter verzonden via een andere mailserver en is het domein van de afzender een KPN domein (@kpnmail.nl, @planet.nl, @hetnet.nl, etc.) dan voldoen die niet aan de spf (Sender Policy Framework) regels en zouden als spam gekenmerkt moeten worden.

Gewoon via de mailserver van de hoster. Ik gebruik daar in die scripts niet mn gebruikersnaam en wachtwoord van KPN hoor 😁

Ook dat wijst er op dat spf niet goed zou functioneren. 

Ik wacht rustig de reactie van Dennis van het abuse team even af.

Het is in ons aller belang dat spf wel goed functioneert en dat mails met een afzender uit één van de KPN domeinen alleen verstuurd mogen worden via de mailservers van KPN zelf.


@kpnmail word regelmatig gebruikt voor spam. Het wil ook niet zeggen dat het via ons is verstuurd (meestal niet). Het is meestal een poging langs een spamfilter te komen. in de hoop dat wij mail van @kpnmail gewhitelist hebben.


En blijkbaar lukt het ook om de spamfilter te ontwijken immers de mails die via andere (niet KPN) mailservers verzonden worden en dus niet voldoen aan SPF, komen blijkbaar toch in de inbox.@Dennis ABD, dat zou toch niet mogelijk moeten zijn.


Inkomend checken wij geen SPF. Dit hebben we ongeveer een week gedaan maar gaf dusdanig veel problemen, zonder echt iets op te lossen, dat we hier weer mee gestopt zijn. SPF staat op grote schaal verkeerd geconfigureerd, daarnaast gaat het stuk bij forwards. Dit is niet zo'n issue in een corporate environment maar als ISP maakt dit SPF onbruikbaar.

 

Phishing komt helaas vaker door spamfilters heen, dit heeft echter niets te maken met het afzender adres. De nieuwe webmail omgeving moet hier een heleboel bij helpen, daar berichten sneller als spam gerapporteerd worden, daarnaast staan er voor na die tijd nog wat meer zaken op de rol waar deze migratie eerst voor afgerond dient te zijn.


Inkomend checken wij geen SPF. Dit hebben we ongeveer een week gedaan maar gaf dusdanig veel problemen, zonder echt iets op te lossen, dat we hier weer mee gestopt zijn.

Ik was in de veronderstelling dat SPF wel gechecked zou worden.

Is er de mogelijkheid om SPF alleen te checken voor een beperkt aantal domeinen namelijk de "eigen" KPN klantdomeinen (kpnmail.nl, planet.nl, hetnet.nl, etc.) zodat we als klant bij die domeinen er vanuit kunnen gaan dat deze in ieder geval van een valide mailserver afkomstig is.


Inkomend checken wij geen SPF. Dit hebben we ongeveer een week gedaan maar gaf dusdanig veel problemen, zonder echt iets op te lossen, dat we hier weer mee gestopt zijn. SPF staat op grote schaal verkeerd geconfigureerd, daarnaast gaat het stuk bij forwards. Dit is niet zo'n issue in een corporate environment maar als ISP maakt dit SPF.

Dit komt omdat veel websites / bedrijven hun nieuwsbrieven en andere mailings door een externe partij laten verzorgen en daarbij wel de originele domeinnaam als afzender (logisch ook) willen gebruiken?

 


Inkomend checken wij geen SPF. Dit hebben we ongeveer een week gedaan maar gaf dusdanig veel problemen, zonder echt iets op te lossen, dat we hier weer mee gestopt zijn. SPF staat op grote schaal verkeerd geconfigureerd, daarnaast gaat het stuk bij forwards. Dit is niet zo'n issue in een corporate environment maar als ISP maakt dit SPF.

Dit komt omdat veel websites / bedrijven hun nieuwsbrieven en andere mailings door een externe partij laten verzorgen en daarbij wel de originele domeinnaam als afzender (logisch ook) willen gebruiken?

Dan zal zo'n website/bedrijf gewoon een SPF record moeten maken voor de mailserver van de partij die de nieuwsbrieven en andere mailings voor haar domein(en) verzorgt.

Dat is nu juist waar SPF voor bedoeld is, controleren of de mail afkomstig is vanaf een mailserver die ook de permissie heeft om mails voor dat domein te vezenden.

SPF is mijns inziens cruciaal in het gevecht tegen spam.


Daar vergis je je in ;)

 

SPF word gechecked als onderdeel van DMARC, op zichzelf staand word het genegeerd. Zoals aangegeven valt SPF heel erg snel om, wat een hele berg met problemen opleverd. Daarnaast gaan forwards ervan kapot. Er zijn eigenlijk geen grote mailbox providers meer die iets doen met enkel SPF (Hotmail, Gmail, Yahoo) om precies die reden. Als onderdeel van DMARC is het echter wel wardevol en hier word uiteraard naar gekeken.


Reageer