Goedemiddag,

Ik loop redelijk plotseling tegen het probleem aan dat een formbuilder-formulier van een site bij providor-EH geen mail wil verzenden naar een adres met een niet-eigendomein-mailadres; ik krijg een melding :
- smtp 550 we do not accept mail from this address.

Verzendingen naar eigendomein-mailadressen verlopen oke. Providor-EH verwijst naar een hack van de site die onlangs is geweest (sinds ongeveer die betreffende datum bestaat dit probleem), want mailen vanuit webmail verloopt wel 100% oke.

- site is ge-update naar 2.2.28, vanaf 2.1.15, formbuilder is naar 0.8.1.6 gebracht, maar dat geeft geen oplossing.
- andere sites: 2.1.15, formbuilder 0.8.1.6, soortgelijke formulieren, zelfde providor, geven geen problemen.

Als het probleem dan inderdaad 'ergens' in de betreffende account zou zitten, waar moet ik het dan zoeken?
- ik heb uitvoerig alle vermeende hack-bestanden opgezocht en verwijderd (gedecteerd via ftp ahv schrijfdatum en vergelijken met andere CMSMS-sites
- de site functioneert verder naar behoren.

Dank voor je aandacht; groet, Wietze

Klinkt als een probleem met dat specifieke email adres, kan je wel vanaf een ander, nieuw, email adres mail versturen vanuit formbuilder?

Ik denk dat je je provider moet vragen deze ban op uitgaande email vanaf dit email adres te liften anders.

Nieuw eigendomein-adres: maakt geen verschil; verzenden naar meerdere adressen bijv eigendomein- en domeinvreemde adressen, gaat fout voor elk domein-vreemde adres, goed voor elk eigendomein-adres.

Aanvulling:
Ook bij verzenden van testmails vanaf de backend van de site (Instellingen - Algemeen : Mail-instellingen), is de situatie: testmails naar domein-vreemde adressen stranden, testmails naar eigendomein-adressen verlopen oké.

Ok, maar wat zegt je provider precies dan?

De providor doet tests via de formulieren op de site, ziet ook dat het fout loopt zoals geschetst, doet aanvullend vanaf hun positie tests mbt de werking van zijn mailserver, concludeert dat daar geen fouten optreden en geeft terug dat de fout dus optreedt vanuit de status van de site, dat daar iets fout gaat en dat zij daar niet verantwoordelijk voor zijn.
De providor stelt geen veranderingen mbt de mailserver te hebben doorgevoerd gedurende de laatste maand.

Feit is dat ik zelf kan constateren dat tot rond 12/13-07 de mailverwerking oké was, dat na het gerommel mbt de hack er sprake is van 'een andere verwerking' van de mail.

Op mijn constatering (en ticketverzending) vrijdagmiddag jl mbt het onderscheid tussen domein-eigen/vreemde mail is vandaag niet gereageerd.

Beetje onhandig dat ze niet reageren natuurlijk, betaal je voor deze dienst?

Je zou ook nog eens kunnen kijken of je je mail instellingen op Instellingen - Algemeen - Mail instellingen kan aanpassen naar een andere methode, bijv. smtp.

Reeds geprobeerd: mail/sendmail geven het zelfde resultaat; van smtp lukt het niet om alle instellingen goed voor elkaar te krijgen, maar eigenlijk heb ik ook daar weinig hoop....

Is een betaalde hosting in 020 (was oorspronkelijk Domeinhuis), met een telefonist die blijkbaar als opdracht heeft klanten vooral niet met de echte deskundigen door te verbinden, en alleen als ontkoppelpunt te dienen.

SMTP moet altijd werken eigenlijk aangezien je dan dezelfde methode gebruikt als je met iedere andere mail client zou gebruiken. Hoe heb je het geprobeerd?

Altijd welkom overigens om naar hosting in 015 te verhuizen trouwens

Ben nog nooit een shared hosting partij tegengekomen die toegang geeft tot logfiles van de mailserver.

Zonder ondersteuning is het lastig om eruit te komen.

Ik heb zelf een aantal .php scripten om mail servers te testen (sendmail, smtp etc...).

Je schreef een gehackte cmsms site gehad te hebben:

- Hoe heb je je website nu beveiligd?
- Hoe heb je getest dat er geen geinfecteerde bestanden meer aanwezig zijn?

Enfin om problemen met cmsms uit te sluiten kan kan je volgende php script in de root van je webserver plaatsen en draaien. Daarna gooi je hem weer weg.



Misschien is er van je domeinnaam wel zoveel spam uitgestuurd dat je nu op een blacklist staat. Grote kans dat er iets mis is met de configuratie van je web of mailserver. Een verkeerde cmsms configuratie of gemodificeerd cmsms bestand kan altijd ..... je zult alles na moeten gaan.

Zoals Tristan schrijft eerst een SMTP server testen met een 'gewone' mailclient en daarna via een 'website' is een goede tip.

Ken trouwens een goede vps provider in 010 ;)

