Так как ни крути что-то окрывать придётся, так почему бы и не 25-й портvg писал(а):Ну, и firewall - лы там всякие
На перловке он написанYury писал(а):Есть и бесплатно
http://caspian.dotconf.net/menu/Software/SendEmail/
плюс пару строк в бат (кмд) файле плюс
виндовый скедулер
просто и со вкусом
ЗЫ Ох уж эти программисты - все бы им писАть и писАть
, что для виндов проблематично ...
Вы эта.... не горячитесь, товарищь. Я видел товарищей, которые пытались использовать совершенно нормальное мыльное ПО, например Outlook Express, для работы в приватной сети (прикрытой firewall с технологией отличной от NAT) для работы в инет.А ты видел файерволы в компаниях чтобы почту не пропускали?
Легальную.
(если только не NAT-ом прикрыто ) Да-да. И у Вас не будет работать, и у меня не будет работать. И телнет за фареволом не будет работать. B FTP не будет работать. Ежели только не NAT. И та прога, о которой Вы постили не будет скорее всего работать. И вы представляете, не будет работать даже в том случае, если на firewall разрешить вообще любой трафик. Да не об этом я вовсе! Не об э т о м! Хоть все порты открой на firewall - не будет работать. Ибо так работает firewall. Любой, кроме тех, что использует NAT, где на рабочих станциях приватной сети можно ограничиться только указанием шлюза по умолчанию (для инет). Для всего остального ПО firewall мапит запросы от клиентов приватной сети к удалённым клиентам инет. Мапить firewall умеет. Но надо каким-то образом сделать так, чтобы firewall мог принимать от клиента запрос (который потом и будет "мапиться"). А для этого клиент приватной сети должен уметь взаимодействовать с firewall. И есть только три способа взаимодействия: NAT (+ его разновидности), SOCKS (стандарт инф. обмена с firewall) и специализированное ПО, дополнительно установленное на компе пользователя.vg:
Ну, и firewall - лы там всякие
Так как ни крути что-то окрывать придётся, так почему бы и не 25-й порт
HTTP..., оно конечно кажется не так страшно, но ведь это только кажется...
Я там вверху давал ссылку на HTTP uploader, если его завернуть в правильный скрипт то сработает и по HTTP, хотя и не так удбно как это AutoMail
Спасибо, конечно, Marmot, что вступились за меня.Ну я видел, во многих местах SMTP traffic наружу закрыт для юзверей, только через corporate mail server, a этот AutoMail похоже сам себя обслуживает...
Но выше я пропостил - в чём дело. Разрешения и запрещения при фильтрации трафика - это одно (то, о чём вы пишите. и кстати нормальные админы только так и делают), а способ взаимодействия клиента внутри приватной сети и firewall - то другое (SOCKS или специализированный клиент, работающий по RPC, SOCKS, да как угодно). Котлеты (фильтрация трафика) и мухи (взаимодействие клиента и фаревал) отдельно.А не Вы ли писали в разделе "Общее" про то, что Вам "шо" дает в лиз IP? Этож реальный IP инет. Вы пробовали на машине, которая прямо смотрит в инет. А есть на тойже машине firewall, аль нет - совершенно по барабану, если правильно написаны фильтры трафика.там для виндов экзешник есть
работает (через шо пробовал)
А можно здесь подробнее про связь "аутинтификации" на смпт сервере и задачи leonid. Для Вас откровение, что никто аутинтификацию smtp в инет не использует?но аутинтификация на смтп сервере
похоже там не предусмотрена
Догадайтесь почему? Расскажите, пожалуйста, какие?так что в корпоративных сетях могут быть проблемы
В задаче leonid-a? vg, вы чего такое тут несёте, вы когда нибудь работали с нормальными firewall-ми?vg писал(а):Да не об этом я вовсе! Не об э т о м! Хоть все порты открой на firewall - не будет работать. Ибо так работает firewall. Любой, кроме тех, что использует NAT, где на рабочих станциях приватной сети можно ограничиться только указанием шлюза по умолчанию (для инет). Для всего остального ПО firewall мапит запросы от клиентов приватной сети к удалённым клиентам инет. Мапить firewall умеет. Но надо каким-то образом сделать так, чтобы firewall мог принимать от клиента запрос
Вы так уверены? По крайней мере в документацци к тому HTTP commnad-line client-у написано что он ходит через SOCKS .leonid писал(а):Похоже, что остальные предложенные command line или "пакетные" HTTP, FTP и SMPT клиенты не смогут проходить через "ненормальные" firewalls.
IMHO, хорошо обстoят, это то же код что работает в IEleonid писал(а): Интересно, как с этим обстоят дела в WinINet?
Ага, всё так просто, потому что все эти Web Services тоже ходят через обычный HTTPleonid писал(а): Еще интересно как с этим делом обстоит у .Net Remoting или Web Services? M$ клянется, что одно из преемуществ этих технологий перед DCOM, возможность проходить через firewalls.
Зря Вы так. Я на любых форумах говорю только то, что знаю наверняка (привираю только иногда, и не в этом случаеvg, вы чего такое тут несёте, вы когда нибудь работали с нормальными firewall-ми?
Ничего клиенты знать не должны, как я уже писал firewall ПРОЗРАЧЕН для клиента, есть он, нет его, механизм взаимодействия с сервером один и тот же.
Просто, если порт закрыт, то firewall не пускает клиента...
). Ибо делал это 100 раз. Похоже, что кроме firewall, построенных на NAT, Вы не с чем больше не имели дело . Без обид. Там, да. Клиенту ничего практически знать не надо. Почти не надо. Единственное, что нужно, это указать шлюз (gateway) по умолчанию на сетевом интерфейсе клиента. В этом случае NAT выполняет маскарадинг, только получая от клиента совершенно обычный пакет (как если б пакет направлялся непосредственно в инет, а не раутеру), приходящий на "внутренний" сетевой интерфейс маршрутиризатора. Как работает NAT ? - в принципе писано-переписано. В инете есть много доки. И на русском. Это только моё мнение, что Вы в своём постинге немного не правы. Вопрос ко всем: Checkpoint firewall какого типа?vg писал(а):2Marmot,Зря Вы так. Я на любых форумах говорю только то, что знаю наверняка (привираю только иногда, и не в этом случаеvg, вы чего такое тут несёте, вы когда нибудь работали с нормальными firewall-ми?
Ничего клиенты знать не должны, как я уже писал firewall ПРОЗРАЧЕН для клиента, есть он, нет его, механизм взаимодействия с сервером один и тот же.
Просто, если порт закрыт, то firewall не пускает клиента...
И последнее. Не примите, пожалуйста, за указание, умничение, высокомерие, ну, и т.д. Очень легко убедиться в том, что я говорю. Сами знаете, лучший критерий - опыт. Для такого человека, как Вы написать, например, почтового клиента (любого) - две секунду. Напишите, попробуйте запустить в приватной сети за firewall, там где не NAT При этом я также упорно обращаю Ваше внимание на аббревиатеру "NAT", как вы упорно игнорируете эту деталь
И самое последнее. Понятие, нормальный/ненормальный firewall -весьма относительно. Тем более, что речь идёт о вполне конкретной задаче leonid-а. Посмотрите в начало треда. Леонид пишет, что он не знает, какой firewall будет стоять у его клиентов. Более того, он совершено справедливо предполагает, что у некоторых клиентов в горле сетки будет стоять обычный прокси, работающий по SOCKS, а не маршрутиризатор, на котором поднят NAT. А если так, то в его коммерческой задаче естественно желание учесть все варианты (то, что с Вашей точки зрения является нормальной, и то, что ненормально)
ПС. Кстати socks - документирован rfc. Это стандартная (в буквальном смысле) технология
Хоть Ваше замечание адресовано и не мне, но могу заметить, что Вы здесь не правы. Прав leonid. За одним маленьким исключением, которого, мне кажется, не понимаете (не знаете) Вы.leonid:
Похоже, что остальные предложенные command line или "пакетные" HTTP, FTP и SMPT клиенты не смогут проходить через "ненормальные" firewalls.
Вы так уверены? По крайней мере в документацци к тому HTTP commnad-line client-у написано что он ходит через SOCKS .
Поэтому-то для HTTP и не нужен SOCKS вовсе Отсюда у вас и сложилось мнение, что "...firewall - прозрачный по умолчанию...". Из той же оперы. Дело здесь вовсе не в WinINet, или других библиотеках, а в том, что по умолчанию все firewall (прокси) поддерживают HTTP-proxy. И SOCKS - не нужен.leonid:
Интересно, как с этим обстоят дела в WinINet?
IMHO, хорошо обстoят, это то же код что работает в IE
leonid:
С НТТР всё просто - пакеты шлются прямо в инет, как еслиб этот хост был выставлен непосредственно в инет (т.е. имел бы на сетевом интерфейсе реальный инет IP, см. rfc 1918 о реальных адресах). И это не зависит от того, какой библитотекой Вы пользуютесь при программировании клиента.