Hi Eric,

I thought about that and checked before. There is no such file or script
not in /home/fiberdesignsourcing.com/ or /home/
fiberdesignsourcing.com/domains/fiberdesignsourcing.com/zahir/Maildir/

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 <ebr...@whitehorsetc.com> wrote:

> Do you have a script in /home/vpopmail/domain/yourdomain.com/user,
> 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, <ebr...@whitehorsetc.com> wrote:
>
>> 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?
>>
>> Eric
>> On 7/23/2019 1:53 AM, Tahnan Al Anas wrote:
>>
>> Hi,
>>
>> 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 <ebr...@whitehorsetc.com>
>> wrote:
>>
>>> Angus,
>>>
>>> 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 (127.0.0.1) 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.
>>>
>>> Eric
>>>
>>> Get Outlook for Android <https://aka.ms/ghei36>
>>>
>>>
>>>
>>>
>>> On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre" <an...@pobox.com
>>> > wrote:
>>>
>>> r...@mattei.org wrote on 7/22/19 10:22 AM:
>>>>  > You need to install the cert on your machine. Does the /etc/hosts
>>>>  > 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 pings.
>>>>
>>>>
>>>> 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:
>>>>
>>>>    127.0.1.1 s6.mydomain.com s6
>>>>
>>>> (obviously, 'mydomain' is not the actual name here). The .pem file
>>>> contains the lines:
>>>>
>>>>    Subject: OU=Domain Control Validated, OU=PositiveSSL,
>>>> CN=mail.mydomain.dev
>>>>
>>>> and
>>>>
>>>>    X509v3 Subject Alternative Name:
>>>>      DNS:mail.mydomain.dev, DNS:www.mail.mydomain.dev
>>>>
>>>> 's6.mydomain.com' and 'mail.mydomain.dev' all resolve to the same IP.
>>>>
>>>> My existing qmailtoaster server (running an older version of the
>>>> software) has '/etc/hosts' containing:
>>>>
>>>>    127.0.1.1 s2.mydomain.com s2
>>>>
>>>> and the .pem file contains:
>>>>
>>>>    Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain,
>>>> CN=mydomain.com
>>>>
>>>> and
>>>>
>>>>    X509v3 Subject Alternative Name:
>>>>      DNS:mydomain.com, DNS:mail.mydomain.com, DNS:www.mydomain.com
>>>>
>>>> 's6.mydomain.com' resolves to the same IP as 'mail.mydomain.dev';
>>>> 's2.mydomain.com' resolves to the same IP as 'mail.mydomain.com'.
>>>>
>>>> As far as I can see, the two situations are equivalent, with the slight
>>>> difference that the official server name of the new box
>>>> ('s6.mydomain.com') is not a subdomain of the domain in the PEM file
>>>> ('mail.mydomain.dev'), whereas on the old box the name of the host
>>>> ('s2.mydomain.com') is a subdomain of one of the domain names in the PEM
>>>> file ('mydomain.com'). I don't know if this is a possible cause of my
>>>> problems.
>>>>
>>>> One other difference is that I don’t have a PTR record for
>>>> 's6.mydomain.com'. An RDNS lookup on the IP of 's2.mydomain.com' will
>>>> yield 's2.mydomain.com', but an RDNS lookup on the IP of
>>>> 's6.mydomain.com' 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.
>>>>
>>>> Thanks,
>>>>
>>>> Angus
>>>>
>>>>
>>>>
>>>> >
>>>> >> 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, using:
>>>> >>
>>>> >>     yum --enablerepo=qmt-testing update
>>>> >>     yum --enablerepo=qmt-devel update
>>>> >>
>>>> >> as on the homepage of qmailtoaster.com. After installation, I patched 
>>>> >> the Squirrelmail config and the smtps supervise as directed at:
>>>> >>
>>>> >>     http://www.qmailtoaster.com/sqmailconfig.html
>>>> >>
>>>> >> Attempting to send from SquirrelMail produces the message:
>>>> >>
>>>> >>     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 127.0.0.1
>>>> >>   2019-07-22 02:45:15.179905500 tcpserver: ok 2843 s6:127.0.0.1:465
>>>> >>     :127.0.0.1::58822
>>>> >>   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/config.inc.php' so 
>>>> >> that it contains:
>>>> >>
>>>> >>   $config['smtp_server'] = 'tls://mail.myhost.com';
>>>> >>
>>>> >>   $config['smtp_conn_options'] = array(
>>>> >>      'ssl' => array(
>>>> >>         'peer_name' => 'mail.myhost.com',
>>>> >>         'verify_peer'  => true,
>>>> >>         'verify_depth' => 3,
>>>> >>         'cafile'       => '/var/qmail/control/servercert.pem',
>>>> >>    ),
>>>> >>   );
>>>> >>
>>>> >> (where 'mail.myhost.com' 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://mail.myhost.com:587...
>>>> >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 220 s6.myhost.net -
>>>> >>   Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server ESMTP
>>>> >>   [21-Jul-2019 22:26:08 -0400]:  Send: EHLO mail.myhost.com
>>>> >>   [21-Jul-2019 22:26:08 -0400]:  Recv: 250-s6.myhost.net -
>>>> >>   Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server
>>>> >>   [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 routines:SSL23_GET_CLIENT_HELLO:unknown
>>>> >>   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: qmailtoaster-list-unsubscr...@qmailtoaster.com
>>>> >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>>>> >>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
>>>> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>>>>
>>>>

Reply via email to