26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский




Название26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский
страница2/19
Дата конвертации25.02.2016
Размер3.35 Mb.
ТипДокументы
1   2   3   4   5   6   7   8   9   ...   19

4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ


Технические требования к техническим средствам службы обмена электронными сообщениями

в части службы электронной почты по протоколу SMTP приведены в Приложении 1.


Технические требования к техническим средствам службы обмена электронными сообщениями

в части службы электронной почты по протоколу POP3 приведены в Приложении 2.


Технические требования к техническим средствам службы обмена электронными сообщениями

в части службы электронной почты по протоколу IMAP4 приведены в Приложении 3.


Технические требования к техническим средствам информационных служб в части службы


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


доменных имен по протоколу DNS приведены в Приложении 4.


Технические требования к техническим средствам службы доступа к информационным ресурсам

по протоколу HTTP приведены в Приложении 5.


Технические требования к техническим средствам службы доступа к информационным ресурсам

по протоколу NNTP приведены в Приложении 6.


Технические требования к техническим средствам службы доступа к информационным ресурсам

по протоколу FTP приведены в Приложении 7.


5. ТРЕБОВАНИЯ К ТЕХНИЧЕСКОМУ ОБЕСПЕЧЕНИЮ


Используемые при создании ТС телематической службы средства вычислительной техники

должны иметь сертификаты системы ГОСТ Р, подтверждающие соответствие Российским

стандартам на средства вычислительной техники, эксплуатируемые в производственных

помещениях.


6. ТРЕБОВАНИЯ К НАДЕЖНОСТИ И ДОСТОВЕРНОСТИ


ТС телематических служб должны быть рассчитаны на круглосуточную работу без постоянного

присутствия персонала и технического обслуживания. Надежность хранения информации в системе

должна обеспечиваться применением аппаратно-программных методов организации данных с

применением стандартных носителей.


7. ТРЕБОВАНИЯ К ДИАГНОСТИКЕ


Диагностика аппаратной части и системного программного обеспечения ТС телематических

служб должна производиться средствами, поставляемыми предприятиями - изготовителями средств

вычислительной техники и программного обеспечения. Указанные средства должны включать

тестовое ПО комплекса технических средств телематических служб, обеспечивающее проверку

работоспособности ТС телематических служб и диагностику.


Средства диагностики сервера (узла) телематических служб не должны нарушать целостность и

корректность данных.


8. ТРЕБОВАНИЯ К ЭЛЕКТРОПИТАНИЮ


Система должна быть работоспособной при электропитании оборудования системы от


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


источников бесперебойного электропитания, обеспечивающих на выходе напряжение 220 В с

частотой 50 Гц и допустимыми отклонениями напряжения от минус 15% до +10% и частоты +/- 5 Гц.


В случае пропадания электропитания источники гарантированного питания должны обеспечить

работоспособность аппаратуры сервера (узла) телематических служб в течение не менее 5 минут для

выполнения корректного закрытия системы и выполнения процедур, обеспечивающих сохранность

информации.


9. ТРЕБОВАНИЯ К ЭЛЕКТРОБЕЗОПАСНОСТИ


И ЭЛЕКТРОМАГНИТНОЙ СОВМЕСТИМОСТИ


Технические средства телематических служб должны отвечать общим требованиям

электрической и механической безопасности, требованиям электромагнитной совместимости и

должны иметь соответствующий сертификат соответствия.


Конструкция и монтаж аппаратных средств системы должны исключать возможность

прикосновения обслуживающего персонала к токоведущим частям. Компьютеры и периферийные

устройства, входящие в состав ТС телематических служб, должны быть подключены к защитному

заземлению (занулению).


10. ТРЕБОВАНИЯ ПО УСТОЙЧИВОСТИ К КЛИМАТИЧЕСКИМ ФАКТОРАМ


ТС телематических служб должен оставаться работоспособным при температуре окружающего

воздуха от 5 до 40 град. С и относительной влажности от 20 до 80% (без конденсата).


ТС телематических служб должен сохранять свои параметры во всем диапазоне рабочих

температур при изменении напряжения первичного источника электропитания в допустимых

пределах.


11. ТРЕБОВАНИЯ К ДОКУМЕНТАЦИИ


В состав документации на ТС телематических служб должны входить следующие обязательные

документы:


Технические условия;


Комплект эксплуатационной документации.


Технические условия на ТС телематических служб должны быть выполнены на русском языке и

соответствовать требованиям настоящих ОТТ.


