В данной статье подробно рассказывается про продление сертификата врача, и все что об этом надо знать. Для того чтобы врач мог осуществлять деятельность по своей специальности, ему необходимо иметь на руках не только диплом, подтверждающий получение образования, но и сертификат специалиста. Важно следить не только за профессиональными качествами и опытом врача, но и за тем, чтобы не прошел срок действия сертификата. Это связано с тем, что осуществлять деятельность без документа нельзя. Все работники медицины сталкиваются с этой необходимостью подтвердить сертификат каждые пять лет.

Что это такое?

Сертификат - это основание для осуществления врачом работы по своей специальности, обозначенной в дипломе и других документах. Этот документ врачи получают каждые пять лет после окончания курсов повышения квалификации и прохождения экзамена. Они распечатаны на специальных бланках, которые установлены законом в типографии «Гознак».

Документ выдают на основании диплома и в случае сдачи экзамена на сертификацию, пройденного хорошо. Как только экзамен будет пройден, председатель комиссии заверяет его подписью и печатью.

Сертификаты заполняются исключительно на компьютере. В бланк необходимо внести данные о работнике медицины. К ним относятся ФИО, местоположение и название организации, которое принимает экзамен, специальность и направление деятельности сотрудника, номер и дата протокола, на основании которого выдается сертификат и присуждается квалификация.

Последствия непродления сертификата

Допуск к медицинской деятельности имеют лица, которые получили соответствующее образование и сертификат врача. Сотрудники будут вынуждены повысить свою квалификацию по прошествии определенного срока.

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

• Врач не работал меньше пяти лет по своей специальности, и у него нет сертификата, то он сможет осуществлять работу только в случае если получит его;
• Врач не работал больше пяти лет по своей специальности, то он может получить доступ к работе только после завершения повышения квалификации и получения сертификата.

Следовательно, когда действие сертификата практически подходит к концу, то врач обязан получить новый.

Примут ли на должность без сертификата?

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

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

Главный врач отстраняет такого работника до предъявления им нового сертификата. Еще он обеспечивает специалисту все возможности, чтобы тот хорошо сдал экзамен, а в случае, когда действие сертификата заканчивается, то он направляет специалиста на обучение.

Исходя из законодательства, отстранение сотрудника по причине прошедшего срока сертификата является правомерной мерой.

Что делать?

Когда у врача истекает срок сертификата необходимо действовать следующим образом:

• Отстранить сотрудника от работы на время, когда он находится на обучении;
• Перевести специалиста на должность, на которой сертификат не нужен. Осуществляется в случае, если сотрудник отказывается от прохождения обучения в связи с различными причинами, например отсутствия времени или средств. Главный врач обязан предложить специалисту другую должность, которая будет оплачиваться сравнительно ниже. При желании сотрудник может спустя некоторое время пройти обучение, получить сертификат и тогда его восстановят на прежнюю должность.

В случае если срок действия истек во время нахождения сотрудника в отпуске по уходу за ребенком, то как только он возвращается к работе, ему будет необходимо пройти обучение и получить новый сертификат. На время его получения сотруднику при желании предоставят должность, где он не требуется в обязательном порядке. Так же врачу необходимо будет пройти курсы повышения квалификации, на срок которых ему могут быть предоставлены те же условия.

Продлить сертификат специалиста необходимо каждому врачу, так как осуществлять свою работу они смогут только, когда сделают это. Стоит отметить, что каждый врач в праве отказаться от продления сертификата сразу же после истечения его срока, и сдать экзамены позже. Однако до этого момента ему нельзя будет приступать к своей работе.

Статья Трудового кодекса РФ номер 196 гласит: в тех случаях, которые предусмотрены ФЗ или правовыми документами, начальник обязан проводить курсы повышения квалификации всех своих подчиненных, при условии, что это требуется для их деятельности. Это также касается и сертификатов.

В этой статье вы узнали, про продление сертификата врача. Если у вас возникли вопросы и проблемы, требующие участие юристов, то вы можете обратиться за помощью к специалистам информационно-правового портала «Шерлок». Просто оставьте на нашем сайте заявку, и наши юристы вам перезвонят.

