Изпечатай

[laskov]

Ако пощенските сървъри, които поддържате са твърде стриктни, може да не получавате писмата от НАП:

relay=mail-eu.nap.bg [212.122.164.53] (may be forged),reject=451 4.1.8 Possibly forged hostname for 212.122.164.53

а сега трябва да получите протоколите за ДДС декларациите.

[Naka]

Какво означава 'forged hostname'?

mail-eu.nap.bg не се резолва.

[Acho]

И при мене не ресолва името mail-eu.nap.bg Но пък като запитам нейм сървъра ми за адреса 212.122.164.53, виждам че сочи към mail-eu.nap.bg Явно си има обратен ресолв.

[romeo_ninov]

И при мене не ресолва името mail-eu.nap.bg Но пък като запитам нейм сървъра ми за адреса 212.122.164.53, виждам че сочи към mail-eu.nap.bg Явно си има обратен ресолв.

nap.bg  MX preference = 10, mail exchanger = mail.nap.bg
И за срамотите е само един

[Acho]

Да :

Domain name mail-eu.nap.bg does not exist in database!

Пак някой кадърен админ е пипал DNS-а, а пък сериала е -> Serial=2010022601

26 Февруари 2010 година, първа редакция на зоновия файл. Доста време е минало оттогава, и няма кой да го фиксне.

[laskov]

Какво означава 'forged hostname'?

Да речем, че ти разполагаш с IP адреса 212.122.164.53 и с DNS сървъра, който е авторитетен за този IP адрес, т.е. когато бъде запитан сървъра

dig -x 212.122.164.53

и той ти връща името на хоста, който е на този адрес. Ти си си направил един пощенски сървър, който да изпраща писма от този IP адрес, дал си му име mail.банка.com и си го написал и в DNS зоната за обратен резолв, така че при горното запитване, DNS-ът потвърждава, че това е машината mail.банка.com. Остава да започнеш да пращаш писма от името на банката с покани от рода "Моля напишете си името и паролата и отговорете на този e-mail". Можеш да пращаш спам от името на когото си поискаш.
Но някои приемащи писмата сървъри, след въпроса

dig -x 212.122.164.53

на който в случая се получава отговор "mail-eu.nap.bg", правят и запитване

dig mail-eu.nap.bg

, на което отговаря DNS сървъра за домейна nap.bg и той в случая казва, че такъв хост няма. А може да каже, че има, но е на съвсем друго IP. В този случай приемащият пощенски сървър счита, че името на изпращащия сървър е подправено (forged), т.е. той се представя за някой, който всъщност не е.
Би могло да се направи и проверката

dig -t MX nap.bg

, при която се вижда, че пощенски сървър с име mail-eu.nap.bg наистина не съществува. При това положение най-естественото решение за приемащия пощенски сървър е да откаже да приеме писмото.

[addict]

Само да отбележа за изпращане на поща не ти трябва mx запис, а A запис и това е по RFC.
Освен това повечено сървъри не трябва да спират поща ако я няма в обратен запис и това трябва да го знае всеки, които администрира пошеснки сървър.

Какво означава 'forged hostname'?

Да речем, че ти разполагаш с IP адреса 212.122.164.53 и с DNS сървъра, който е авторитетен за този IP адрес, т.е. когато бъде запитан сървъра

dig -x 212.122.164.53

и той ти връща името на хоста, който е на този адрес. Ти си си направил един пощенски сървър, който да изпраща писма от този IP адрес, дал си му име mail.банка.com и си го написал и в DNS зоната за обратен резолв, така че при горното запитване, DNS-ът потвърждава, че това е машината mail.банка.com. Остава да започнеш да пращаш писма от името на банката с покани от рода "Моля напишете си името и паролата и отговорете на този e-mail". Можеш да пращаш спам от името на когото си поискаш.
Но някои приемащи писмата сървъри, след въпроса

dig -x 212.122.164.53

на който в случая се получава отговор "mail-eu.nap.bg", правят и запитване

dig mail-eu.nap.bg

, на което отговаря DNS сървъра за домейна nap.bg и той в случая казва, че такъв хост няма. А може да каже, че има, но е на съвсем друго IP. В този случай приемащият пощенски сървър счита, че името на изпращащия сървър е подправено (forged), т.е. той се представя за някой, който всъщност не е.
Би могло да се направи и проверката

dig -t MX nap.bg

, при която се вижда, че пощенски сървър с име mail-eu.nap.bg наистина не съществува. При това положение най-естественото решение за приемащия пощенски сървър е да откаже да приеме писмото.

[laskov]

1. Ми то повечето компютри не трябва да пращат спам, но го правят! Затова сървърите трябва да са конфигурирани така, че за отсрещната страна да е ясно, че си "говорят" с надежден източник, а не със зомбиран Windows.
2. За пращащият писма нищо не е важно. Особено ако е НАП. Това, че получателите не получават писмата си е техен проблем!
3. Не знам какво трябва да знае всеки, който администрира пощенски сървър, нито смятам да уча някого, нито пък ще седна да чета RFC-та. Ако някой иска да прочете нещо кратко и полезно, ето - Best practices (на английски).

