Торификация mutt

Решил перейти на "православные" способы юзания электропочты, т.е. консольные.
Возникает вопрос, как торифицировать Mutt? Точнее, не сам мутт, конешна, а отправку почты с него.
Ибо, как я понимаю, для того, чтобы отправлять почту через Mutt, его так и так надо натравливать на локальный sendmail/exim etc.
В данном случае, меня интересует exim как дефолтный почтовый сервер в моем дистрибьютиве. Сейчас он настроен, что доставляет почту только на локалхосте между юзерами.
Как я понимаю, мне нет необходимости приобретать специальный dns-name и настривать его как типа публичный. Тем более, что тогда об анонимности можно будет забыть :)
То есть, его надо настраивать, чтобы он коннектился с соответствующим публично доступным мыло-сервером, хоть с гмылом, хоть со своим на удаленном серваке, для использования почтового аккаунта на этом последнем.
Как настроить – вроде бы куча инструкцией, если погуглить.
Вопрос: как правильно заторить? Можно ли средствами exim прописать заворачивание в socks4a проксю?
Или, если прозрачно торифицировать весь внешний трафик пользователя exim – будет ли это работать?!
Хотелось бы еще узнать, легко ли настроить Mutt, чтобы он скрывал версию ОС и версию почтового клиента?
Кстати, наверное, можно вообще слать почту со своего сервера, на котором крутиться свой публичный почтовый сервер? Просто поставить туда mutt, коннектиться по ssh, и фигачить через удаленный терминал, чтобы ip клиента определялся как ip почтового сервера.
А с сервером коннектиться по ssh из-под прозрачно торифицированного юзера?
Единственное неудобство – на сервера нельзя баловаться с gpg,придется шифровать/подписывать текст на локалхосте и вставлять в сообщение через буфер, а прикрепляемые зашифрованные/подписанные файло также подписывать/шифровать на локалхосте и в таком виде по ssh загонять на сервак.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.

Комментарии

—	*Гость* (14/08/2011 14:37) <#>

> первый очень лапидарен

в отличие от muttrc(5)

$ man mutt | less -p "SEE ALSO"

SEE ALSO
       curses(3), flea(1), mailcap(5), maildir(5),  mbox(5),  mutt_dotlock(1),
       muttrc(5), ncurses(3), sendmail(1), smail(1)

       Mutt Home Page: http://www.mutt.org/

Конфиг записал таким образом:

$ cat .tsocks.conf
server = 212.11.28.25
port = 1080

port 1080 у 212.11.28.25 открыт ?
можно попробовать через Tor :

server = 127.0.0.1
server_port = 9050

Правильно ли я делаю, сохраняя его как $HOME/.tsocks, по аналогии с другими конфигами? Или он должен быть $HOME/tsocks?

это может зависеть от системы/дистрибутива. Хозяину видней где что располагается в его_OS. У кого-то конфиг может быть, например, в /etc

—	*Гость* (14/08/2011 14:46) <#>

P.S

Invalid pair type (port) specified on line 2 in configuration file, "port = 1080"

server_port = 1080

—	*Гость* (14/08/2011 16:10) <#>

1) Через Tor – работает. Но этот же хост в "local subnet"!!!
2) Порт – открыт:

nmap ip-addr | grep 1080
1080/tcp  open  socks

(Тот ip изменен, из параноидных соображений, у реального открыт).
И утилита из tsocks – inspectsocks, показывала, что проксик рабочий (специально брал с сайта свежие прокси, а чекал их по списку, по ip и номеру порта, этой утилитой).
3) server_port = 1080 – ругани "Invalid pair type (port) specified on line 2 in configuration file, "port = 1080"" нет, спс.
Но, не работает:

~$ tsocks msmtp --host=smtp.mail.ru --serverinfo
12:07:00 libtsocks(2334): SOCKS server ip-addr (ip-addr) is not on a local subnet!
msmtp: cannot connect to smtp.mail.ru, port 25: В соединении отказано

P.S. Я пробовал в браузере (в ГУЕ браузера) указывать эту проксю (как socks проксю) – работает, а если запускать браузер из комстроки через tsocks или proxychains – вышеописанная беда.

