Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#11 ar_waitreply() failed, Solaris 9, sid-milter 0.2.7

v0.2.7
closed
5
2005-04-29
2005-04-06
Fredrik Pettai
No

I didn't want to report this as a bug before you looked
at it...in case of that this isn't a bug...

I get a lot of entries like this in my logfile:

Mar 31 20:42:37 aries sid-filter[16515]: [ID 146386
mail.error] j2VIfYUo021869 ar_waitreply() failed
Mar 31 20:42:37 aries sid-filter[16515]: [ID 313135
mail.error] j2VIfYUo021869 sid_marid_check(): -1 ( <
marid ne.citrix-news.net?)
Mar 31 20:42:37 aries sid-filter[16515]: [ID 146386
mail.error] j2VIfYOY021871 ar_waitreply() failed
Mar 31 20:42:37 aries sid-filter[16515]: [ID 313135
mail.error] j2VIfYOY021871 sid_marid_check(): -1 ( <
marid ne.citrix-news.net?)
Mar 31 20:42:37 aries sid-filter[16515]: [ID 146386
mail.error] j2VIfYmt021870 ar_waitreply() failed
Mar 31 20:42:37 aries sid-filter[16515]: [ID 313135
mail.error] j2VIfYmt021870 sid_marid_check(): -1 ( <
marid ne.citrix-news.net?)
Mar 31 20:43:16 aries sid-filter[16515]: [ID 146386
mail.error] j2VIgE9c021923 ar_waitreply() failed
Mar 31 20:43:16 aries sid-filter[16515]: [ID 313135
mail.error] j2VIgE9c021923 sid_marid_check(): -1 ( <
marid ne.citrix-news.net?)

Using "dig -t TXT" on the domain works fine (see
below), but the domain is a CNAME to another domain,
which is a another CNAME to another domain... (its some
sort of e-mail business company working for companies
like citrix for example).
However "dig -t TXT" works fine on all the domains, but
"libar" timeouts anyway. What should sid-filter do in
this kind of situation?

Re,
/P

# dig -t TXT ne.citrix-news.net

; <<>> DiG 9.2.3 <<>> -t TXT ne.citrix-news.net
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32152
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1,
ADDITIONAL: 0

;; QUESTION SECTION:
;ne.citrix-news.net. IN TXT

;; ANSWER SECTION:
ne.citrix-news.net. 3570 IN CNAME
www.emarsys.net.
www.emarsys.net. 7174 IN CNAME
emalb.emarsys.net.

;; AUTHORITY SECTION:
emarsys.net. 120 IN SOA
linbit.com. support.linbit.com. 33 7200 3600 1209600 120

;; Query time: 53 msec
;; SERVER: 151.156.10.12#53(151.156.10.12)
;; WHEN: Thu Mar 31 20:50:42 2005
;; MSG SIZE rcvd: 136

