Do you have maildrop installed?

On 8/6/2019 1:13 AM, Tahnan Al Anas wrote:
Dear Eric,

I am suing centos 7. I tried many ways but somehow mail is getting delivered to junk folder. I tried same doamin such as <> to <> and mail is getting delivered to junk folder. Below is the header of the mail.

qmail default cotaint | /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox

*Return-Path:* < <>> *Delivered-To:* <>
*Received:* (qmail 29911 invoked by uid 89); 4 Aug 2019 04:58:00 -0000
*Received:* by simscan 1.4.0 ppid: 29903, pid: 29907, t: 0.0875s
     scanners: attach: 1.4.0 clamav: 0.100.2/m:58/d:25530
*Received:* from unknown (HELO Shital) ( <>@ <>)      by <> with ESMTPA; 4 Aug 2019 04:58:00 -0000 *From:* "Shital" < <>> *To:* "'Nur Knitwear, Syed Hassan'" < <>>


Best Regards
Muhammad Tahnan Al Anas

On Wed, Jul 24, 2019 at 4:09 AM Eric Broch < <>> wrote:


    What is the version of Qmail you are running and the OS?
    Qmailtoaster does not have any stock message filters as far as I know.

    In Qmailtoaster the stock delivery program is vpopmail's
    vdelivermail program called in .qmail-default for each domain

    I'm sure that Roundcube doesn't have message filtering, but
    Squirrelmail does. You may look for a message filter there. I'm
    not sure whether Rainloop has message filtering.


    On 7/23/2019 12:13 PM, Tahnan Al Anas wrote:
    Hi Eric,

    I thought about that and checked before. There is no such file or
    script not in /home/

    There is only .qmail file which have ./Maildir text. This issue
    happen in multiple server. I guess this might have something to
    with webmail application. I will check and update all. If you
    have any other suggestion please let advice.


    Best Regards
    Muhammad Tahnan Al Anas

    On Tue, Jul 23, 2019 at 8:23 PM Eric Broch
    < <>> wrote:

        Do you have a script in
        <>, perhaps a .qmail file with
        .mailfilter script?

        On 7/23/2019 7:48 AM, Tahnan Al Anas wrote:
        Hi Eric,

        Thank you for your reply. The issue is happening in webmail.
        I am using roundcube, squirrel mail, rain loop and after
        logic webmail. Some user use Microsoft outlook. But mail
        that received by server going to squirrel, roundcube spam
        folder, for which client unable to get it in their outlook
        inbox. I have increased simscan hit from 12 to 80 to test,
        also whilst domain. You have any idea why it might happen?

        On Tue, 23 Jul 2019, 6:50 pm Eric Broch,
        < <>>

            Hi Muhammad,

            I don't think QMT 'naturally' any mail to spam folder.
            Is this perhaps a client setting? What email client are
            they using?


            On 7/23/2019 1:53 AM, Tahnan Al Anas wrote:

            Some of my user are getting mail at their spam box from
            some domain. Can you suggest what can be done to
            prevent mail getting delivered at spam box? They prefer
            to get it in inbox.


            Best Regards
            Muhammad Tahnan Al Anas

            On Tue, Jul 23, 2019 at 8:41 AM Eric's mail
            <>> wrote:


                Did you think about simply using port 25, no
                authentication or encryption, which is how
                squirrelmail on QMT used to be configured, relying
                on HTTPS alone for password and email security
                across the cloud as the email (after the cloud) is
                submitted directly to the server (tcpserver) by the
                server (apache) itself ( rendering
                encryption useless or redundant. I think this is
                the route I will go because with every upgrade of
                roundcube, the webmail I prefer, there seems to be
                issues with past configurations.


                Get Outlook for Android <>

                On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus
                McIntyre" <
                <>> wrote:

            <>  wrote on 7/22/19 
10:22 AM:
                      > You need to install the cert on your machine. Does the 
                      > have the name of your machine can you try to ping that 
name to
                      > see if it resolves?

                    The certificate is installed.

                    The hostname in '/etc/hosts' resolves, and responds to 

                    I replaced the self-signed PEM that shipped with 
qmailtoaster with one
                    that I made myself by concatenating the ‘.key’ and ‘.crt’ 
files from my
                    server certificate. Inspecting the resulting .pem with 
‘openssl x509 -in
                    servercert.pem -text’ confirms that the resulting .pem is 
for the domain
                    that I expect. File permissions and ownership are correct.

                    '/etc/hosts' for my newly-built server contains the 
following line:

                <>  s6

                    (obviously, 'mydomain' is not the actual name here). The 
.pem file
                    contains the lines:

                        Subject: OU=Domain Control Validated, OU=PositiveSSL,


                        X509v3 Subject Alternative Name:
                  <>,  <>

                    '  <>' and' 
 <>' all resolve to the same IP.

                    My existing qmailtoaster server (running an older version 
of the
                    software) has '/etc/hosts' containing:

                <>  s2

                    and the .pem file contains:

                        Subject: OU=Domain Control Validated, OU=PositiveSSL 


                        X509v3 Subject Alternative Name:
<>,  <>

                    '  <>' resolves to the same 
IP as'  <>';
                    '  <>' resolves to the same 
IP as'  <>'.

                    As far as I can see, the two situations are equivalent, 
with the slight
                    difference that the official server name of the new box
                    ('  <>') is not a 
subdomain of the domain in the PEM file
                    ('  <>'), whereas 
on the old box the name of the host
                    ('  <>') is a 
subdomain of one of the domain names in the PEM
                    file ('  <>'). I don't know 
if this is a possible cause of my

                    One other difference is that I don’t have a PTR record for
                    '  <>'. An RDNS lookup on 
the IP of'  <>' will
                    yield '  <>', but an 
RDNS lookup on the IP of
                    '  <>' yields the FQDN 
of the Linode VM it runs on. Could
                    that be an issue?

                    I'll keep digging on this, but if anyone has any 
suggestions of tests or
                    tools I might use, I'd welcome your recommendations.



> >> Il giorno 21 lug 2019, alle ore 20:03, Angus McIntyre ha scritto:
                    >> Thanks to a great deal of help from Remi and Eric, I 
have now managed to get my Ansible role to the point where it can successfully build 
out a QMailToaster server running PHP 7.1 and RoundCube 1.4rc1.
                    >> However, because nothing is ever that easy, RoundCube 
and SquirrelMail have now stopped sending mail (RainLoop works fine).
                    >> 1) SquirrelMail
                    >> SquirrelMail was installed from the qmailtoaster RPMs, 
                    >>     yum --enablerepo=qmt-testing update
                    >>     yum --enablerepo=qmt-devel update
                    >> as on the homepage of  