—	*Гость* (14/08/2011 17:16) <#>

>Тот ip изменен, из параноидных соображений...

это конечно не порок, но, вы пишите IP, а используете hostname, вот так запутывать не надо. Пробуйте :

$ tsocks msmtp --host=94.100.177.1 --serverinfo

Последнее китайское предупреждение – курите man'ы )

$ man 8 tsocks | less -p DNS 
DNS ISSUES
       tsocks  will  normally  not be able to send DNS queries through a SOCKS
       server since SOCKS V4 works on TCP and DNS normally uses  UDP.  Version
       1.5 and up do however provide a method to force DNS lookups to use TCP,
       which then makes them proxyable. This option can only enabled  at  com-
       pile time, please consult the INSTALL file for more information.

—	*Гость* (14/08/2011 18:47) <#>

I keep getting an error like "SOCKS server is not on a local subnet!", what's going on?

—	*Гость* (14/08/2011 20:25) <#>

— Гость (14/08/2011 17:16)

Насчет dns, так я запускаю tsocks под прозрачно торифицированным юзером, там dns заворачивается в tcp и резолвится через tor. Как я понимаю, на выходе из tor он остается tcp? (dns ведь умеет и tcp). Тогда не должно быть проблем с резолвингом dns через socks-проксю после tor'а. Или exit-нода tor'а резолвит dns через udp запросы, хотя и получает их в виде tcp? Что-то я не совсем тогда понимаю как и зачем.

— Гость (14/08/2011 18:47) <#>
wwwI keep getting an error like "SOCKS server is not on a local subnet!", what's going on?

Спс, но ничерта не понимаю, как это сделать.
Согласно man tsocks.conf, как я понял, есть две интересные директивы:

local  An  IP/Subnet  pair  specifying  a network which may be accessed
              directly without proxying through a SOCKS server (e.g  "local  =
              10.0.0.0/255.0.0.0").   Obviously  all SOCKS server IP addresses
              must be in networks specified as local, otherwise  tsocks  would
              need a SOCKS server to reach SOCKS servers.

       reaches
              This  directive is only valid inside a path block. Its parameter
              is formed as IP[:startport[-endport]]/Subnet and it specifies  a
              network  (and  a  range  of  ports  on that network) that can be
              accessed by the SOCKS server specified in this path  block.  For
              example, in a path block "reaches = 150.0.0.0:80-1024/255.0.0.0"
              indicates to tsocks that the SOCKS server specified in the  cur&#8208;
              rent  path  block  should be used to access any IPs in the range
              150.0.0.0 to 150.255.255.255 when the connection request is  for
              ports 80-1024.

Если я прописываю что-то типа local = 212.11.28.00/24, выходит такой лай об ошибках:

tsocks msmtp --host=94.100.177.1 --serverinfo
16:08:28 libtsocks(3768): Local network specification (212.11.28.00:1080) is not validly constructed in reach statement on line 1 in configuration file (ругань на указанную запись, которая у меня в этой первой строчке - прим. автора)
libtsocks(3768): SOCKS server 212.11.28.00 (212.11.28.00) is not on a local subnet!
msmtp: cannot connect to 94.100.177.1, port 25: В соединении отказано

Если что-то типа reaches = 212.11.0.0/16:80 – 1080:212.12.0.0./16, то такой:

tsocks msmtp --host=94.100.177.1 --serverinfo
 libtsocks(3787): Local network specification (212.11.0.0/16:80 - 1080:212.12.0.0./16) is not validly constructed in reach statement on line 1 in configuration file
libtsocks(3787): SOCKS server 212.11.28.00 (81.20.200.26) is not on a local subnet!
msmtp: cannot connect to 94.100.177.1, port 25: В соединении отказано

—	*Гость* (14/08/2011 22:59) <#>

так я запускаю tsocks под прозрачно торифицированным юзером

Э...,тогда все зря. Что может tsocks? перехватить запрос от msmtp и отправить его socks-proxy, которым может быть в частности и Tor тоже. под прозрачно торифицированным юзером все исходящие в обход Tor блокируются файрволом, поэтому

1) Через Tor – работает.

