Настройка SPF-записи в DNS

Sender Policy Framework, SPF (инфраструктура политики отправителя) — расширение для протокола отправки электронной почты через SMTP. SPF определен в RFC 7208, т.е. это запись DNS содержащая информацию о серверах, которые могут отправлять почту с вашего домена. Наличие SPF снижает вероятность попадания вашего письма в спам. Благодаря SPF можно проверить, не подделан ли домен отправителя.
SPF запись может быть только одна для одного домена. В рамках одной SPF может быть несколько записей. Для поддоменов нужны свои записи.
Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1.
Далее указываются параметры (механизмы). Чаще всего используются следующие: all, ip4, ip6, a, mx, include, redirect. Также существуют, но используются значительно реже: ptr, exists, exp. Они все будут рассмотрены ниже.

SPF-запись выглядит примерно следующим образом:

v=spf1 ip4:75.123.48.0/24 ip4:77.137.178.0/22 ip4:ip_вашего_сервера/32 ~all

Такая запись означает, что письма с данного домена могут отправляться из подсетей 75.123.48.0/24 и 77.137.178.0/24, а письма, пришедшие с других серверов (all), должны проходить дополнительную проверку (~).

Основной синтаксис

Любая SPF-запись начинается с v=spf1, этот параметр не изменяется. Он указывает на версию записи, и в настоящее время поддерживается только spf1.
Далее указываются параметры (механизмы). Чаще всего используются следующие: all, ip4, ip6, a, mx, include, redirect. Также существуют, но используются значительно реже: ptr, exists, exp. Они все будут рассмотрены ниже.
Помимо механизмов используются префиксы (определители):
«+» — Pass, принимать почту. Прописывать этот параметр необязательно, он установлен по умолчанию (т.е. значения «+a +mx» и «a mx» — идентичны).
«-» — Fail, отклонять почту.
«~» — SoftFail, «мягко» отклонять (принимать почту, но помещать ее в «Спам»).
«?» — нейтрально (обрабатывать как обычное письмо).
Параметр «all» подразумевает все серверы, не упомянутые отдельно в SPF-записи. «all» задает обработку полученных с них писем и указывается в конце записи.

Например:
v=spf1 ip4:176.57.223.0/24 ~all

— принимать почту только из подсети 176.57.223.0/24; письма с других адресов должны быть помечены как спам.

v=spf1 a -all

— принимать почту только с A-записи домена; письма с других адресов должны отвергаться.

v=spf1 -all

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

В последующих примерах мы не будем дополнительно комментировать значения параметров ~all и -all в SPF-записях.

ip4 / ip6 — Используется для указания конкретных адресов и подсетей, из которых могут отправляться письма. Синтаксис для IPv4 и IPv6 идентичен.

v=spf1 ip4:75.123.48.0/24 ~all

— принимать почту из подсети 75.123.48.0/24.

v=spf1 ip6:2002::4b7b:300b ~all

— принимать почту с IPv6-адреса 2002::4b7b:300b.

a — IP отправителя проверяется на соответствие A-записи домена.

v=spf1 a ~all

— принимать почту с A-записи текущего домена.

v=spf1 a:sub.domain.com ~all

— принимать почту с A-записи домена sub.domain.com.

mx — IP отправителя проверяется на соответствие IP-адресам серверов, указанных в MX-записях домена. На текущий день для многих современных сервисов эта директива уже не так важна, так как серверы входящей и исходящей почты зачастую имеют разные IP.

v=spf1 mx mx:sub.domain.com -all

— принимать почту с MX-серверов текущего домена и домена sub.domain.com.

v=spf1 mx/24 -all

— принимать почту из подсети, в которую входят MX-серверы текущего домена.

include — позволяет учитывать в SPF-записи настройки SPF другого домена.

v=spf1 a include:other-domain.com -all

— принимать почту с A-записи текущего домена и серверов, указанных в SPF-записи домена other-domain.com.

При такой настройке проверяется SPF домена other-domain.com; если это, допустим, «v=spf1 a -all», то далее IP отправителя проверяется на соответствие A-записи домена other-domain.com.

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

v=spf1 redirect=other-domain.com

— почта должна приниматься или отклоняться согласно настройкам домена other-domain.com.

Прочие механизмы

Здесь мы рассмотрим оставшиеся механизмы, которые используются в настройках значительно реже.