Discussion

  • Fredrik Pettai
    Fredrik Pettai
    2005-04-06

    Logged In: YES
    user_id=370342

    btw. A restart of sid-milter doesn't improve the situation.

    /P

     
    • labels: --> Functionality
    • milestone: --> v0.2.7
    • assigned_to: nobody --> sm-msk
     
  • Logged In: YES
    user_id=1048957

    Modified for next release to be a little more descriptive.

     
  • Fredrik Pettai
    Fredrik Pettai
    2005-04-13

    Logged In: YES
    user_id=370342

    According to the ar_waitreply(),
    there was too many retries (see log below).
    But dig from the same machine works perfectly well... (see
    the dig results below). How many retries does does it do?
    Any ideas?
    Perhaps add a flag to tune max retries/timing of retries?

    Sendmail log from the new patch:

    Apr 13 11:14:25 libra sendmail[8693]: [ID 801593 mail.info]
    j3D9EP7w008693: Milter (sid-filter): init success to negotiate
    Apr 13 11:14:25 libra sendmail[8693]: [ID 801593 mail.info]
    j3D9EP7w008693: Milter: connect to filters
    Apr 13 11:14:27 libra sendmail[8693]: [ID 801593 mail.info]
    j3D9EP7w008693: Authentication-Warning: libra.vattenfall.se:
    Host [212.105.105.50] claimed to be smtp.servisen.se
    Apr 13 11:14:27 libra sendmail[8693]: [ID 801593 mail.info]
    j3D9EP7w008693: from=<info@arenagroup.se>, size=1560,
    class=0, nrcpts=1,
    msgid=<002501c54006$6badc960$0364a8c0@Sponsorservice.local>,
    proto=ESMTP, daemon=MTA-v4, relay=[212.105.105.50]
    Apr 13 11:15:05 libra sid-filter[6048]: [ID 337111
    mail.error] j3D9EP7w008693 ar_waitreply() failed: Too many
    retries
    Apr 13 11:15:05 libra sid-filter[6048]: [ID 313135
    mail.error] j3D9EP7w008693 sid_marid_check(): -1 ( < marid
    arenagroup.se?)
    Apr 13 11:15:05 libra sendmail[8693]: [ID 801593 mail.info]
    j3D9EP7w008693: Milter: data, reject=451 4.3.2 Please try
    again later
    Apr 13 11:15:05 libra sendmail[8693]: [ID 801593 mail.info]
    j3D9EP7w008693: to=<Helena.Kortered@vattenfall.com>,
    delay=00:00:38, pri=31560, stat=Please try again later

    Dig results...

    # dig -t TXT arenagroup.se

    ; <<>> DiG 9.3.1 <<>> -t TXT arenagroup.se
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2034
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
    ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;arenagroup.se. IN TXT

    ;; AUTHORITY SECTION:
    arenagroup.se. 1251 IN SOA
    ns.servisen.se. administrator.servisen.se. 20040627 900 600
    86400 3600

    ;; Query time: 6 msec
    ;; SERVER: 192.36.28.1#53(192.36.28.1)
    ;; WHEN: Wed Apr 13 11:53:53 2005
    ;; MSG SIZE rcvd: 93

    /P

     
  • Fredrik Pettai
    Fredrik Pettai
    2005-04-13

    Logged In: YES
    user_id=370342

    Now, then i look at all ar_waitreply() 's, they all point at
    ---> ar_waitreply() failed: Too many retries

    Maybe there a point making a extra flag/feature to change
    the maximum retries for libar to a custom value?

    /P

     
  • Logged In: YES
    user_id=1048957

    libar uses the default retry count and retransmission timer
    provided by the resolver, meaning it uses the same retry and
    timeout values that BIND does by default. There's a way to
    change these values but it's not exposed in sid-milter.

    You will get a quick response for your query because the
    nameserver has the reply in its cache now. I did the same
    query on my workstation and got:

    ; <<>> DiG 8.3 <<>> arenagroup.se. txt
    ;; res options: init recurs defnam dnsrch
    ;; got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24918
    ;; flags: qr aa ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
    ADDITIONAL: 0
    ;; QUERY SECTION:
    ;; arenagroup.se, type = TXT, class = IN

    ;; AUTHORITY SECTION:
    arenagroup.se. 1H IN SOA ns.servisen.se.
    administrator.servisen.se. (
    20040627 ; serial
    15M ;
    refresh
    10M ; retry
    1D ; expiry
    1H ) ;
    minimum

    ;; Total query time: 14031 msec
    ;; FROM: protagonist.smi.sendmail.com to SERVER: 10.210.100.115
    ;; WHEN: Wed Apr 13 12:38:28 2005
    ;; MSG SIZE sent: 31 rcvd: 93

    Just over 14 seconds to get the answer back. Looks like a
    slow nameserver to me. I believe the retry count is 3 by
    default and the retry timer is five seconds, so that was one
    second short of failing.

    A second query of the same address, now cached, took 2 msec.

     
  • Fredrik Pettai
    Fredrik Pettai
    2005-04-29

    • status: open --> closed
     
  • Fredrik Pettai
    Fredrik Pettai
    2005-04-29

    Logged In: YES
    user_id=370342

    Yep, this is not a bug... I will make it a RFE instead...

    Re,
    /P