а через 212.11.28.25 и др. нет.

—	*Гость* (15/08/2011 01:32) <#>

— Гость (14/08/2011 22:59) <#>

Я почему-то думал,что tsocks пошлет пакеты через Tor (куда его завернет фаервол) на прокси-сервер, а тот уже – вовне.
Так как, например, если в браузере, запускаемом под прозрачно торифицированным юзером, указать настройки прокси, то прозрачная торификация заворачивает все в тор, из экзита оно идет на прокси, а уже из прокси – по назначению.
С tsocks так не работает?

—	*Гость* (15/08/2011 09:52) <#>

Кстати, из-под незаторенного юзера проблема сохраняется. Так что, имхо, дело не в tor, а в неправильной конфигурации tsocks.
Может быть, кто-нибудь бы выложил образец своего работающего конфига?! Ессно, без чувствительных данных.

—	*Гость* (15/08/2011 14:52) <#>

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

Я сомневаюсь, что вы понимаете, что такое прозрачная торификация и как она работает. Но, допустим, всё именно так как вы говорите и это работает. Тогда это означает, что трафик дважды идёт через Tor, т.е. цепочки длиной 6, а не 3.

—	*Гость* (15/08/2011 19:25) <#>

Я сомневаюсь, что вы понимаете, что такое прозрачная торификация и как она работает. Но, допустим, всё именно так как вы говорите и это работает. Тогда это означает, что трафик дважды идёт через Tor, т.е. цепочки длиной 6, а не 3.

Имеется ввиду внешний прокси, не Tor. Если tcpdump'ить, все идет через Tor, если смотреть ip на выходе (на тех же tor-детекторах или всяких чекалках ip) – ip внешнего проксика (я как то так делал, чтобы tor-ноды не абузить, их и так мало).
Что же касается указания в браузере под прозрачно торифицированным юзером, думаю, здесь Вы не правы – те же три цепочки, просто уходит на привокси или на полипу и идет обычным порядком, я тестил.
iptables -L -v -t nat не показывает, что пакеты заворачиваются в Tor фаерволом, если нет утечки, конечно. (Например, FF с торбаттоном утечки не давал, а джаббер-клиенты зачастую пытаются выпустить пакеты напрямую, тогда они режутся).
Но это оффтоп, а вот пример рабочего конфига tsocks или proxychains никто не привел, и не гуглится ни фига.
Кстати, а ssmtp умеет прокси без всяких tsocks, сам по себе?

—	*Гость* (17/08/2011 00:01) <#>

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

Да, ошибся. Почему-то подумалось о случае Tor-рутера, т.е. когда первый Tor-клиент находится на другой машине вообще, и там это было бы так (если Tor-рутер + свой Tor-клиент на машине за Tor-рутером).

пример рабочего конфига tsocks или proxychains никто не привел, и не гуглится ни фига

Гуглите как proxychains site:pgpru.com в гугле. Уже задолбался его конфиг сюда писать. Всё работает. Что не работает — тоже освещалось в топиках. Грубо говоря, не все прокси-серверы имплеменчены одинаковы, не все прокси-клиенты имплеменчены одинаково, так что сыпать все шишки на proxychains — нехорошо. Он проксифицирует как умеет. С цепочками прокси я его не использовал, но в качестве проксификатора через одну socks- или http-прокси — многократно. С tsocks не работал, потому ничего не подскажу.

Кстати, а ssmtp умеет прокси без всяких tsocks, сам по себе?

Ну что Вы как маленький, право дело! Откройте man, посмотрите поиск по слову proxy (после открытия man введите: -i/proxynnnnnn) — если ничего не найдено, то значит нет.

—	*Гость* (06/01/2015 13:59) <#>

> ssh при настройке для работы через http-прокси требует внешней тулзы corkscrew

В тему сабжа:

Схема «mutt^* → privoxy → Tor → remote SSH-server → mail-server»

fetchmail и msmtp соксифицирются через proxychains, которая завязана на SOCKS-порт, открываемый ssh'ем (опция -D), идущим через Tor.