ptr — PTR-запись IP-адреса отправителя проверяется на соответствие указанному домену. Данный механизм требует большого количества DNS-запросов при проверке, поэтому без острой необходимости использовать его в SPF не рекомендуется.

v=spf1 ptr:other-domain.com -all

— принимать почту со всех адресов, PTR-запись которых направлена на домен other-domain.com

exists — запрашивается А-запись указанного домена; если она существует, проверка считается пройденной. Другими словами, проверяется, резолвится ли домен на какой-либо (любой) IP-адрес.

v=spf1 exists:mydomain.com -all

— принимать почту, если существует A-запись домена mydomain.com.

exp — Параметр «exp» применяется для отправки сообщения об ошибке отправителю письма. С помощью «exp» в SPF прописывается определенный поддомен, в TXT-записи которого указан текст сообщения об ошибке. Имя поддомена и текст ошибки может быть любым.
Параметр «exp» всегда указывается в конце записи (после all).

v=spf1 mx -all exp=error-spf.mydomain.com

При этом TXT-запись домена error-spf.mydomain.com содержит: «Not authorized to send mail for this domain».

Примеры настроек

Настройка SPF для «Почты для доменов» от Mail.Ru
Если вы отправляете почту только с серверов Mail.Ru:

v=spf1 redirect=_spf.mail.ru

Если вы отправляете почту так же и с других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):

v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.mail.ru ~all

Настройка SPF для Яндекс.Почты
При использовании только серверов Яндекса:

v=spf1 redirect=_spf.yandex.net

При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):

v=spf1 ip4:IP1 ip4:IP2 ip4:IP3 include:_spf.yandex.net ~all

Настройка SPF для Google
При использовании только серверов Google:

v=spf1 include:_spf.google.com ~all

При использовании также и других серверов (укажите IP-адреса или подсети вместо IP1, IP2 и т.д.):

v=spf1 ip4:IP1 ip4:IP2 include:_spf.google.com ~all

Другие примеры

v=spf1 a ip4:75.123.48.11 include:extdomain.com -all

— принимать почту с IP-адресов, соответсвующих A-записям текущего домена, с IP-адреса 75.123.48.11 и серверов, указанных в SPF-записи extdomain.com; прочие письма отклонять.

v=spf1 mx/24 a:extdomain.com/24 ~all

— принимать почту из подсети, в которую входят MX-серверы текущего домена, и из подсети, в которую входят A-записи домена extdomain.com; прочие письма отклонять.

v=spf1 a ip4:75.123.48.11 include:extdomain.com -all

— принимать почту с A-записи текущего домена, IP-адреса 75.123.48.11, а также с серверов, указанных в SPF домена extdomain.com.

N.B!: Настройка SPF необходима для установки политики DMARC (Domain-based Message Authentication, Reporting and Conformance — идентификация сообщений, создание отчётов и определение соответствия по доменному имени). Т.е. DMARC — это подпись, которая позволяет принимающему серверу решить, что делать с письмом. DMARC использует DKIM и SPF.

BSDA в вопросах и ответах

Данная книга задумана как методическое пособие для подготовки к экзамену BSDA. Книга, тем не менее, может быть полезна не только тем кто собирается сдавать этот экзамен, но и просто широкому кругу IT-специалистов, желающих систематизировать свои знания об операционных системах семейства BSD (NetBSD, OpenBSD, FreeBSD, DragonFly BSD).

Читать -> BSDA в вопросах и ответах

Материал написан Евгением Миньковским, он старый, но многое актуально для понятия основ и по сей день.

Настройка сетевого интерфейса в OpenBSD

Настройка сети в OpenBSD выполняется с помощью текстовых файлов в /etc, для каждого интерфейса создается файл с именем – hostname + псевдоним сетевого интерфейса. Интерфейсы называются по типу карты, а не по типу соединения. Название сетевого интерфейса узнаем выполнив команду:

$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33200
        index 3 priority 0 llprio 3
        groups: lo
        inet 127.0.0.1 netmask 0xff000000
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:02:b3:5b:12:f8
        index 1 priority 0 llprio 3
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.0.0.5 netmask 0xffffff00 broadcast 10.0.0.255
enc0: flags=0<>
        index 2 priority 0 llprio 3
        groups: enc
        status: active
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33200
        index 4 priority 0 llprio 3
        groups: pflog

В файле /etc/hostname.fxp0 прописываются настройки интерфейса fxp0:

$ cat /etc/etc/hostname.fxp0
inet 10.0.0.5 255.255.255.0 NONE media 100baseTX mediaopt full-duplex