Редактор: Игорь Решетов

Представим ситуацию, когда и верстальщики отлично поработали, и подписчики согласие дали, а письма неумолимо продолжают попадать в спам, снижая репутацию домена. Одной из причин высоких показателей Spam Complain Rate (SCR) - неправильные настройки в служебных заголовках или же их полное отсутствие.

Сегодня мы расскажем о том, как настроить служебные заголовки и почему это поможет защитить вас от интернет-мошенников, которые могли бы рассылать от вашего имени спам.

Что такое служебные заголовки и зачем их настраивать

Протоколы, реализующие отправку и приём электронных писем, появились еще в 80-е. В те благословенные и слегка наивные времена всемирная сеть была мала и фактически не знала мошенничества и обмана, поэтому проверки и защита в почтовых протоколах почти отсутствовали.

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

В случае использования платформ-рассыльщиков ситуация усложняется. Отправителем выступает ваш домен, например, site.ru, но рассылка ведётся с адреса mail.sendsay.ru, что вызовет у принимающего почтового сервера справедливые подозрения.

Sender Policy Framework

Чтобы снять подозрения почтовиков используется специальный механизм - SPF (Sender Policy Framework или инфраструктура политики отправителя). С его помощью сайт (всё тот же, site.ru) говорит принимающей стороне, что рассыльщик (sendsay.ru) действительно имеет права на отправку ваших писем.

Важно, что SPF работает только с заголовком письма и специальным обратным адресом (smtp.mailfrom), но не с тем адресом From, который видит человек. Так что мошенничество с подменой From никак не повлияет на проверку SPF.

Выходит, этот механизм не является действительно надёжной защитой: чаще всего провал SPF-проверки не является поводом отвергнуть письмо. Главная его задача - подтверждение отправителя, что важно для репутации домена в глазах почтовых платформ. Чем выше рейтинг домена, тем ниже шансы, что ваши письма будут признаны спамом. Если компания использует для рассылок несколько доменных имён (допустим, .ru и.com), то настраивать служебные заголовки придётся для каждого доменного имени отдельно. Проще всего выделить для рассылок специальное доменное имя (например, mail.stie.ru) и настроить SPF-запись под него.

При желании для рассылок можно воспользоваться и доменом sendsay.ru, но это имеет ряд побочных эффектов. В частности, использование стороннего отправителя явно отображается в веб-интерфейсе gmail.com: рядом с адресом отправителя появляется надпись о рассыльщике:

Не смертельно, но неприятно. В настройке SPF-записи поможет сетевой SPF-мастер .

Domain Keys Identified Mail

Следующим бастионом на пути проверки писем является цифровая подпись DKIM (Domain Keys Identified Mail - идентификация письма по ключу домена). DKIM - это специальная криптографическая подпись, которая позволяет надёжно идентифицировать вас как легитимного отправителя. Идеологически DKIM подобна водяным знакам на банкнотах.

Метод строится на паре ключей шифрования: открытом и закрытом. Закрытым ключом сообщение подписывается перед отправкой. Открытый ключ публикуется на DNS-сервере отправителя в TXT-записи.

При получении письма, принимающий сервер читает открытый ключ и автоматически проверяет, действительно ли email подписано правильным ключом. Таким образом, криптографическая подпись позволяет не только идентифицировать отправителя, но и гарантировать, что подписанное сообщение не было искажено в пути.

Провал проверки DKIM обычно не является катастрофой: подобные письма доберутся до получателя, пусть и с пометкой «возможно мошенничество, мы не можем проверить подлинность отправителя» . Самое неприятное последствие проваленной DKIM-проверки - ущерб для репутации отправителя.

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

Если же вы настраиваете самостоятельную рассылку, то создание цифровых подписей лежит на вас. Для упрощения настройки DKIM удобно воспользоваться онлайн-визардом .

Domain-based Message Authentication, Reporting and Conformance

