[megoldva] Néhány szerver visszadobja az emailt

UNIX kezdő

Sziasztok,

Interworx szervert használok, centos oprendszeren.
Minden jól működik, de van egy kis gond.

Néhány szerver visszadobja a kiküldött emailemet, mint ha spf hibát olvasnék ki ebből, de nincs is spf recordom, és a webszerveren sem tudok ilyen beállításról.

Bemásolom a hibát, mit jelenthet ez, vagy mit kéne átállítanom hozzá?:

Delivery to the following recipient failed permanently:

mail@******

Technical details of permanent failure:
Message rejected by Google Groups. Please visit http://mail.google.com/support/bin/answer.py?hl=en&answer=188131 to review our Bulk Email Senders Guidelines.

----- Original message -----

X-Received: by 10.180.198.142 with SMTP id jc14mr12839553wic.32.1444057081917;
Mon, 05 Oct 2015 07:58:01 -0700 (PDT)
Return-Path:
Received: from webszerver (webszerver. [0.0.0.0])
by mx.google.com with ESMTPS id cl14si31423824wjb.118.2015.10.05.07.58.01
for
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Mon, 05 Oct 2015 07:58:01 -0700 (PDT)
Received-SPF: neutral (google.com: 0.0.0.0 is neither permitted nor denied by best guess record for domain of email@email.hu) client-ip=0.0.0.0;
Authentication-Results: mx.google.com;
spf=neutral (google.com: 0.0.0.0 is neither permitted nor denied by best guess record for domain of mail@mail.hu) smtp.mailfrom=mail@mail.hu
Received: (qmail 27533 invoked by uid 108); 5 Oct 2015 16:57:46 +0200
Received: from unknown (HELO ?192.168.0.6?) (email@email@0.0.0.0)
by webszerver with ESMTPSA; 5 Oct 2015 16:57:46 +0200

szerk.: van amelyik webszerver ezzel dobja vissza:
Sorry. Although I'm listed as a best-preference MX or A for that host,
it isn't in my control/locals file, so I don't treat it as local. (#5.4.6)

Szerk.: Végül is arra jöttem rá, hogy a gmail mindenképpen igényli a spf record létezését, szóval beaplikáltam azt is, és így működik, a probléma megoldódott.
Köszönöm mindenkinek a segítséget.

  • 3243 megtekintés

( tigrincs | 2015. 10. 08., cs – 21:42 )

"de nincs is spf recordom"
Hat mondjuk kezdhetned azzal hogy legyen meg dkim es dmarc is.
Az pluszban jo lenne ha kiderulne hogy min keresztul kuldesz illetve hogy mit.

Ezen elindulhatsz:

spf rekord: (xxx a mailszervered ip-je)
v=spf1 a mx ip4:xxx.xxx.xxx.xxx -all

dkim rekordod
TXT mail._domainkey.mydomain.com
Publikus kulcsod amit generaltal

DMARC-al megadhatod, hogy ha a level elhasal az SPF es DKIM check-en akkor mi tortenjen pl:

none ( ez az alap mikor elkezded hasznalni ekkor nem utasitjak el de megkapod listaban, hogy volt e naluk fail es kiderulhet, hogy valaki a nevedben kuldozget levelet )

Kesobb ezt erdemes rejectre allitani ( mikor biztos vagy abban hogy az osszes felhasznalod rajtad keresztul kuld levelet es minden rendben van a mailszerverrel)

Ez az en dmarc rekordom a tesztidoszak alatt:
domainem kicsereltem mydomainre ertelemszeruen ;)

txt _dmarc.mydomain.com
v=DMARC1; p=none; rua=mailto:postmaster@mydomain.com; ruf=mailto:postmaster@mydomain.com

( gergelykiss | 2015. 10. 08., cs – 21:47 )