ssh торифицируется через corkscrew, которая перенаправляет его трафик на privoxy, зацепленную на Tor. Нужно, чтобы коннект на все хосты по ssh заворачивался на privoxy, а туннельные коннекты по ssh, т.е. к 127.0.0.1 (localhost), шли напрямую. И тут вылазят нюансы.

Во-первых, не забываем, что с точки зрения ssh хосты localhost и 127.0.0.1 разные: если в командной строке указывается ssh login@localhost, а в ~/.ssh/config особые правила указаны только для 127.0.0.1, то localhost будет обработан как произвольный хост (подпадает под секцию Host *). Во-вторых, из-за весьма больной логики OpenSSH (смотрим в сорс) если имя хоста не соответствует паттерну (тут не важно, с отрицанием или без), то данный элемент списка паттернов игнорируется.

Предположим, что в секции Host конфига ~/.ssh/config задан только один паттерн, тогда:

ssh 99.1.2.3, Host 99.*.*.* ⇒ секция в конфиге применяется, пишется дебаг-сообщение Applying...
ssh 99.1.2.3, Host !99.*.*.* ⇒ секция не применяется, пишется дебаг-сообщение Skipping ...
ssh 88.1.2.3, Host 99.*.*.* ⇒ секция игнорируется, сообщения нет.
ssh 88.1.2.3, Host !99.*.*.* ⇒ паттерн игнорируется, секция игнорируется, сообщений нет.

Вариант 4 — это явная болезнь логики. Что курили (имели в виду) авторы? Если в строке Host указывать один отрицательный паттерн, из вышеизложенного следует, что эта секция не выполняется никогда. Вот что пишут на этот счёт в мане:

If a negated entry is matched, then the Host entry is ignored, regardless of whether any other patterns on the line match.

Т.е., надо писать «Host !127.0.0.1 *», тогда в случае типа 4 будет вот что:

ssh 99.1.2.3 ⇒ первый паттерн (отрицание) не срабатывает, и секция матчится по второму элементу в списке — *.
ssh 127.0.0.1 ⇒ первый паттерн (отрицание) срабатывает, и секция игнорируется.

Есть и другой вариант, как в Tails:

Host 127.0.0.1
ProxyCommand none
 
Host *
ProxyCommand ....

Срабатывает это потому, что OpenSSH использует только первую по ходу конфига активную секцию Host, т.е. удовлетворяющую паттернам (берёт её значение для ProxyCommand, а упоминание ProxyCommand в последующих секциях игнорирует). Т.е., секция «Host *» должна идти в конце. В общем, имеем очередной пример торжества программистской нечеловеческой логики и «Worse Is Better» подхода.

P.S. Два равнозначных конфига ~/.ssh/config, написанных с учётом сказанного:

Первый:

Host X.X.X.X
    IdentityFile ~/.ssh/X.X.X.X-keyfile.ssh
 
Host 127.0.0.1
    IdentityFile ~/.ssh/127.0.0.1-keyfile.ssh
 
Host !127.0.0.1 *
    ProxyCommand corkscrew 127.0.0.1 8118 %h %p
 
Host *
    Compression yes
    CompressionLevel 9

Второй:

Host 127.0.0.1
    IdentityFile ~/.ssh/127.0.0.1-keyfile.ssh
    ProxyCommand none
 
Host X.X.X.X
    IdentityFile ~/.ssh/X.X.X.X-keyfile.ssh
 
Host *
    Compression yes
    CompressionLevel 9
    ProxyCommand corkscrew 127.0.0.1 8118 %h %p

^*Работает как связка msmtp+fetchmail+procmail.

—	*Гость* (07/01/2015 20:05) <#>

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

Проблем с торификацией msmtp и mpop никаких, через torsocks/proxychains4 работают нормально. Для изоляции цепочек для каждой торифицируемой программы (msmtp, mpop, gpg, wget и т.д.) нужно использовать отдельный конфигурационный файл torsocks.conf или proxychains.conf с указанием своего пользователя для username-авторизации на Tor. User и password могут быть любыми, главное чтобы отличались, Tor их сейчас не проверяет, использует только для разделения путей.