Domain-based Message Authentication, Reporting and Conformance (DMARC) - идентификация сообщений, создание отчётов и определение соответствия по доменному имени. DMARC - политика проверки сообщений, предназначенная для снижения числа нежелательных писем.

Возникшая всего пару лет назад (в марте 2015 года), DMARC строится на уже описанных SPF и DKIM, но имеет существенное отличие. Если базовые механизмы лишь говорят получающему почтовому серверу прошло ли письмо проверки, то DMARC объявляет как с такими сообщениями следует поступать.

Можно включить строгую политику и запретить доставку подобных писем, хотя не все почтовые сервисы следуют этим инструкциям буквально. В частности, почта Яндекса всё равно доставит письма, пусть и с пометкой, что это «возможно мошенничество». Есть у DMARC и возможность пропустить все письма без исключения, тогда проваленные проверки будут отражаться только в отчётах. Это бывает полезно при отладке технических заголовков.

В настройке DMARC-записей также поможет специальный сервис .

Для проверки правильности технических заголовков воспользуйтесь универсальным сервисом supertool . Он не только выявляет проблемы, но и формирует рекомендации по исправлению.

Итог

Как видите, настройка аутентификации электронной почты - задача сложная, но важная в современном контексте. Платформа старается взять на себя заботу о технических деталях, именно поэтому при делегировании нам своего поддомена, клиенты получают служебные заголовки, настроенные нашими специалистами.

Предисловие:

Тебе приходилось когда-нибудь
отсылать трояны "от другого лица" на
ящики пользователей? Тогда ты знаешь, что
успех зависит от нескольких факторов: во-первых
от того, кому попало письмо (ламер, юзер,
хакер и т.д.), во-вторых от умения
использовать социальную инженерию и в-третьих
от умения фальсификации заголовков.

Инструментарий:

Итак, что же нам понадобится:

1. Прога для создания письма.
   Подойдёт любая: TheBat!, АутГлюк и т.д. Если
   нужно отослать более одного письма,
   рекомендую SendIt.
2. Прога для массовой рассылки
   писем с поддержкой использования прокси (Advanced
   Direct Remailer , G-Loch
   EasyMail , Advanced
   Mass Sender , Group
   Mail Free , Mega-MailerPro ,
   Beijing Express Direct
   Email Blaster и т.
   д.)
3. Прога для работы других прог
   через прокси: Socks Chain
   и т. д.
4. Ну, и письмо от чела, чьим "двойником"
   станешь.

Все эти проги я описывать не буду.
Это выходит за рамки моей статьи. Описание
прог под пунктом "2" можно найти в
последнем номере журнала "Хакер" (ver 02.03
(50)).

Принцип работы

Принцип работы прост, как всё
гениальное: если пользователь
засомневается, что письмо пришло от того,
кто указан в поле "От", он полезет в
заголовки и будет с умным лицом их изучать (а
может и сравнит с пришедшими до этого
письмами). Поэтому нам надо подменить
заголовки писем на те, которые указываются
в настоящем письме. Вот для чего нам
требовалось получить письмо от того, кем мы
притворимся.

Формирование письма

Самый первый этап работы
заключается в правильном создании письма.
"А что сложного в создании писем?"
спросишь ты. Под "созданием письма" я
имею ввиду не текст письма, а создание
заголовков. Итак, всем известно, что при передачи письма
почтовому серверу тот вставляет свой
заголовок в начало. Т. е. самый первый
заголовок будет от сервака, где находится
твоё мыло, т.к. он последний получил письмо. Наша задача состоит в том, чтобы отправить
письмо серверу где находится мыло жертвы
напрямую, т.е. минуя другие сервера, и при
этом притворится настоящим отправляющим
сервером.

Вот тут нам понадобятся две проги (или
одна — смотря какими пользуешься): любой
почтовик и одна из прог под пунктом 2.

