Postfix: fatal bad network port in destination

Discussion in 'ISPConfig 3 Priority Support' started by MaxT, Apr 2, 2019.

  1. MaxT

    MaxT Member HowtoForge Supporter

    I have this error in Postfix log:

    Code:
    Apr  2 13:54:14 host postfix/smtp[15549]: fatal: bad network port in destination: [127.0.0.1]:100244
    Apr  2 13:54:15 host postfix/qmgr[14984]: warning: private/amavis socket: malformed response
    Apr  2 13:54:15 host postfix/qmgr[14984]: warning: transport amavis failure -- see a previous warning/fatal/panic logfile record for the problem description
    Apr  2 14:47:09 host postfix/master[20858]: warning: process /usr/lib/postfix/sbin/smtp pid 22586 exit status 1
    Apr  2 14:47:09 host postfix/master[20858]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
    Apr  2 14:47:09 host postfix/qmgr[20860]: warning: private/amavis socket: malformed response
    Apr  2 14:47:09 host postfix/qmgr[20860]: warning: transport amavis failure -- see a previous warning/fatal/panic logfile record for the problem description
    
    Time ago I have mispelled the port number inside file tag_as_foreign.re
    Code:
    /^/ FILTER amavis:[127.0.0.1]:100024
    
    and then I have corrected that line with 10024:
    Code:
    /^/ FILTER amavis:[127.0.0.1]:10024
    
    I have recreated both sender_access.db and virtual.db
    Code:
    postmap /etc/postfix/sender_access
    postmap /etc/postfix/virtual
    
    service postfix restart
    
    when I start postfix don't show me the error. However, after some time, when some outer message is coming, the error appears again. And the message cannot enter.

    I have deleted both postfix caches:

    Code:
    rm /var/lib/postfix/smtpd_scache.db
    rm /var/lib/postfix/smtpd_scache.db
    
    and then restarted Postfix. However, the error still reappears.

    Inside master.cf I have:

    Code:
    127.0.0.1:10025 inet n - n - - smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes
        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
        -o smtp_send_xforward_command=yes
     
    127.0.0.1:10027 inet n - n - - smtpd
        -o content_filter=
        -o local_recipient_maps=
        -o relay_recipient_maps=
        -o smtpd_restriction_classes=
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_recipient_restrictions=permit_mynetworks,reject
        -o mynetworks=127.0.0.0/8
        -o strict_rfc821_envelopes=yes
        -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
        -o smtp_send_xforward_command=yes
        -o milter_default_action=accept
        -o milter_macro_daemon_name=ORIGINATING
     
    
     
    amavis unix - - - - 2 smtp
            -o smtp_data_done_timeout=1200
            -o smtp_send_xforward_command=yes
                    -o smtp_bind_address=
    
    
    there is no 10024 allthough I'm not sure this can have something to do...

    I do a #grep 100024 /etc/postfix/* without result.

    I have repeated this process 3 times without result. It seems as is the old mispellled port ":100024 " still is present in some place that I Ignore
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    10024 is the port that amavis is listening on, so that's defined in the amavis config and not postfix master.cf.

    Try this:

    grep -r 100024 /etc

    to see if this number is used in other files. It might be though, that you still have mails in the mailqueue that try to connect to the old port number.
     
    MaxT likes this.
  3. MaxT

    MaxT Member HowtoForge Supporter

    yes, it appears inside /etc/rpc
    Code:
    # This file contains user readable names that can be used in place of rpc
    # program numbers.
    
    portmapper      100000  portmap sunrpc
    rstatd          100001  rstat rstat_svc rup perfmeter
    rusersd         100002  rusers
    nfs             100003  nfsprog
    ypserv          100004  ypprog
    mountd          100005  mount showmount
    ypbind          100007
    walld           100008  rwall shutdown
    yppasswdd       100009  yppasswd
    etherstatd      100010  etherstat
    rquotad         100011  rquotaprog quota rquota
    sprayd          100012  spray
    3270_mapper     100013
    rje_mapper      100014
    selection_svc   100015  selnsvc
    database_svc    100016
    rexd            100017  rex
    alis            100018
    sched           100019
    llockmgr        100020
    nlockmgr        100021
    x25.inr         100022
    statmon         100023
    status          100024
    bootparam       100026
    ypupdated       100028  ypupdate
    keyserv         100029  keyserver
    tfsd            100037
    nsed            100038
    nsemntd         100039
    ypxfrd          100069
    pcnfsd          150001
    amd             300019  amq
    sgi_fam         391002
    ugidd           545580417
    fypxfrd         600100069       freebsd-ypxfrd
    bwnfsd          788585389
    
    is there some relation?

    And yes, I have quite messages in the queue according #postqueue -p

    and wiith #postcat -q 47DEAB803CA I can see inside them like this:
    Code:
    *** HEADER EXTRACTED deferred/4/id ***
    content_filter: amavis:[127.0.0.1]:100244
    *** MESSAGE FILE END deferred/4/47DEAB803CA ***
    
    How can I alliberate all them?
     
    Last edited: Apr 2, 2019
  4. till

    till Super Moderator Staff Member ISPConfig Developer

    There is no relation with /etc/rpc

    Then the problem is that messages with wrong port are still in the queue. Maybe requeening them might help:

    postsuper -r ALL
     
    MaxT likes this.
  5. MaxT

    MaxT Member HowtoForge Supporter

    yes! it works:) . Big thanks... you are like an oracle.

    I suppose the error now is solved becausee the cause were the messages instead amavis... It isn't?
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Yes, the problem should be fixed now.
     
    MaxT likes this.

Share This Page