Комплект эксплуатационной документации должен быть выполнен на русском языке и должен


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


содержать:


- общее описание, включая контрольный пример;


- руководства администратора и оператора.


Приложение 1


ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ


К ТЕХНИЧЕСКИМ СРЕДСТВАМ СЛУЖБЫ ЭЛЕКТРОННОЙ


ПОЧТЫ ПО ПРОТОКОЛУ SMTP


1. ОБЛАСТЬ ПРИМЕНЕНИЯ


Настоящее Приложение описывает технические требования к ТС службы ЭП по протоколу

SMTP в соответствии с RFC 821 [1].


В Приложении приведены передача сообщений электронной почты другим серверам

электронной почты по протоколу SMTP по сети передачи данных в соответствии с адресом

получателя, промежуточное временное накопление сообщений для дальнейшей передачи, а также

доставка сообщений в локальный ящик электронной почты в соответствии с указанным именем

ящика.


Не все функции, содержащиеся в данном Приложении, обязательны для ТС служб ЭП по

протоколу SMTP, но если они выполняются, то их реализация должна соответствовать настоящему

Приложению.


2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ К SMTP


2.1. Соединения


2.1.1. Протокол нижнего уровня


При использовании TCP для организации соединения клиента и сервера должен использоваться


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


порт 25. При кодировании сообщений SMTP должно учитываться, что соединение TCP

поддерживает длину байта 8 бит. Семибитные символы сообщений SMTP должны быть выравнены

вправо, а старший бит октета установлен в 0.


2.1.2. Установление соединений


В результате запроса клиента передатчик SMTP устанавливает дуплексное соединение с

приемником SMTP.


Протокол SMTP должен предоставлять механизм передачи почты непосредственно с узла

передающего клиента на узел получающего клиента при условии, что эти два узла соединены единой

транспортной службой.


Протокол SMTP должен предоставлять механизм передачи почты путем пересылки между

одним и более серверами SMTP, если два узла клиентов не соединены единой транспортной

службой.


2.2. Взаимодействие


По запросу клиента передатчик SMTP устанавливает дуплексное соединение транспортного

уровня с приемником SMTP. Приемник SMTP может быть либо промежуточным узлом, либо

оконечным узлом адресата. Приемник и передатчик обмениваются командами и ответами.


После установления соединения транспортного уровня приемник должен выдать ответ

приветствия 220.


Первой командой в сессии должна быть команда HELO.


Последней командой сессии должна быть команда QUIT.


Элементы взаимодействия по протоколу SMTP приведены в п. 8.


3. СООБЩЕНИЯ


Сообщения SMTP, посылаемые передатчиком SMTP приемнику SMTP, называются командами.

Сообщения SMTP, посылаемые приемником SMTP передатчику SMTP, называются ответами.


Команды и ответы состоят из символов кода ASCII.


3.1. Команды


Командами являются символьные строки, заканчивающиеся . Команды состоят из кода

команды и последующего поля аргументов. Коды команды и аргументы должны быть разделены

одним или более пробелами. Регистр символов кода команды и названий параметров, таких как "to:"

или "from:", не является существенным. Регистр аргументов прямого и обратного пути является

существенным. Поле аргумента состоит из строки символов переменной длины, заканчивающейся

.


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


3.1.1. Перечень команд


Перечень команд SMTP приведен в табл. 1


Таблица 1


ПЕРЕЧЕНЬ КОМАНД SMTP


Команда    HELO                                                

Аргументы  domain - имя узла передатчика SMTP                          

Описание   Используется для идентификации передатчика SMTP приемником  

SMTP                                                        

Действия с Все таблицы состояний и буферы очищены                      

буферами  


Команда    MAIL FROM:                                    

Аргументы  reverce-path - обратный путь. Состоит из списка узлов и     

почтового ящика отправителя                                 

Описание   Указывает на передачу почты. Наличие списка узлов в обратном

пути показывает, что данное почтовое сообщение было переслано

через каждый из указанных узлов. Данный список используется в

качестве маршрута для пересылки недоставленной почты        

отправителю.                                                

При каждой пересылке пересылающий узел добавляет свое имя в 

начало списка. Если узел имеет несколько имен, должно       

использоваться имя, известное в системе назначения          

Действия с Очищаются буферы обратного пути, буферы прямого пути, буфер 

буферами   данных почты.                                               

В буфер обратного пути помещаются данные аргумента команды  


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Команда    RCPT TO:                                      

Аргументы  forward-path - прямой путь. Состоит из списка узлов и       