В почтовике составляем текст
письма. Это уж как-нибудь без меня. После
того, как письмо написано, его нужно
перенаправить к проге ADR (Advanced Direct Remailer). Для
этого в настройках почтовика заполняем
поле SMTP сервера как "localhost" (без кавычек) и отправляем письмо. Теперь
заходим в ADR, кликаем правой кнопкой мыши на
письмо и выбираем "Посмотреть сообщение".
У нас высвечивается Блокнот, в котором
показаны текст письма и заголовки
почтовика. Текст письма не трогаем, а вот
заголовки удаляем и вставляем нужные. Для
этого надо открыть письмо того чела, кем мы
будем прикидываться и настроить почтовик
на показ заголовков (например, в русском TheBat!
это делается так: вид-> показывать
заголовки (RFC-822)).

Нужно вставить все заголовки этого
письма, кроме самого первого (последний
заголовок вставит сервер). Теперь заголовки
необходимо отредактировать: заменить мыло
получателя на то, на которое собираешься
посылать письмо, изменить дату и время на то,
которое будет при отправке. При этом нужно
подсчитать разность времени между
получениями письма серверами, через
которое оно проходит, и ставить время для
каждого сервера своё.

Теперь лезем в настройки ADR.
Заходим в раздел "Доставка" и в поле
"Домен для "HELO"" пишем название
сервака, который отправляет почту (в
заголовках письма оно указано рядом с его IP).
Далее нам понадобится Socks Chain. В настройках
устанавливаем, через сколько проксей нужно
отправить письмо до того, как оно попадёт на
SMTP (хватит и одного). Не закрывая SC снова
лезем в настройки ADR-> "Прокси". Здесь
указываем адрес прокси как 127.0.0.1 и порт,
который стоит в настройках SC (по умолчанию
1081).

Всё, отправляем письмо.

From [email protected] Sun Dec 08 09:04:04 2002
Envelope-to: [email protected]
Delivery-date: Sun, 08 Dec 2002 09:04:04 +0300
Received: from (helo=webserver2.kaspersky-labs.com)
by mx5.mail.ru with smtp (Exim
SMTP.5)
id 18KuXr-000GQc-00
for [email protected]; Sun, 08 Dec 2002
09:04:04 +0300
From:
To: [email protected]
Subject: Тест.
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Message-Id:
Date: Sun, 08 Dec 2002 09:04:04 +0300

Думаю, не для кого не секрет, кем я
хотел представиться 🙂

Проблемы

Иногда почтовые сервера с высокой
степенью защиты от спама не принимают почту,
если указать в "Домене для "HELO"" не
настоящее имя сервера, с которого пришло
письмо (такое было с mail.ru и hotbox.ru). Вероятно,
сервер сравнивает IP с какого идёт письмо (в
случае с использованием прокси — его адрес)
с IP сервера, на котором находится ящик
отсылающего. В этом случае письмо попадает
в "Плохие" с ошибкой "Почтовый ящик
не существует на этом сервере". Вероятные
решения этой проблемы:

Заменить имя домена на настоящее
(в случае использования прокси — указать
его IP)

Попытаться использовать IP-спуфинг

Сделать имя своего компа таким
же, как и у хоста, который указывается в
"Домен для "HELO" (на тот случай, если
твою машину при соединении регистрируют
в сети прова).

При отправке письма напрямую,
некоторые сервера отказываются работать,
если используется их служба, а в строке "От"
указан ящик, чей аккаунт находится у
другого сервера (такое было у mail.ru).

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

В последнее время многие
сервера отказываются принимать почту, если
определённый IP соответствует прокси. Здесь
также стоит попробовать спуфинг.

Плюсы и минусы данного способа

К достоинствам этого способа можно
отнести возможность рассылки писем без
засветки своих реальных данных (IP, имя компа,
и т.д.) При этом, этот способ вполне может
подействовать не только на ламеров, которые
и о заголовках-то никогда не слышали, но и на
юзеров, если те полезли в заголовки письма (там
всё идентично, кроме IP).

Недостаток: может найтись тот
чувак, который проверит соответствие IP и
имя указанного домена. Но всё равно, уж
лучше так, чем отсылать заведомо
неправильно сформированное письмо.

Заключение

Ну, вот и всё. Желаю тебе побед в
нелёгкой борьбе против ламеров.