[Acho]

Разбира се, че винаги трябва да се държи на обратния ресолв при мейлерите. Като не съвпада проверката -> мъна. Никаво приемане от такъв. Да ме извини addict, ама от непроверени сървъри не приемам и не релейвам писма.

[runtime]

Не защитавам никой ама точно от нечетенето на RFC-та стават с извинение кавалски работи из мрежата.. Общо взето като почне всеки да прави каквото му хрумне и ...

 

[gat3way]

Само аз ли не съм убеден, че има особено голям смисъл да сверяваш A и PTR записите на sender-а? Според мен в днешно време, това няма особен смисъл и често създава повече проблеми, отколкото решава.

[laskov]

gat3way, погледни http://spamassassin.apache.org/tests_3_3_x.html и виж тестовете, свързани с DNS и RDNS. Относно MX записите и изпращача addict е прав, но хората от spamassassin са счели, че и те трябва да бъдат проверявани. Не казвам, че за изпращача трябва да има MX запис.

[gat3way]

Прекалено висок резултат са дали за reverse DNS проверките според мен, но те си се занимават и те си знаят. Въпреки това, мен ми се е случвало да си ровя из спам папката и честно казано, по-голямата част от спама си идва от съвсем легитимни сървъри, които си имат съответстващ PTR запис, дори съм се връзвал и съм правил VRFY срещу изпращача и ми се е връщало че такъв акаунт реално съществува. Според мен, огромна част от спама идва от разни ботнети. Писачите на ботнетите въобще не са тъпи хора и знаят как да вземат SMTP или Exchange настройките на инсталираните мейл клиенти. Дори 1/10 от заразените машини да имат инсталиран и конфигуриран мейл клиент е достатъчно да изпратят доволно много спам. И сървъри, които разчитат само на проверки дали PTR и A записите съвпадат или пък дали сървъра не е в някакъв abuse списък, спокойно ще приемат тези писма. В крайна сметка, аз си имам домашен пощенски сървър и нямам PTR запис, въпреки което GMail примерно приема поща от мене, за разлика от _%$@%_ от mail.bg например. При това, досега много рядко ми се е случвало да видя спам в inbox-а, google вършат добра работа с антиспам софтуера. Та очевидно има доста по-ефикасни средства за борба със спама от такава проверка. Това е все едно като стане мач ЦСКА-Левски, полицията да прибира хората със сини и червени дрехи. Няма значение колко хора ще го отнесат без да са хулигани и няма значение че никой не е казал, че хулиганите трябва да носят дрехи в такива цветове.

[Naka]

Само аз ли не съм убеден, че има особено голям смисъл да сверяваш A и PTR записите на sender-а? Според мен в днешно време, това няма особен смисъл и често създава повече проблеми, отколкото решава.

И аз мисля че създава повече проблеми, отколкото решава.

Правилният начин за борба със спама е да се използват базите данни черни листи като например cbl.abuseat.org bl.spamcop.net spamhaus.org ...
Всякъкви други работи са разни акоробатики дето могът да орежат някое важно писмо.
/като например от НАП сървера/
Ако имате важна бизнес корепонденция много по-важно е да получите някое писмо отколкото да не го получите - даже с цената на едно две промъкнали се SPAM писма.

[gat3way]

Правилният начин е този протокол да се изхвърли от употреба в този си вид и да се замени с нещо доста по-неудобно и по-спорно от privacy гледна точка. Само дето това няма да стане, защото проблемът е силно политически и защото би имало доста хора, които ще изреват на умряло. Това би могло да стане по следния начин: всички писма задължително се подписват и съответно си има проверки дали са подписани от хора, чиито публичен ключ е подписан от някакво trusted CA. Както браузърите, така и мейл клиентите ще имат списък от trusted CA-та, от които приемат поща. Електронната поща ще стане платена услуга, ако искаш да си сигурен, че ще ти получат съобщението, което е лошата страна на нещата. От друга страна, в момента, в който някой се зарази и почне да праща спам, сертификата му се revoke-ва и дотам бяхме. Това ще троши доста процесорно време, ще докара много политически проблеми и рев, докато се избистри, но веднъж въведено, ще сработи. Понякога, колкото и да е тъжно, човек трябва да пожертва свободата си за сметка на сигурността и това е един от тези случаи. В противен случай всичко ще си остане надпревара между спамъри и антиспам софтуер, от което печелят единствено производителите на антиспам софтуер, както и спамърите.

Имам предвид, до голяма степен работи спрямо фишинга, въпреки че той продължава да съществува като понятие. Ако го нямаше HTTPS протокола, сега веб-а щеше да бъде същата кочина, каквато е smtp в момента - може би дори по-близо до момента, в който е станал неизползваем. Проблемът е много прост - на кого имаш доверие и на кого нямаш и има отдавна измислени решения на този проблем. Не са перфектни, но работят за голяма част от случаите. Много по-голяма, отколкото тази, която разните антиспам софтуери могат да хванат.