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 <[email protected]> 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, <[email protected]> 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 <[email protected]> >> 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" <[email protected] >>> > wrote: >>> >>> [email protected] 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: [email protected] >>>> >> For additional commands, e-mail: [email protected] >>>> >> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>>