где inet — семейство протоколов (IPv4), 10.0.0.5 — IP-адрес, 255.255.255.0 — маска подсети, NONE — широковещательный адрес (будет выбран автоматически), media 100baseTX mediaopt full-duplex — опции сетевого адаптера, если не задать будет сконфигурено автоматически, но возможно не так как требуется . Для конфигурирования интерфейса с помощью DHCP, необходимо поместить в файл строку dhcp.

Добавить второй ip на интерфейс:

$ cat /etc/etc/hostname.fxp0
inet 10.0.0.5 255.255.255.0 NONE media 100baseTX mediaopt full-duplex
inet alias 10.0.0.77 255.255.255.255

Шлюз по умолчанию указывается в файле /etc/mygate

$ cat /etc/mygate
10.0.0.1

Название хоста указывается в файле /etc/myname

$ cat /etc/myname
test.example.com

Указать DNS сервера в системе

$ cat /etc/resolv.conf
search example.com
nameserver 10.0.1.194
nameserver 10.0.1.195
lookup file bind

Перезагрузить настройки сети

$ sh /etc/netstart

Настройка двусторонней синхронизации файлов с помощью unison

Для решения задачи по синхронизации данных между двумя машинами, в ситуации
когда изменения могут появиться на каждом из компьютеров, прекрасно подходит
утилита unison (http://www.cis.upenn.edu/~bcpierce/unison/). При синхронизации
между удаленными машинами в качестве транспорта может использоваться ssh. При
обнаружении конфликтов, например, когда на обоих машинах отредактирован один и
тот же файл, unison пытается разрешить конфликт автоматически, а если это не
удается предоставляет пользователю интерфейс для принятия решения.

Устанавливаем unison.

Fedora/RHEL/CentOS:

   sudo yum install unison

Debian/Ubuntu:

   sudo apt-get install unison

FreeBSD:

   $ cd /usr/ports/net/unison/ && make install

Синхронизируем две локальные директории:

   unison /test1 /test2

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

Для синхронизации с удаленной директорией необходимо указать:

   unison /test1 ssh://testserver.test.ru//test1

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

Для определения сложной политики синхронизации можно создать файл конфигурации
с определением параметров.

Например, создаем файл ~/.unison/test.prf:

   # Определяем список директорий, которые будут синхронизированы
   root = /home/project
   root = /mnt/NFS/home/project
 
   # Указываем сохранять права доступа и владельца
   owner = true
   times = true
 
   # Определяем список поддиректорий, которые нужно синхронизировать, остальное игнорируем:
   path = cgi-bin
   path = htdocs
   path = conf
 
   # Определяем маски для файлов, которые не нужно синхронизировать
   ignore = Name .htaccess
   ignore = Name *~
   ignore = Name .*~
   ignore = Path conf/project.conf
   ignore = Path htdocs/rrd
   ignore = Path htdocs/mon
   ignore = Name *.o
   ignore = Name *.tmp
   ignore = Name *.log
   ignore = Name *.gz
   ignore = Name *.iso
   ignore = Name {,.}*{.old}
 
   # Копируем в резервные копии изменяемых файлов в отдельную  директорию
   backup = Name *
   backups = true
   backupdir = /home/project/backup
 
   # Определяем свою команду для отображения отличий между копиями файлов при конфликте
   #diff = diff -y -W 79 --suppress-common-lines
 
   # Сохраняем лог с результатами работы в отдельном файле
   log = true
   logfile = ./sync.log

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

   unison test

Удаленная переустановка linux на примере Debian

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

Удивлённо поднимем брови, умиляясь тому, как гибка наша любимая операционка, засучим рукава и приступим к делу.

В основе данного метода лежит идея о том, что мы можем использовать SWAP-раздел для установки временной операционной системы, а когда она встанет на ноги — заняться основной. Главное и единственное, что нам нужно — это своп размером не менее 420 Мб (именно столько занимает lenny со всем необходимым).

В статье используются следующие допущения:
— у вас стоит дебиан, и ставить вы планируете дебиан,
— используется grub установленный в MBR.

Краткий план наших работ будет выглядеть так:

1. превращаем swap-раздел в ext3;
2. устанавливаем на него чистую ОС;
3. перезагружаемся в нее;
4. делаем нужные изменения на основном разделе;
5. копируем чистую ОС из временного в основной раздел;
6. загружаемся с основного раздела, включаем swap.

Подготовка раздела.

Первое, что мы сделаем — убедимся, есть ли у нас этот своп-раздел вообще:

# free -m
...
Swap:          470          0        470

Как видим — есть, и размер (отображается в Мб) вполне удовлетворяет требованиям. Осталось выяснить, как у нас разбит диск:

# fdisk -l /dev/sda
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1         462     3710983+  83  Linux
/dev/sda2             463         522      481950    5  Extended
/dev/sda5             463         522      481918+  82  Linux swap / Solaris

Видно, что на sda1 — текущая ОС, на sda5 — своп. Запутаться сложно, но всякое бывает.

Отключаем своп:

# swapoff -a

Убедиться, что мы его выключили, можно выполнив всё тот же free:

# free
...
Swap:            0          0          0

Обновим нашу таблицу разделов:

# fdisk /dev/sda
Command (m for help): t
Partition number (1-5): 5
Hex code (type L to list codes): 83
Changed system type of partition 5 to 83 (Linux)
Command (m for help): w
The partition table has been altered!
 
WARNING: Re-reading the partition table failed with error 16: Устройство или ресурс занято.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Нам заботливо сообщили, что ядро не увидит изменений до перезагрузки, но нам это пока и не нужно. Теперь самое время подготовить файловую систему на нашем старом новом разделе. Например, ext3:

# mke2fs -j /dev/sda5
Writing inode tables: done
Creating journal (4096 blocks): done

Примонтируем раздел куда-нибудь и на этом его подготовка будет закончена.

# mkdir /mnt/temp
# mount /dev/sda5 /mnt/temp
# df -h
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sda1             3,5G  600M  2,8G  18% /
...
/dev/sda5             456M   11M  422M   3% /mnt/temp

Установка «временной» ОС.

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

Используем отличное средство для получения минимальной установки — debootstrap. Здесь и далее мы будем считать что проблем с интернетом на сервере нет (иначе какой же он после этого сервер ?), поэтому выкачиваем всё из репозитория.

# aptitude install debootstrap
...
Настраивается пакет debootstrap (1.0.10lenny1) ...

Данной утилите достаточно передать четыре параметра: желаемая архитектура, название релиза, директория установки и ссылка на полное зеркало. Архитектуру можно определить по выводу `uname -a`, дистрибутив выбираем на свой вкус, директория в данном случае та, куда мы смонтировали наш раздел, а ссылку на зеркало можно взять здесь: http://www.debian.org/mirror/list. Получается, что строка запуска выглядит примерно так:

# debootstrap --arch i386 lenny /mnt/temp http://ftp.ru.debian.org/debian/

После нажатия enter начнется процесс загрузки и установки пакетов, при достаточно среднем интернет-соединении (~10 Мбит) на это уходит порядка 5-10 минут — я даже не успел допить свой чай. В конце вы увидите сообщение о том, что система успешно установлена:

I: Base system installed successfully.

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

Сначала скопируем все важные настройки. Наверное, у каждого найдутся достаточно важные файлы, которые лежат не там где положено. У меня, к примеру, есть некий /etc/rc.routes со всеми нестандартными маршрутами. Главное не забыть ничего. Приводить тут какой-либо список, мне кажется, совершенно бессмысленно, но у меня это выглядит примерно так:

# cp /etc/{resolv.conf,hosts,rc.local} /mnt/temp/etc
# cp /etc/network/interfaces /mnt/temp/etc/network
# cp /etc/your-stuff /mnt/temp/etc

В fstab напишем самое необходимое — proc и наш корневой раздел:

# cat > /mnt/temp/etc/fstab << "#EOF"
> proc            /proc           proc    defaults              0       0
> /dev/sda5       /               ext3    errors=remount-ro     0       1
> #EOF

Теперь смонтируем dev-окружение, перейдем в чрут нашей временной системы и сразу примонтируем proc:

# mount --bind /dev /mnt/temp/dev
# chroot /mnt/temp /bin/bash
# mount -t proc proc /proc

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

# wget http://debian.soar.name/sources.list -O /etc/apt/sources.list
# aptitude update

Настроим часовой пояс:

# dpkg-reconfigure tzdata

Также нам понадобятся следующие пакеты:

# aptitude install locales
# dpkg-reconfigure locales
# aptitude install console-data
# aptitude install ssh
# aptitude install sudo

Сразу же, чтобы не забыть, создадим пользователя и назначим ему пароль, иначе в ssh нас потом не пустят:

# adduser --ingroup users soar
# visudo

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

# aptitude install grub
# grub-install /dev/sda

После чего необходимо инициализировать МБР на загрузку с нашего нового раздела. Для этого всё там же, в чруте, войдем в консоль граба и напишем следующее:

# grub
grub> root (hd0,
 Possible partitions are:
   Partition num: 0,  Filesystem type is ext2fs, partition type 0x83
   Partition num: 4,  Filesystem type is ext2fs, partition type 0x83

Своеобразный автокомплит по табу подскажет нам, какие разделы есть в нашем распоряжении. Как видим всё на единицу меньше чем в названии в системе. Инициализируем загрузку с нашего sda5:

grub> root (hd0,4)
 Filesystem type is ext2fs, partition type 0x83
 
grub> setup (hd0)
...
Done.
 
grub> quit

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

# aptitude search linux-image
# aptitude install linux-image-2.6.26-2-686

В ходе установки нас спросят «Create a symbolic link to the current kernel image?», на что мы ответим утвердительно. Так же сообщат, что мы устанавливаем ядро, требующее от загрузчика поддержку initrd, и уточнят, не передумали ли мы.
Отвечаем «Нет» и установка заканчивается. Осталось обновить меню загрузчика:

# update-grub
Found kernel: /boot/vmlinuz-2.6.26-2-686
Updating /boot/grub/menu.lst ... done

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

# exit
# reboot

Если все было сделано правильно — машина перезагрузится в нашу временную систему. Мы можем зайти в ssh как пользователь, которого мы только что добавили.

Перенос системы на основной раздел.

Форматируем и монтируем наш старый раздел:

# mke2fs -j /dev/sda1
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
 
# mkdir /mnt/temp
# mount /dev/sda1 /mnt/temp

К слову, на этом этапе можно провести и обслуживание диска: например переразбить основной раздел и проверить файловую систему.

Остается скопировать нашу чистую ОС на основной раздел:

# cp -a -x / /mnt/temp/

Обновляем fstab. На этот раз причешем его по всем правилам:

# cat > /mnt/temp/etc/fstab << "#EOF"
> # /etc/fstab: static file system information.
> #
> #
 
> proc            /proc           proc    defaults           0      0
> /dev/sda1       /               ext3    defaults,errors=remount-ro 0 0
> #EOF

В очередной раз нужно обновить граб. На этот раз — для загрузки уже с нашего основного раздела:

# mount --bind /dev /mnt/temp/dev
# chroot /mnt/temp/ /bin/bash
# grub-install /dev/sda
# grub
 
grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
 
grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... yes
 Checking if "/boot/grub/stage2" exists... yes
 Checking if "/boot/grub/e2fs_stage1_5" exists... yes
 Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  17 sectors are embedded.
succeeded
 Running "install /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.lst"... succeeded
Done.
 
grub> quit
 
# update-grub
Updating /boot/grub/menu.lst ... done

Тут стоит отметить, что у меня в этом месте, в отличие от первого случая, menu.lst обновляться отказался, и там по-прежнему оставались ссылки на sda5. Почему это происходит — я так и не разобрался, поэтому вручную подредактировал этот файл:

# sed -i -e 's/sda5/sda1/g' /boot/grub/menu.lst
# sed -i -e 's/(hd0,4)/(hd0,0)/g' /boot/grub/menu.lst

Выходим из чрута и делаем вторую перезагрузку:

# exit
# reboot

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

# df -h
Файловая система      Разм  Исп  Дост  Исп% смонтирована на
/dev/sda1             3,5G  436M  2,9G  13% /

Остается создать и включить своп:

# fdisk /dev/sda
Command (m for help): t
Partition number (1-5): 5
Hex code (type L to list codes): 82
Changed system type of partition 5 to 82 (Linux swap / Solaris)
...
The new table will be used at the next reboot.
Syncing disks.
 
# cat >> /etc/fstab << "#EOF"
> /dev/sda5       none            swap    sw                   0      0
> #EOF
 
# mkswap /dev/sda5
# swapon -a

Убедимся что всё нормально:

# free -m
Swap:          470          0        470

Ну и в конце, если вы редактировали /boot/grub/menu.lst врукопашную — стоит все-таки запустить скрипт его обновления еще раз:

# update-grub
Updating /boot/grub/menu.lst ... done

Подводя итоги.

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

Источник