Spam-gyanúsnak ítéli meg a Google a kiküldött leveleidet, aminek 1000+1 oka lehet sajnos... :(

Néhány a leggyakoribbak közül:

  • valaki a múltban spamküldésre használta a szervered IP-címét, esetleg egy másik címet a tartományból -> itt ellenőrizheted, hogy szerepel-e a szervered IP-címe valamilyen nyilvános feketelistán. Ha igen, próbáld meg a címet levetetni a listáról vagy kérj a szolgáltatótól egy másik IP-t (VPS-szolgáltatóknál sajnos gyakori az ilyesmi, mivel relatíve olcsó ezeknél szervert bérelni, és kevésbé hozzáértő emberek, de akár spamküldők is előszeretettel használnak VPS-eket)!
  • feltörték a szervert vagy egy email fiókot és spamküldésre használják -> nézd át a levelezési és a bejelentkezési logokat, hátha találsz bennük valami gyanúsat, és futtass egy rootkit keresést (pl. a Rootkit Hunter-rel)
  • túl sok leveled küldesz a Gmail felé -> itt a "túl sok" fogalmát sajnos nehéz definiálni, de ha mondjuk óránként 2000 levelet elküldesz, azzal már jó eséllyel gyanús lehetsz a Google szemében
  • nincs SPF rekord -> jegyezd be a DNS-be! Itt egy hasznos tool, ami segíthet, ha nem vagy teljesen képben.
  • nem használsz DKIM-et -> ez már picit kevésbé elterjedt megoldás, de növelheti a szervered reputációját, ha DKIM-kulccsal aláírod a kimenő leveleket
  • végül a legalattomosabb: tőled, vagy egy korábbi IP-használótól olyan levelek mentek ki, amiket túl sokan jelöltek meg spam-nek, noha valójában nem azok. A Google eléggé komolyan veszi a felhasználók visszajelzéseit, és csak sok-sok köteg zöldhasú ellenében hajlandó fehérlistázni a szerveredet, hogy ne menjenek a leveleid spam-be. Elég komplex spamszűrőt használnak, amit sokszor piszok nehéz "kijátszani" (vagyis, rájönni, hogy mi a konkrét kiváltó ok, amiért spam-be megy a leveled). Előző munkahelyemen foglalkoztunk (legális) eDM-küldéssel, ott szembesültem ezzel. Ez jellemzően a levél tartalmára szűr, nem a metaadatokra, úgyhogy a te esetedben valószínűleg ennek a legkisebb az esélye (hacsak nem tényleg spam-et próbálsz küldeni :).

Egyébként az a "client-ip=0.0.0.0;" kicsit gyanús nekem, ez így szerepelt a levél forrásában, vagy csak kinulláztad a tényleges IP-címet?

( andrej_ v | 2015. 10. 08., cs – 22:48 )

Ha a reverz, forward és helo name egyezik, akkor ha még SPF rekord is van, akkor nemnagyon szoktak spambe pakolni. Érdemes a senderbase.org -on csekkolni az IP reputációt, mert elég sok enterspájz cucc használja és az mxtoolbox.com -on pedig a dnsbl-eket.

( _Franko_ v | 2015. 10. 09., p – 12:01 )

Ér ez az egész annyit, hogy szopjál a levélküldéssel? Én egy ideje áttettem a levélküldést a Google Apps-ra, a közelébe nem kerülök a napi 2000 recipients határnak és azóta teljesen kisimult vagyok. :)

Nem a Tiedről van szó, a teljes kifelé menő levelezésről, kb. ennyit kell felvenni (Postfix esetén):

smtp_sasl_security_options = noanonymous
relayhost = [smtp-relay.gmail.com]:587
smtp_use_tls = yes
smtp_tls_CAfile = /etc/postfix/cacert.pem
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/passwd

Kell egy cert, egy név/jelszó páros a passwd fájlba és a teljes levelezés kifelé ezen át fog menni...

--
https://portal.gacivs.info

"Gondolom klasszikus shared hostingos szerver és sokmindenki szeretne emailt küldeni."

Akkor tovább kell menni egy saját VPS-re... vagy végiggondolni, hogy kiket enged az ember a szerverére vagy végiggondolni az üzleti modellt a levelezés mögött vagy ésatöbbi. De ez így csak vergődés lesz, napról-napra egyre több probléma fog előjönni, amit a kellő hozzá nem értés csak súlyosbít.