Если mpop запускается от отдельного пользователя (так безопасней), то в качестве MDA лучше использовать локальный SMTP-сервер, который в любом случае нужен. В противном случае procmail для доступа к почтовому ящику пользователя mutt требует рута или setuid, что небезопасно.

Смысл запуска mutt на удалённом сервере неясен, т.к. в этом случае письма хранятся на недоверяемой машине. ssh через corkscrew нужен только для прямого доступа (не через Tor) через HTTP-прокси, что позволяет сделать и proxychains. Через Tor достаточно torsocks/proxychains4 ssh, комбайны с corkscrew и privoxy не нужны.

По заголовкам тут уже сказали – User-Agent убрать, Message-ID модифицировать (опции user_agent и hostname). Принимающий SMTP-сервер добавит заголовок с IP-адресом эксит-ноды, даже если бы торифицируемый ПК имел белый адрес. Чтобы видеть и редактировать заголовки при наборе письма, лучше установить опции edit_headers и autoedit.

—	*Гость* (07/01/2015 23:02) <#>

> Смысл запуска mutt на удалённом сервере неясен

mutt запускается локально.

> Через Tor достаточно torsocks/proxychains4 ssh, комбайны с corkscrew и privoxy не нужны.

Там всё хитрее. Почту надо забирать, показывая mail-серверу нейтральный IP, т.е. Tor-эксит не канает, поэтому выбирается фиксированный SSH-сервер, доступ к которому уже идёт через Tor. Дальше возникает технический нюанс: proxychains не умеет разные конфиги (другие соксификаторы не курил; возможно, зря). Когда SSH-тунель проброшен, proxychains'ом в SOCKS-порт SSH'а заворачиваются msmtp и fetchmail. А как тогда завернуть в Tor сам SSH? Под тем же юзером отдельный конфиг proxychains для него не сделать, поэтому он торифицируется через комбайн с corkscrew и privoxy.

Кроме перечисленного, есть и другие нюансы: под этим же юзером надо выпускать mcabber через Tor с учётом того, что mcabber не умеет найтивно SOCKS-прокси, зато дружит с HTTP-прокси. Соответственно, ему в настройках проще всего указать privoxy, зацепленную на Tor. Это работает стабильнее, чем через proxychains, даже если бы вариант с proxychains был бы совместим.

Наконец, из-за того, что какие-то программы надо выпустить просто через Tor, а другие ещё и через SSH-сервер за Tor'ом, нельзя обе SOCKS-прокси (Tor и SSH SOCKS) указать в конфиге proxychains как два звена одной цепочки прокси. Короче, комбайн очень специфичен. Возможно, с другим проксификатором было бы меньше плясок.

> Вместо fetchmail удобней использовать mpop

Да, есть альтернативы и для msmtp и для fetchmail (тот же getmail и др.), но глубоко я с ними не разбрался, связка устоялась, а теперь главенствует принцип «не сломано — не чини». Времени играться и перенастраивать все конфиги через другие тулзы пока нет.

> в качестве MDA лучше использовать локальный SMTP-сервер

Это было бы уже совсем монструозно.

> который в любом случае нужен.

Зачем? Только чтобы системные логи собирать?

> В противном случае procmail для доступа к почтовому ящику пользователя mutt требует рута или setuid, что небезопасно.

procmail запускается локально от того же юзера, который имеет доступ к почте. Насколько я знаю, никакого рута или суидности в этом случае не требуется. Вот если запускать от другого юзера, то могли бы быть нюансы, но и там это разруливается: procmail запускается от того, который имеет доступ к почте, а работа с почтой идёт от другого юзера, которому выдали доступ хозяйничать в нужной директории.

За советы спасибо.

P.S. Уже есть какой-то иной proxychains — proxychains-ng.

На страницу: 1, 2, 3, 4, 5, 6, 7, 8 След.

Ваша оценка документа [показать результаты]

Торификация mutt

Схема «mutt* → privoxy → Tor → remote SSH-server → mail-server»

Схема «mutt^* → privoxy → Tor → remote SSH-server → mail-server»