Fórum Root.cz
Hlavní témata => Server => Téma založeno: TomasP 23. 10. 2012, 15:59:43
-
Zdravím, předem se omlouvám za OT, ale určitě tu najdu odborníka co poradí.
Mám problém s google apps, konkrétně emaily, doména rada.cz.
1) docela dost mailů padá do spamu, dá se tomu zabránit?
2) Při testu SMTP to píše "Reverse DNS does not match SMTP Banner" co s tím? Nejspíše kvůli tomuto problému nechodí dost důležité maily...
http://mxtoolbox.com/SuperTool.aspx?action=mx%3arada.cz
Díky za rady!!!
-
Nesouvisí to přímo s Gapps. Většina dnešních poštovních serverů si ověřuje, že reverzní záznam na IP adresu ukazuje správně doménu. Jinými slovy, že funguje tohle:
$ host sup.iinfo.cz
sup.iinfo.cz has address 213.151.94.187
$ host 213.151.94.187
187.94.151.213.in-addr.arpa is an alias for 187.128-191.94.151.213.in-addr.arpa.
187.128-191.94.151.213.in-addr.arpa domain name pointer sup.iinfo.cz.
Neboli že dotaz na IP adresu odesílacího stroje vrátí opět původní doménové jméno. Tohle nemáš správně nastavené v DNS. Hledej: DNS a reverzní záznamy.
-
Děkuji za odpověď, ale má tedy ještě jeden dotaz - kde je mám hledat? V Google jsou poze MX, mám se obrátit na TELE3 (zde jsou DNS) nebo to najdu někde v administraci? Protože k souboru s mými DNS záznamy se asi těžko dostanu, to už bych si je (snad) uměl opravit.
Děkuji!
-
Určitě na držitele IP adresy, poradí ti whois. Držitel musí na IP adresu serveru nastavit správný zpětný záznam. Tedy aby ukazoval na tvou doménu, ze které odchází pošta.
-
2) Při testu SMTP to píše "Reverse DNS does not match SMTP Banner" co s tím? Nejspíše kvůli tomuto problému nechodí dost důležité maily...
Obávám se, že toto není závada, ale vlastnost Google Apps a obecně všech cloudovitých řešení. V podstatě to znamená, že server, vedený jako MX pro danou doménu − já vidím např ASPMX.L.GOOGLE.COM − se při navázání spojení představí takto:
$ telnet ASPMX.L.GOOGLE.COM. 25
Trying 2a00:1450:4001:c02::1a...
Connected to ASPMX.L.GOOGLE.COM..
Escape character is '^]'.
220 mx.google.com ESMTP gf1si5305905wib.47…ale reverzní dotaz na IP adresu mailserveru vrátí namísto mx.google.com toto:$ host 2a00:1450:4001:c02::1a
a.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.c.0.1.0.0.4.0.5.4.1.0.0.a.2.ip6.arpa domain name pointer fa-in-x1a.1e100.net.
Jediný, kdo by to mohl spravit, je Google, ale ten to opravovat jistě nebude. Na druhou stranu, stejný problém mají všichni, kteří používají Google apps, nebo i Gmail. Takže problém se spamem bych hledal někde zcela jinde.
-
Pravda. Neuvědomil jsem si, že ty MX záznamy vedou na Google. Opravit se samozřejmě musí záznamy poštovního serveru, což je v tomhle případě server Google.
-
Děkuji za info... Dostal jsem informaci, že některé emaily vůbec nedorazí - nemůže to být tím, že DNS vrací "truncated" a pak si nestáhne celou odpověď a vlastně to ani neodešle? Nebo to vše chápu úplně špatně a problém je jinde... ?
-
Děkuji za info... Dostal jsem informaci, že některé emaily vůbec nedorazí - nemůže to být tím, že DNS vrací "truncated" a pak si nestáhne celou odpověď a vlastně to ani neodešle? Nebo to vše chápu úplně špatně a problém je jinde... ?
To by skutečně mohl být problém. Ale v tomto případě se to nezdá. maximální délka zprávy, včetně DNSSEC podpisů, je 973 bajtů, bez DNSSECu dokonce jen 255. Takže by k oříznutí nikdy dojít nemělo (bez EDNS0 je podporováno 512 B, s EDNS0, které je potřebné pro DNSSEC pak je podporováno až 4 KB):
$ dig rada.cz mx +notcp +dnssec
; <<>> DiG 9.9.1-P2 <<>> rada.cz mx +notcp +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10957
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 5, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;rada.cz. IN MX
;; ANSWER SECTION:
rada.cz. 816 IN MX 40 ASPMX2.GOOGLEMAIL.COM.
rada.cz. 816 IN MX 50 ASPMX3.GOOGLEMAIL.COM.
rada.cz. 816 IN MX 1 ASPMX.L.GOOGLE.COM.
rada.cz. 816 IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
rada.cz. 816 IN MX 30 ALT2.ASPMX.L.GOOGLE.COM.
rada.cz. 816 IN RRSIG MX 5 2 3600 20121102085003 20121023085003 61340 rada.cz. bh166Hzz8+se0YXUrXvT2UA+RDL89Vd8cCMifDvUyv6QCOcxqre+NtV2 DPdFuTu7I7Mx5+lHzK5s7+qKOY65A3LDMdmlHBDw5rGqJdKiKGbL3frm fnQLSWvAwnrBEBQuXxU0KwoeW79NLR0OioL/s89go3DJ/VCd/NStT01O OLSHoxleH+dkxgsPmkonPjDnt3K4r7CjBjkvGejjrAtHJioJZJyE3Jwv 9kkH46V4Q+CzXsZHwLvRSzSCC9tKOFad3WGB8TdR1AqG4wjXzLvpBt6b ocstL3QsD1TQD22p5DsTs2XZ5g5Dd3+b7hpV3rZhDrUj0OPRXkOxMm1L Vn7Wu+CzEN+GKpHZGCQ1bDAiAqllwsLredG8Rxee1olwWnCcIchvSu1a 4Aqod8WezmIdxXoOVHD3z5KaVlDYcTWGxQ8=
;; AUTHORITY SECTION:
rada.cz. 816 IN NS ns4.tele3.sk.
rada.cz. 816 IN NS ns2.tele3.cz.
rada.cz. 816 IN NS ns1.tele3.cz.
rada.cz. 816 IN NS ns3.tele3.cz.
rada.cz. 816 IN RRSIG NS 5 2 3600 20121102085003 20121023085003 61340 rada.cz. V0QsZUUgBgqdBczx81m4cv8ulupZ5FWM+8PC1DcVYLplpoYBtVq47s3C fMI1VJRxihCZ7N6uuOTZUjylBbFqhgRVlKuyQuwrBbdnm5sci6g9J4ag iOMU6lAZIf0PrBxEfNpyK9cMT0InZL7w+nX82SFqfX20XBNukfvPByw5 byap8IwyBXMoNX/kDSyzwyEuyAvrUtNkrFGVo2glMib2VyWKoGFSdxRy N/iTtskUz3q0LGS+5knZFn8NRJmtlc2VDj9SFAZPPMwRRAns29eCtfi+ Ral6XMphMczwkiByhrA2FwfuoqEme7K0g5Nu0ieUShNCv936bwxHsUIJ X4WtNkjSJIhLpWVB6RV2wZrGcdbdE8CGaihrHbnBe5Eq8ohxEnMHd004 JbE7fVwqTNIdU+0SEwwnikKu65wzDrt5IN4=
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Oct 24 22:18:21 2012
;; MSG SIZE rcvd: 973
-
A můžete poradit KDE hledat chybu? Už mě fakt nic nenapadá, zde končí mé znalosti DNS. Ztrácí se maily např. z uniqua pojištovny, takže celkem důžežité, tak jsem z toho nějak mimo...
-
A musí to být problém v DNS? Obvykle se při debuggování e-mailové komunikace vyplatí kontaktovat provozovatele mailserveru, popřípadě mailserverů obou stran, a zeptat se, zda pošta skutečně odešla, zda byla přijata, nebo proč byla vyhodnocena jako spam. Jen nevím, jak se na takové dotazy bude Google tvářit.