<>. After installation, I patched the Squirrelmail config and 
the smtps supervise as directed at:
                    >> Attempting to send from SquirrelMail produces the 
                    >>     0 Can't open SMTP stream
                    >> The /var/log/qmail/smtps/current log shows:
                    >>   2019-07-22 02:45:15.173127500 tcpserver: status: 1/100
                    >>   2019-07-22 02:45:15.179903500 tcpserver: pid 2843 from
                    >>   2019-07-22 02:45:15.179905500 tcpserver: ok 2843 
s6:  <>
                    >>     :
                    >>   2019-07-22 02:45:15.197381500 tcpserver: end 2843 
status 256
                    >>   2019-07-22 02:45:15.197383500 tcpserver: status: 0/100
                    >> 2) RoundCube
                    >> RoundCube is 1.4rc1, installed from the remi-test repo. 
Following Eric's instructions, I edited '/etc/roundcubemail/' so that 
it contains:
                    >>   $config['smtp_server'] = 'tls://  
                    >>   $config['smtp_conn_options'] = array(
                    >>      'ssl' => array(
                    >>         'peer_name' => '  
                    >>         'verify_peer'  => true,
                    >>         'verify_depth' => 3,
                    >>         'cafile'       => 
                    >>    ),
                    >>   );
                    >> (where '  <>' is 
the actual name of my mailserver, as it appears in the 'servercert.pem' file).
                    >> Trying to send from RoundCube produces a 220 
Authentication Failed message. The transcript in RoundCube's SMTP log looks like:
                    >>   [21-Jul-2019 22:26:08 -0400]:  Connecting to
                    >>   tls://
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 220  
<>  -
                    >>   Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP 
Server ESMTP
                    >>   [21-Jul-2019 22:26:08 -0400]:  Send: EHLO  
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv:  
<>  -
                    >>   Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP 
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 250-STARTTLS
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 250-PIPELINING
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 250-8BITMIME
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 250 SIZE 20971520
                    >>   [21-Jul-2019 22:26:08 -0400]:  Send: STARTTLS
                    >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 220 ready for tls
                    >>   [21-Jul-2019 22:26:08 -0400]:  Send: RSET
                    >>   [21-Jul-2019 22:27:08 -0400]:  Send: QUIT
                    >>   [21-Jul-2019 22:27:08 -0400]:  Recv: 454 TLS connection
                    >>   failed: error:140760FC:SSL 
                    >>   protocol (#4.3.0)
                    >> 3) Desktop client
                    >> Trying to send from a desktop client (PostBox) also 
fails, generating the warning:
                    >>   Could not verify this certificate because the issuer 
is unknown
                    >> The issuer in this case is actually Sectigo, which is 
the new name for Comodo, who should be reasonably reputable.
                    >> The 'servercert.pem' file that I'm using is generated 
from the same '.key' and '.crt' files that I use to secure the webserver, which 
appear to work fine in that context.
                    >> Has anyone encountered this issue, or can suggest a 
possible fix?
                    >> Thanks for any help you can give me,
                    >> Angus
                    >> To unsubscribe, e-mail:  
                    >> For additional commands, e-mail:  

                    To unsubscribe,  
                    For additional commands,  

Reply via email to