Dank voor je reactie

- alle dir's nagelopen op wijzigingen/datums die niet van mij afkomstig waren; deze bestanden verwijderd; in Public.html, ook in root van het account. Ook vergeleken met andere CMSMS-accounts
- CMS naar laatste versie 2.2.28 (was 2.1.15), modules geupdate waar mogelijk.
- ftp toegang, overal ww's etc veranderd
- tests door providor zelf uitgevoerd

Volgens de hoster is er van een blacklist geen sprake

php-bestand, resultaat:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

check-auth@verifier.port25.com
host relay.denit.net [62.148.xxx.55]
SMTP error from remote mail server after MAIL FROM:<caravans@honk6.dooooohuis.nl> SIZE=1504:
550 we do not accept mail from this address.

Ik zou ook nog een cmsms checksum doen, dat de datum van een bestand niet veranderd is zegt niet alles. Site Admin -> System verification.

Daarnaast zou ik een .htaccess bestand op de /admin zetten, zal niets uitmaken als die webserver lek is maar geeft wel wat extra beveiliging.

Het kan zou maar zijn dat er een andere hostnaam gehackt is en je provider alle accounts op een zelfde gebruikers naam draait en er zodoende toegang gekregen kan worden tot alle hosts.... en onderschat de kracht mogelijkheid tot misbruik van UDT's niet.

Enfin je provider weet hopelijk voldoende van webbeveiliging.
===

In eerste instantie verander je het $to en $from adres natuurlijk naar het emailadres wat overeenkomt met je domeinnaam, en kijk je wat er gebeurt.

check-auth@verifier.port25.com is een bestaand emailadres maar vooral bedoeld om smtp servers te controleren.

De standaard mail functie gaat waarschijnlijk via sendmail.
https://www.port25.com/authentication-checker/

Wat gebeurt er als je via je mail applicatie met smtp instellingen email uitstuurd? Deze settings zou je ook voor cmsms kunnen testen.

10 Bestanden niet gevonden
Bestanden niet gevonden:
/modules/CMSMailer/lang/ext/uk_UA.php
/admin/lang/ext/rm_CH.php
/admin/lang/ext/gl_GL.php
/admin/lang/ext/so_SO.php
/admin/lang/ext/eo_UY.php
/admin/lang/ext/uk_UA.php
/admin/lang/ext/mn_MN.php
/admin/lang/ext/vi_VN.php
/admin/lang/ext/iw_IL.php
/admin/lang/ext/fa_FA.php

21 Bestanden md5sum check komt niet overeen:
/modules/Search/lang/ext/rm_CH.php
/modules/Search/lang/ext/iw_IL.php
/modules/Search/lang/ext/fa_FA.php
/modules/MicroTiny/lang/ext/vi_VN.php
/modules/MicroTiny/lang/ext/iw_IL.php
/modules/MicroTiny/lang/ext/fa_FA.php
/modules/News/lang/ext/mn_MN.php
/modules/News/lang/ext/vi_VN.php
/modules/News/lang/ext/iw_IL.php
/modules/News/lang/ext/fa_FA.php
/modules/MenuManager/lang/ext/rm_CH.php
/modules/MenuManager/lang/ext/iw_IL.php
/modules/MenuManager/lang/ext/fa_FA.php
/modules/CMSMailer/lang/ext/iw_IL.php
/modules/CMSMailer/lang/ext/fa_FA.php
/modules/ModuleManager/lang/ext/rm_CH.php
/modules/ModuleManager/lang/ext/iw_IL.php
/modules/ModuleManager/lang/ext/fa_FA.php
/modules/FileManager/lang/ext/iw_IL.php
/modules/FileManager/lang/ext/fa_FA.php
/lib/phpmailer/class.phpmailer.php

Dit is het resultaat van de 2.2.8.checksum.

De 2.2.8 is wel pas geïnstalleerd na de hack-datum

Ik zou op een test account nog eens een verse 2.2.8 installatie doen en daar dezelfde checksum draaien.

Daarna alle modules die je ook op je live account hebt installeren en upgraden en een een md5 sum genereren die je vervolgens binnen je live-account test.

Afwijkende bestanden kan je dan van je test account naar je live account kopieren.

Weet niet of lang files in de checksum zitten?

Deze is mbt tot je mail problemen wel verdacht:

2.2.8 inmiddels ook op een sub dir geïnstalleerd

In: class.phpmailer.php blijken een paar regels in // comment te zijn veranderd; dit bestand heb ik derhalve vervangen vanuit de sub dir, maar dat maakt vooralsnog niet het verschil.
Voor de rest zijn in een nieuwe checksum nu nog 'ontbrekende' en installatiedatum-verschillen genoemd, alle zijn niet-(nl-NL)taalbestanden; daar kan toch eigenlijk niets verkeerds mee zijn.