почтового ящика адресата                                    

Описание   Идентифицирует индивидуального получателя данных почты.     

Несколько получателей определяются использованием множества 

команд RCPT. Наличие списка узлов в прямом пути указывает,  

что почтовое сообщение должно быть передано следующему узлу 

из списка. Если приемник SMTP не поддерживает функцию       

пересылки, он должен выдать ответ 550 (неизвестный локальный

клиент).                                                    

При передаче почтового сообщения передающий узел должен     

удалить свое имя из списка прямого пути. При достижении     

почтовым сообщением оконечного адресата (при этом прямой путь

будет содержать только имя почтового ящика) приемник SMTP   

должен поместить почтовое сообщение в почтовый ящик с именем,

указанным в прямом пути                                     

Действия с Аргумент прямого пути добавляется в буфер прямого пути      

буферами  


Команда    DATA                                                        

Аргументы  -                                                           

Описание   Приемник обрабатывает строки, следующие за этой командой как

данные почты, направляемой от передатчика. Полученные       

почтовые данные добавляются к буферу данных. Почтовые данные

должны заканчиваться последовательностью ".".   

После окончания получения почтовых данных сервер начинает их

обработку с использованием информации из буфера обратного   

пути, прямого пути и буфера почтовых данных. По окончании   

выполнения данной команды эти буферы должны быть очищены. В 

случае удачного выполнения команды приемник должен выдать   

ответ OK.                                                   

Когда приемник SMTP получает почтовое сообщение для пересылки

или для окончательной доставки, он должен вставлять в начало

почтовых данных линию штампа времени. В штампе времени должны

указываться: узел-отправитель, узел-получатель (приемник    

данной команды), дата и время получения сообщения.          

Когда приемник SMTP выполняет окончательную доставку        

почтового сообщения, он должен вставлять в начало почтовых  

данных информацию о линии обратного пути. Вставляемая       

информация должна быть взята из аргумента "обратный путь"   

команды MAIL. В случае если пересылка почты выполнена только

частично (только части указанных адресатов), сервер SMTP    

должен выдать ответ ОК и извещения о непересланных          

сообщениях. Может быть либо одно извещение с перечнем всех  

неудачных адресатов, либо для каждого неудачного адресата   

должно быть выслано отдельное извещение.                    

Все извещения о недоставке должны посылаться с помощью      

команды MAIL                                                


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Действия с Буферы обратного пути, прямого пути и буфер данных          

буферами   сбрасываются                                                


Команда    SEND FROM:                                    

Аргументы  reverse-path - обратный путь                                

Описание   Используется для инициации транзакции, в которой почта      

доставляется одному или более терминалам.                   

Обратный путь может состоять из необязательного списка узлов

и имени почтового яшика отправителя. Если присутствует список

узлов, он указывает на узлы, через которые пересылалось     

данное почтовое сообщение.                                  

Данный список используется для посылки отправителю извещений

о недоставке                                                

Действия с Буферы обратного пути, прямого пути и буфер данных          

буферами   сбрасываются. Информация из аргумента обратного пути        

вставляется в буфер обратного пути                          


Команда    SOML FROM:                                    

Аргументы  reverse-path - обратный путь                                

Описание   Используется для инициации транзакции, в которой почта      

доставляется одному или более терминалам или почтовым ящикам.

Данные почты для каждого адресата доставляются на терминал, 

если он активен, или в почтовый ящик в противном случае.    

Назначение аргумента аналогично команде SEND                

Действия с Буферы обратного пути, прямого пути и буфер данных          

буферами   сбрасываются. Информация из аргумента обратного пути        

вставляется в буфер обратного пути                          


Команда    SAML FROM:                                    

Аргументы  Reverse-path - обратный путь                                

Описание   Используется для инициации транзакции, в которой почта      

доставляется одному или более терминалам и почтовым ящикам. 

Данные почты для каждого адресата доставляются на терминал, 

если он активен, и обязательно в почтовый ящик. Назначение  

аргумента аналогично команде SEND                           

Действия с Буферы обратного пути, прямого пути и буфер данных          

буферами   сбрасываются. Информация из аргумента обратного пути        

вставляется в буфер обратного пути                          


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Команда    RSET                                                        

Аргументы  -                                                           

Описание   Показывает, что текущая транзакция должна быть прекращена,  

все запомненные данные уничтожены, все буферы очищены.      

Приемник должен ответить OK                                 

Действия с Все сохраненные данные уничтожаются, все буферы сбрасываются