Сообщение электронной почты обычно состоит из двух частей:

заголовка (header), содержащего служебную информацию, управляющую доставкой и обработкой сообщения;

тела (body), содержащего непосредственно пользовательское сообщение: текст и прикрепленные данные (графические, звуковые файлы и т.п.).

Заголовок сообщения

Почтовое сообщение – это простой текст в формате ASCII. Поэтому заголовок сообщения представляет собой последовательность текстовых строк вида:

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

Message-ID – уникальный идентификатор сообщения. Уникальность значения этого поля гарантируется программным обеспечением узла-отправителя, поэтому оно генерируется автоматически.

Date – поле "Дата". Содержит дату отправки сообщения. Значение поля устанавливается автоматически почтовым клиентом при отправке сообщения.

From – поле "От". Содержит адрес, который отправитель сообщения указывает в качестве исходящего адреса.

Sender – поле "Отправитель". Содержит адрес, с которого было реально отправлено сообщение. Это поле может отсутствовать в заголовке, если поле "From" содержит адрес реального отправителя.

To – поле "Кому". Содержит адрес основного получателя сообщения.

Cc – поле "Копия". Содержит адреса дополнительных получателей сообщения.

Bcc – поле "Скрытая копия". Содержит адреса дополнительных получателей сообщения. Получатели, перечисленные в полях "To" и "Cc", не будут знать, что абоненты из списка "Bcc" получили копию сообщения.

Reply-to – поле "Ответить". Содержит адрес, по которому получатель должен направлять ответ. Это поле является необязательным: в случае его отсутствия ответы направляются по адресу, указанному в поле "From".

Subject – поле "Тема сообщения". В этом поле обычно указывается краткое описание (тема) сообщения.

Тело сообщения

Изначально предполагалось, что почтовые сообщения могут содержать только текст в формате ASCII. А поскольку возможность передачи нетекстовой информации не предусматривалась, то протоколы передачи электронной почты могут некорректно обрабатывать такие сообщения. В связи с этим в свое время был разработан специальный стандарт, определяющий принципы преобразования нетекстовых данных к текстовому виду. Этот стандарт получил название MIME (Multipurpose Internet Mail Extension, многоцелевое расширение почты Интернет).

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

текст – простой текст в формате ASCII, а также текст в формате RTF или HTML;

графические изображения – файлы в формате JPEG и GIF;

аудио и видео данные;

данные в форматах различных приложений, например, документы Microsoft Office, а также данные произвольного формата (в том числе, различные исполняемые файлы).

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

Это широко используется при отправке сообщений с вложениями (attachments) – дополнительными "прикрепленными" файлами, которые могут содержать разнородную информацию. Например, к текстовому сообщению можно прикрепить графический файл c фотографией отправителя.

Кроме того, это может оказаться полезным, когда текст сообщения необходимо передать в разных форматах. Например, отправленное сообщение в формате HTML, содержащее какое-либо оформление, может некорректно восприниматься клиентской программой получателя. Чтобы избежать подобных проблем почтовый клиент отправителя может сформировать альтернативное представление сообщения в виде простого текста.

Для обеспечения корректной передачи сообщений c нетекстовыми данными в MIME предусмотрены два алгоритма перекодировки, осуществляющие преобразование таких данных к тестовому виду:

алгоритм "Quoted-printable", предназначенный для замены байтов, не являющихся ASCII-символами, на группу из трех байт, представляющих собой только стандартные символы;

алгоритм "Base64", осуществляющий преобразование трех произвольных байт в четыре ASCII-символа.

Для обеспечения корректной интерпретации данных стандартом MIME в заголовок сообщения вводятся дополнительные специальные поля.

Content-type – поле "Тип содержимого". Отвечает за корректное определение типа данных, содержащихся в сообщении заголовка сообщения. Значение поля указывает на конкретный тип данных, или информирует о том, что тело содержит несколько разнотипных блоков.

Content-Transfer-Encoding – поле "Тип кодирования содержимого". Определяет способ преобразования (перекодировки) исходных данных в текстовый вид.