[exim-dev] [Bug 1424] Exim stuck on $sender_host_name in not…

トップ ページ
このメッセージを削除
このメッセージに返信
著者: Jeremy Harris
日付:  
To: exim-dev
古いトピック: [exim-dev] [Bug 1424] New: Exim stuck on $sender_host_name in notquit ACL
題目: [exim-dev] [Bug 1424] Exim stuck on $sender_host_name in notquit ACL
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=1424

Jeremy Harris <jgh146exb@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|tlyons@???           |jgh146exb@???





--- Comment #2 from Jeremy Harris <jgh146exb@???> 2015-03-29 15:34:43 ---
As of writing,

https://www.gnu.org/software/libc/manual/html_node/Host-Names.html#index-converting-host-address-to-name

... lists gethostbyname2() as AS-unsafe. getaddrinfo() is noted as another
possible means for getting the implementation, but there is no proper
definition
of it, let alone async-signal safety information. getipnodebyname() is
listed by Oracle

http://docs.oracle.com/cd/E36784_01/html/E36875/getipnodebyname-3socket.html

but does not specify signal-safety (either way). It was briefly present in
glibc, but then apparently deprecated in favour of getaddrinfo().

At least some implementations of getaddrinfo() are problematic:

http://blog.powerdns.com/2014/05/21/a-surprising-discovery-on-converting-ipv6-addresses-we-no-longer-prefer-getaddrinfo/


What a mess. It does feel like calling the acl_notquit processing from
within the signal-handler, local_scan_timeout_handler()/receive_bomb_out()
is a trifle ambitious. It's been like that since 2007 when this acl was added.
Back in the depths of Unix history this would have been a case for longjmp()
(the opinion was expressed once that there is about only one thing safe to
do in a signal handler: modify an int-sized flag). I wonder if this is still
the case.


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email