--
http://wiki.javaforum.hu/display/~auth.gabor/Home

De, ez is része a kérdésnek... lépj vissza egyet és nézd távolabbról a problémát, tedd fel a kérdést, hogy mi az (üzleti) igény és azt mivel lehet kielégíteni. Te választottál egy olyan technológiát, aminek a működését nem ismered eléggé, illetve nem is tudod a szükséges feltételeket biztosítani, szóval teljes biztos, hogy különféle spam szűrőkön el fognak akadni a levelek...

...felesleges ezzel napról-napra szívni, de Te tudod.

Hat ha ilyen gondok vannak akkor ezt nem teteznem meg azzal hogy raszabaditom a vilagra a webtarhelyen futo cuccok(formok etc) webrol valo levelkuldozgeteseit is.

elso tennivalo:
PHP fuggvenyes mailt letiltani a 3,14 csaba mielott a "jol beallitott" mailt ropira torik es elkezdenek rola spammelni.( majd ha tudod mit csinalsz visszakapcsolhatod bar a mai vilagban en auth nelkul localhostrol meg se mashonnan nem engedek kuldeni )
Masodik lepes:
Legyenek rendben a rekordok es mukodjon rendesen a mail egy domainra.

Miutan mukodik a levelezes a webes cuccoknak csinalni kulon auth-ot/domain + latogato(egyeb forgalmi szamtol ide helyettesitsed be ami legjobban passzol) szamtol fuggoen rajukpattintani egy quotat is.

Account spoofing ellenorzest bekapcsolni ne engedd a juzereknek a mindenfele mas domaines vagy fals cimek hasznalatat azert mert tudnak egy cimet amivel lehet rajtad keresztul authentikalni.

Ha van mukodo SPF DKIM combo DMARC rekord tarsasagaban az hidd el tenyleg javitja a kezbesitesi aranyt nagy szolgaltatok fele. Plane ha nagy tomegben erkezik a szerverrol level.
Igy ok azt latjak hogy itten van egy fasza IP ami kuldozget egy csomo domain neveben mindenfele levelet 600 fele cimrol rendes SPF es DKIM beallitasok nelkul. Hmmm lehet hogy spammer?

Outlook.com illetve Yahoo fele tomegesen uzenetet kuldeni DMARC illetve a Bulk sender FAQ tanulmanyozasa nelkul kb eselyed sincs mert olyan gyorsan fognak blacklistre tenni hogy csak nezel ki a fejedbol.

Es baromira nem egyszeru lekerulni ezekrol...

Csak ez a hiba számomra érthetetlen. spfel csak macera van ezért nem lett beállítva. Csak azt gondoltam ha nincs beállítva akkor nem is adhat ilyen hibaüzenetet.
dmarc, dkim eddig is be volt állítva, és php mail sincs engélyezve, meg még egy sor másik függvény. Továbbá tűzfalban tiltva van az email küldés és hasonló tevékenységek, csak az smtp szervert engedi ki, mert php függvényekből is tudnak "smtp szervert" csinálni, ez tapasztalat...

Ez valamilyen looping hiba (554. 5.4.6) vagy nincs felkonfiguralva helyesen a qmail ( ha jol latom hogy az a MAIL ).
Ez nem valami pleskes webalapu konfigos csoda?

Ha igen akkor ezeket megneznem:

the domain really does not exist in Plesk, but the domain's DNS points to your server as the domain's MX
the domain exists but domain.com > Mail > Disable option was chosen in the Plesk interface
the domain exists and the domain was added to the above files but Qmail failed to restart (Qmail reads these files during start-up only)
the domain exists but the domain was not added to the above files because of some failure during domain creation or the files were modified manually.

( andrej_ v | 2015. 10. 09., p – 14:31 )

szerk: Hát a best MX visszavágja, akkor tovább kéne mennie a másodikra a cuccodnak, ha meg nincs több MX a domainnél, akkor nem a te gondod.