буферами  


Команда    VRFY                                                

Аргументы  string - предполагаемое имя клиента                         

Описание   Данная команда просит приемник подтвердить, что аргумент    

идентифицирует клиента. Если аргумент содержит имя клиента, 

приемник должен выдать ответ с полным именем клиента, если  

оно известно, и полным именем почтового ящика               

Действия с -                                                           

буферами  


Команда    EXPN                                                

Аргументы  string - предполагаемый идентификатор списка рассылки       

Описание   Данная команда просит приемник подтвердить, что аргумент    

идентифицирует список рассылки. Если аргумент содержит список

рассылки, приемник должен выдать многострочный ответ с      

перечнем полных имен клиентов, если они известны, и полных  

имен почтовых ящиков, занесенных в данный список рассылки   

Действия с -                                                           

буферами  


Команда    HELP []                                             

Аргументы  string - имя команды                                        

Описание   По данной команде приемник должен выдать ответ с полезной для

передатчика информацией                                     

Действия с -                                                           

буферами  


Команда    NOOP                                                        

Аргументы  -                                                           

Описание   Нет операции. Приемник должен выдать ответ OK               

Действия с -                                                           

буферами  


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Команда    QUIT                                                        

Аргументы  -                                                           

Описание   Приемник должен выдать ответ OK и закрыть соединение        

Действия с Сброс всех данных и буферов                                 

буферами  


Команда    TURN                                                        

Аргументы  -                                                           

Описание   Приемник должен либо выдать ответ ОК и взять на себя роль   

передатчика, либо выдать ответ отказа 502 и остаться в роли 

приемника.                                                  

Если обмен ролями произошел, процесс, ставший приемником,   

высылает ответ приветствия 220                              

Действия с Сброс всех данных и буферов                                 

буферами  


3.1.2. Синтаксис команд определен в п. 4.


3.1.3. Команды: HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT должны быть реализованы

обязательно.


3.1.4. Обеспечение прозрачности передачи данных в команде DATA


При посылке передатчиком данных почты каждую последовательность ".." (0х0D 0х0A

0х2E) передатчик должен заменять на "." (0х0D 0х0A 0х2E 0х2E). Приемник должен

выполнять обратное преобразование. Указатель конца почтовых данных этому преобразованию не

подвергается.


3.2. Ответы


3.2.1. Код ответа


Ответ SMTP состоит из трехзначного кода ответа (передаваемого как три символа), за которым

следует текст.


Значения номера ответа:


первая цифра


1          Положительный предварительный ответ                

2          Положительный окончательный ответ                  

3          Положительный промежуточный ответ                  

4          Временный отрицательный окончательный ответ        

5          Постоянный отрицательный окончательный ответ       


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


вторая цифра


0          Ошибки синтаксиса                                  

1          Запрос информации                                  

2          О состоянии соединения                             

3          Не определен                                       

4          Не определен                                       

5          О состоянии почтовой системы                       


третья цифра позволяет сделать более точное разделение значений ответов по функциональным

категориям, определенным второй цифрой.


Ответ сервера может состоять из одной или нескольких строк.


Однострочный ответ состоит из:


трехзначного номера ответа, передаваемого как три символа,


символа ,


текста,


символа .


Многострочный ответ состоит из:


трехзначного номера ответа, передаваемого как три символа,


символа "-"


текста первой строки


символа


трехзначного номера ответа, передаваемого как три символа,


символа "-"


текста второй строки


символа


...


трехзначного номера ответа, передаваемого как три символа,


символа ,


текста последней строки,


символа .


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


Список кодов ответов приведен в табл. 2. Для всех ответов, кроме 110, текст ответа не

обязательно должен соответствовать приведенному в табл. 2.


Таблица 2


СПИСОК КОДОВ ОТВЕТОВ


Код Текст                               

211 Системный статус или ответ системной помощи                        

214 Ответ помощи                                                       

220 <домен> Служба готова                                              

221 <домен> Служба закрывает соединение                                

250 Запрошенное действие выполнено успешно                             

251 Клиент не локальный, направлено в <прямой путь>                    

354 Начинаю получение почтовых данных. Конец при .         

421 <домен> Служба не доступна, закрываю соединение                    

450 Запрошенное действие не принято. Почтовый ящик не доступен         

(например, занят)                                                  

451 Запрошенное действие прервано. Локальная ошибка выполнения         

452 Запрошенное действие не принято. Недостаточно памяти               

500 Синтаксическая ошибка, команда не распознана                       

501 Синтаксическая ошибка в параметре или аргументах                   

502 Команда не реализована                                             

503 Неправильная последовательность команд                             

504 Аргумент команды не реализован                                     

550 Запрошенное действие не принято. Почтовый ящик не доступен         

(например, не найден)                                              

551 Клиент не локальный. Пожалуйста, попробуйте <прямой путь>          

552 Запрошенное действие прервано. Превышен лимит памяти               

553 Запрошенное действие не принято. Неправильное имя почтового ящика  

554 Ошибка транзакции                                                  


3.3. Порядок команд и ответов


Первой командой в сессии должна быть команда HELO. Если аргумент команды HELO является

неприемлемым, должен быть выдан ответ 501, и приемник SMTP должен остаться в прежнем

состоянии.


Команды NOOP, HELP, EXPN, VRFY могут использоваться в любое время в течение сессии.


Команды MAIL, SEND, SOML, SAML начинают транзакцию. Если аргумент команды начала

транзакции является неприемлемым, приемник должен выдать ответ 501 и остаться в прежнем

состоянии. Во время транзакции должны использоваться команды в следующей последовательности:

одна или несколько команд RCPT, одна команда DATA. Транзакция может быть прервана командой

RSET. В течение сессии может быть 0, 1 или более транзакций. Если во время транзакции команды


Не является официальной версией, бесплатно предоставляется членам Ассоциации лесопользователей Приладожья, Поморья и Прионежья – www.alppp.ru. Постоянно действующий третейский суд.


выдаются с нарушением указанного порядка, приемник должен выдать ответ 503 и остаться в

прежнем состоянии.


Последней командой сессии должна быть команда QUIT. Команда QUIT может быть выдана в

любое время в течение сессии.


На каждую команду должен выдаваться точно один ответ.


В п. 6 и п. 7 определяются допустимые последовательности команд и ответов.


3.4. Ограничения на размер элементов сообщений SMTP


Ограничения на размер элементов сообщений SMTP приведены в табл. 3.


Таблица 3


ОГРАНИЧЕНИЯ НА РАЗМЕР ЭЛЕМЕНТОВ СООБЩЕНИЙ SMTP


Обозначение Элемент                 Максимальный размер

элемента 

User        Имя клиента                             64 символа        

Domain      Имя домена                              64 символа        

Path        Обратный путь или прямой путь           256 символов      

Command line Строка команды, включая символы   512 символов      

reply line  Строка ответа, включая код ответа и     512 символов      

символы                          

text line   Строка данных почты, включая символы    1000 символов     

, но не считая символы точки,    

добавленные для обеспечения прозрачности

Recipient   Емкость буфера адресатов                100 адресатов     

buffer     


4. ОПИСАНИЕ СИНТАКСИСА КОМАНД И ОТВЕТОВ


1   2   3   4   5   6   7   8   9   ...   19

Похожие:

26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconСогласовано руководитель Департамента здравоохранения города Москвы А. П. Сельцовский
Методические рекомендации предназначены для всех сторон, участвующих в организации и проведении профилактических медицинских осмотров...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon«согласовано» Руководитель по направлению деятельности

26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconГосударственный центр современного искусства
К участию в сетевом проекте "Агитация за искусство". Первый этап проекта пройдет в Екатеринбурге с 15 ноября по 15 декабря 2000 года,...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon24 июня 2003 года Дата введения
А. В.); Всероссийским нии защиты растений (Долженко В. И. и др.); при участии Департамента
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon«согласовано» Начальник Северного окружного управления образования
Руководитель вмо «Сокол» в г. Москве, член Президиума Совета муниципальных образований по сао г. Москвы
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский icon«22» июня 2012г согласовано
Адмиралтейского района, финансирование которых осуществляется с использованием субсидий
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconПресс-релиз руди штанцель
С 14 июня по 10 сентября 2000 года в Австрийском музее прикладного искусства (мак) прошла выставка "реформель" австрийского художника...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconБюро стандартизации электросвязи
...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconБюро стандартизации электросвязи
...
26 июня 2000 года Согласовано Руководитель Департамента электросвязи В. Ю. Квицинский iconБудет объявлена дополнительно
Д-р Андраш Чепреги (профессор богословия, руководитель Департамента по делам связей с церковью при Министерстве образования и культуры...
Разместите кнопку на своём сайте:
kaz.docdat.com


База данных защищена авторским правом ©kaz.docdat.com 2013
обратиться к администрации
kaz.docdat.com
Главная страница