Re: [qmailtoaster] OT - Question about Rocky Linux
Hey thanks and yeah - that would be based on https://hub.docker.com/_/rockylinux (https://hub.docker.com/_/rockylinux) which is maintained by Rocky Linux I think it would be solid Cheers David Bray e. da...@brayworth.com February 20, 2024 9:23 AM, "Remo Mattei" mailto:r...@mattei.org?to=%22Remo%20Mattei%22%20)> wrote: David, to make that a dockerized solution you will want to do the following: 1) container for qmail 2) container for mysql 3) container for httpd 4) container for dovecot 5 container for round cube My 2 cents. Remo On Feb 19, 2024, at 15:20, David Bray mailto:da...@brayworth.com)> wrote: You can probably setup QMail toaster under docker, it would negate any arguments Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) February 19, 2024 8:26 AM, "Jeff Koch" mailto:jeffk...@intersessions.com?to=%22jeff%20koch%22%20%3cjeffk...@intersessions.com%3E)> wrote: Hi - this is really OT but I trust the judgement of this group. All of our servers are running CentOS 7 and we're little leery of the CentOS stream and with RedHat having taken over CentOS. However, we've been in the RH Linux eco-system for 25 years and SUSE, Debian and Ubuntu would be a tough adjustment. I hear a lot about Rocky Linux. Are you CentOS guys comfortable with Rocky Linux? Jeff On 2/18/2024 4:28 PM, Gary Bowling wrote: What is everyone doing with selinux on new Rocky 9 builds? In the past, I've always disabled selinux. But maybe for some added security it's time to do something different. I've learned a bit about selinux and am using it successfully in my new web servers. But it comes with some things already set up for nginx and standard web directories. It will be a bit trickier with a "toaster." Thanks, gb -- The Moderns on Spotify (https://distrokid.com/hyperfollow/themoderns/bbrs) - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com (mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com) For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com (mailto:qmailtoaster-list-h...@qmailtoaster.com)
Re: [qmailtoaster] OT - Question about Rocky Linux
You can probably setup QMail toaster under docker, it would negate any arguments Cheers David Bray e. da...@brayworth.com February 19, 2024 8:26 AM, "Jeff Koch" mailto:jeffk...@intersessions.com?to=%22Jeff%20Koch%22%20)> wrote: Hi - this is really OT but I trust the judgement of this group. All of our servers are running CentOS 7 and we're little leery of the CentOS stream and with RedHat having taken over CentOS. However, we've been in the RH Linux eco-system for 25 years and SUSE, Debian and Ubuntu would be a tough adjustment. I hear a lot about Rocky Linux. Are you CentOS guys comfortable with Rocky Linux? Jeff On 2/18/2024 4:28 PM, Gary Bowling wrote: What is everyone doing with selinux on new Rocky 9 builds? In the past, I've always disabled selinux. But maybe for some added security it's time to do something different. I've learned a bit about selinux and am using it successfully in my new web servers. But it comes with some things already set up for nginx and standard web directories. It will be a bit trickier with a "toaster." Thanks, gb -- The Moderns on Spotify (https://distrokid.com/hyperfollow/themoderns/bbrs) - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com (mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com) For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com (mailto:qmailtoaster-list-h...@qmailtoaster.com)
Re: [qmailtoaster] iPhone updates / new ssl breaks connection
I'm using Letsencrypt and it renews every - well not sure, is it 10/11 weeks - the certs are valid for 3 months It never has an issue with iOS Cheers David Bray e. da...@brayworth.com April 27, 2022 1:47 AM, "Remo Mattei" wrote: > Hello guys, > I got a few of my customers that every year after the upgrade of the SSL cert > do have issues and > shows cert expired or not valid. I did not have the issue on my iOS, but I > just wonder if anyone > has seen that and how they planned to overcome to this issue. > > Thanks, > Remo > - > 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
Re: [qmailtoaster] Smtproutes
Hey - thanks for reply It doesn't bounce I set the catchall to my account so I could figure this I'm thinking this is todo with return path - or perhaps Mail From via mailgun, it comes back to : bounce+ee51da.72c943-qmailtoaster-list=qmailtoaster@brayworth.com, with a response that I'm not a subscriber so I did some testing by using the smtroutes method, the result was the same So - thinking this is to do with ezmlm which is probably responding to the "MAIL FROM" command, which is mutated by mailgun perhaps authsenders this is a good system, but mailgun is not so good as a smtpprovidor The actual response from qmailtoaster: Hi. This is the qmail-send program at mail.whitehorsetc.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, only subscribers may post. If you are a subscriber, please forward this message to qmailtoaster-list-ow...@qmailtoaster.com to get your new address included (#5.7.2) --- Below this line is a copy of the message. Return-Path: Cheers David Bray e. da...@brayworth.com January 5, 2022 8:22 PM, "xaf" wrote: > Can you post the headers from bounced email. > You said mailgun rewrite envelope from, have a look at > https://help.mailgun.com/hc/en-us/articles/360012491394-Why-Do-I-See-On-Behalf-Of-in-My-Email- > > subscribed email through your host > da...@brayworth.com: > others through mailgun > @brayworth.com:smtp.mailgun.org:587|user1mailgun|passwd > > xaf > > David Bray a écrit le 04/01/2022 à 23:37 : >> and I can report it works ! OMG >> >> but, it works for everything except noticably - this mailing list >> >> I receive a message in logs >> 2022-01-04 21:59:25.836113500 simscan:[22631]:CLEAN >> (-0.10/10.00):1.8801s:failure >> notice:66.62.95.221::bounce+ee51da.72c943-qmailtoaster-list=qmail >> toaster@brayworth.com >> >> xaf might comment >> >> so close ... ! >> >> Cheers >> >> David Bray >> e. da...@brayworth.com >> >> January 5, 2022 7:52 AM, "Eric Broch" > >> >> wrote: >> >> It is in the patch >> >> On 1/4/2022 2:42 PM, David Bray wrote: > > Hey Eric - sorry to direct to you - but authsenders - is this an option ? > > Cheers > > David Bray > e. da...@brayworth.com > > January 4, 2022 9:56 PM, "xaf" wrote: > > Did you try authsenders? > > https://www.fehcom.de/qmail/smtpauth.html##SETUP > Setting up qmail-remote for SMTP Authentication > control/authsenders: > eschm...@google.com:gmail-smtp-in.l.google.com:587|E. Schmidt|topsecret > > @senderdomain1.com:smtp.mailgun.org:587|user1mailgun|passwd > @senderdomain2.com:smtp.mailgun.org:587|user2mailgun|passwd > > xaf > > David Bray a écrit le 04/01/2022 à 06:07 : > > true, but relaying with a username/password > > so just trying to solve the linode problem by using a upstream smtp service > (mailgun) > it works on the first domain, but not the subsequent domains, because a > separate set of creds can't > be specified for sending from the 2nd domain > > Cheers > > David Bray > e. da...@brayworth.com > > January 4, 2022 2:58 PM, "Eric Broch" >> > wrote: > > All you're doing is relaying through another host. > > On 1/3/2022 9:41 PM, David Bray wrote: > > and to answer the question > > * yes, it is valid - but the format is [optiional target domain]:relay > server:port|username|password > > but, that only allows one username for many virtual domains ... > > * so using mailgun or any smtp relay service is not an option - if you have > virtual domains ... [my > assumption] > > Cheers > > David Bray > e. da...@brayworth.com > > January 4, 2022 1:56 PM, "David Bray" >> wrote: > > Hi, Is this page valid > > * http://wiki.qmailtoaster.com/index.php/Smtproutes > > in particular the username/password settings > > It doesn't seem to be included in http://qmailtoaster.org > > I'm thinking of relaying through mailgun.com > > Cheers > > David Bray > e. da...@brayworth.com > > - > 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 - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Smtproutes
and I can report it works ! OMG but, it works for everything except noticably - this mailing list I receive a message in logs 2022-01-04 21:59:25.836113500 simscan:[22631]:CLEAN (-0.10/10.00):1.8801s:failure notice:66.62.95.221::bounce+ee51da.72c943-qmailtoaster-list=qmail toaster@brayworth.com xaf might comment so close ... ! Cheers David Bray e. da...@brayworth.com January 5, 2022 7:52 AM, "Eric Broch" mailto:ebr...@whitehorsetc.com?to=%22Eric%20Broch%22%20)> wrote: It is in the patch On 1/4/2022 2:42 PM, David Bray wrote: Hey Eric - sorry to direct to you - but authsenders - is this an option ? Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 9:56 PM, "xaf" mailto:x...@abaxe.net)> wrote:Did you try authsenders? https://www.fehcom.de/qmail/smtpauth.html##SETUP (https://www.fehcom.de/qmail/smtpauth.html##SETUP) Setting up qmail-remote for SMTP Authentication control/authsenders: eschm...@google.com (mailto:eschm...@google.com):gmail-smtp-in.l.google.com:587|E. Schmidt|topsecret @senderdomain1.com:smtp.mailgun.org:587|user1mailgun|passwd @senderdomain2.com:smtp.mailgun.org:587|user2mailgun|passwd xaf David Bray a écrit le 04/01/2022 à 06:07 :true, but relaying with a username/password so just trying to solve the linode problem by using a upstream smtp service (mailgun) it works on the first domain, but not the subsequent domains, because a separate set of creds can't be specified for sending from the 2nd domain Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 2:58 PM, "Eric Broch" mailto:ebr...@whitehorsetc.com) mailto:ebr...@whitehorsetc.com)?to=%22Eric%20Broch%22%20mailto:ebr...@whitehorsetc.com)>>> wrote: All you're doing is relaying through another host. On 1/3/2022 9:41 PM, David Bray wrote: and to answer the question * yes, it is valid - but the format is [optiional target domain]:relay server:port|username|password but, that only allows one username for many virtual domains ... * so using mailgun or any smtp relay service is not an option - if you have virtual domains ... [my assumption] Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 1:56 PM, "David Bray" mailto:da...@brayworth.com) mailto:da...@brayworth.com)?to=%22David%20Bray%22%20mailto:da...@brayworth.com)>>> wrote: Hi, Is this page valid * http://wiki.qmailtoaster.com/index.php/Smtproutes (http://wiki.qmailtoaster.com/index.php/Smtproutes) in particular the username/password settings It doesn't seem to be included in http://qmailtoaster.org (http://qmailtoaster.org) I'm thinking of relaying through mailgun.com Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com (mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com) For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com (mailto:qmailtoaster-list-h...@qmailtoaster.com)
Re: [qmailtoaster] Smtproutes
Hey Eric - sorry to direct to you - but authsenders - is this an option ? Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 9:56 PM, "xaf" mailto:x...@abaxe.net)> wrote: Did you try authsenders? https://www.fehcom.de/qmail/smtpauth.html##SETUP (https://www.fehcom.de/qmail/smtpauth.html##SETUP) Setting up qmail-remote for SMTP Authentication control/authsenders: eschm...@google.com (mailto:eschm...@google.com):gmail-smtp-in.l.google.com:587|E. Schmidt|topsecret @senderdomain1.com:smtp.mailgun.org:587|user1mailgun|passwd @senderdomain2.com:smtp.mailgun.org:587|user2mailgun|passwd xaf David Bray a écrit le 04/01/2022 à 06:07 : true, but relaying with a username/password so just trying to solve the linode problem by using a upstream smtp service (mailgun) it works on the first domain, but not the subsequent domains, because a separate set of creds can't be specified for sending from the 2nd domain Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 2:58 PM, "Eric Broch" mailto:ebr...@whitehorsetc.com) mailto:ebr...@whitehorsetc.com)?to=%22Eric%20Broch%22%20mailto:ebr...@whitehorsetc.com)>>> wrote: All you're doing is relaying through another host. On 1/3/2022 9:41 PM, David Bray wrote: and to answer the question * yes, it is valid - but the format is [optiional target domain]:relay server:port|username|password but, that only allows one username for many virtual domains ... * so using mailgun or any smtp relay service is not an option - if you have virtual domains ... [my assumption] Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 1:56 PM, "David Bray" mailto:da...@brayworth.com) mailto:da...@brayworth.com)?to=%22David%20Bray%22%20mailto:da...@brayworth.com)>>> wrote: Hi, Is this page valid * http://wiki.qmailtoaster.com/index.php/Smtproutes (http://wiki.qmailtoaster.com/index.php/Smtproutes) in particular the username/password settings It doesn't seem to be included in http://qmailtoaster.org (http://qmailtoaster.org) I'm thinking of relaying through mailgun.com Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com (mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com) For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com (mailto:qmailtoaster-list-h...@qmailtoaster.com)
Re: [qmailtoaster] Smtproutes
Hi - yeah, I don't know but they rewite the header to say it's from the authenticated sender, to quote another from https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365 (https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365) As @brayworth (https://www.linode.com/community/user/brayworth) has indicated, mailgun changes the headers, so if sending from a second domain you get the fugly "on behalf of" in mail clients. Cheers David Bray e. da...@brayworth.com January 5, 2022 12:06 AM, "Eric Broch" mailto:ebr...@whitehorsetc.com?to=%22Eric%20Broch%22%20)> wrote: Why does mailgun care that you have a multi-domain server (if that's what you're saying) just as long as you have credentials? You can set smtproutes up to relay mail from all domains on your server to mailgun (w/credentials). On 1/3/2022 10:07 PM, David Bray wrote: true, but relaying with a username/password so just trying to solve the linode problem by using a upstream smtp service (mailgun) it works on the first domain, but not the subsequent domains, because a separate set of creds can't be specified for sending from the 2nd domain Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 2:58 PM, "Eric Broch" mailto:ebr...@whitehorsetc.com?to=%22Eric%20Broch%22%20)> wrote: All you're doing is relaying through another host. On 1/3/2022 9:41 PM, David Bray wrote:and to answer the question * yes, it is valid - but the format is [optiional target domain]:relay server:port|username|password but, that only allows one username for many virtual domains ... * so using mailgun or any smtp relay service is not an option - if you have virtual domains ... [my assumption] Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 1:56 PM, "David Bray" mailto:da...@brayworth.com?to=%22David%20Bray%22%20)> wrote: Hi, Is this page valid * http://wiki.qmailtoaster.com/index.php/Smtproutes (http://wiki.qmailtoaster.com/index.php/Smtproutes) in particular the username/password settings It doesn't seem to be included in http://qmailtoaster.org/ (http://qmailtoaster.org/) I'm thinking of relaying through mailgun.com Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com)
Re: [qmailtoaster] Smtproutes
true, but relaying with a username/password so just trying to solve the linode problem by using a upstream smtp service (mailgun) it works on the first domain, but not the subsequent domains, because a separate set of creds can't be specified for sending from the 2nd domain Cheers David Bray e. da...@brayworth.com January 4, 2022 2:58 PM, "Eric Broch" mailto:ebr...@whitehorsetc.com?to=%22Eric%20Broch%22%20)> wrote: All you're doing is relaying through another host. On 1/3/2022 9:41 PM, David Bray wrote: and to answer the question * yes, it is valid - but the format is [optiional target domain]:relay server:port|username|password but, that only allows one username for many virtual domains ... * so using mailgun or any smtp relay service is not an option - if you have virtual domains ... [my assumption] Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) January 4, 2022 1:56 PM, "David Bray" mailto:da...@brayworth.com?to=%22David%20Bray%22%20)> wrote: Hi, Is this page valid * http://wiki.qmailtoaster.com/index.php/Smtproutes (http://wiki.qmailtoaster.com/index.php/Smtproutes) in particular the username/password settings It doesn't seem to be included in http://qmailtoaster.org/ (http://qmailtoaster.org/) I'm thinking of relaying through mailgun.com Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com)
Re: [qmailtoaster] Smtproutes
and to answer the question * yes, it is valid - but the format is [optiional target domain]:relay server:port|username|password but, that only allows one username for many virtual domains ... * so using mailgun or any smtp relay service is not an option - if you have virtual domains ... [my assumption] Cheers David Bray e. da...@brayworth.com January 4, 2022 1:56 PM, "David Bray" mailto:da...@brayworth.com?to=%22David%20Bray%22%20)> wrote: Hi, Is this page valid * http://wiki.qmailtoaster.com/index.php/Smtproutes (http://wiki.qmailtoaster.com/index.php/Smtproutes) in particular the username/password settings It doesn't seem to be included in http://qmailtoaster.org/ (http://qmailtoaster.org/) I'm thinking of relaying through mailgun.com Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com)
[qmailtoaster] Smtproutes
Hi, Is this page valid * http://wiki.qmailtoaster.com/index.php/Smtproutes (http://wiki.qmailtoaster.com/index.php/Smtproutes) in particular the username/password settings It doesn't seem to be included in http://qmailtoaster.org/ (http://qmailtoaster.org/) I'm thinking of relaying through mailgun.com Cheers David Bray e. da...@brayworth.com
Re: [qmailtoaster] 550 5.7.511 Access denied, banned sender - Office 365
Hey thanks yeah - specifically not Hotmail/Outlook/Live, my bad - these are Microsoft 365 Business accounts, so typically a company who has a Microsoft Online Exchange service Cheers David Bray e. da...@brayworth.com January 4, 2022 12:48 PM, "Angus McIntyre" wrote: > My Linode-hosted qmailtoaster install was blocked by MSN > (Hotmail/Outlook/Live) recently. > > However, it seems that they had singled out just my IP. I don't know > why; logs showed that users on my servers had sent a total of around 600 > messages to about 25 distinct Hotmail etc. users in the previous year, > all personal messages from individual users. Not exactly an unstoppable > spam flood. > > I jumped through the de-listing hoops, and they restored access after > about 2 days. > > Linode as a whole doesn't seem to be blocked -- my IP is still > acceptable to MSN -- but you might be in a netblock that MSN have > decided to block, presumably because some bad actors have set up shop there. > > You could reach out to Linode for help. It's possible that they could > either: > > a. Ask MSN to lift the block, or > b. Allocate you a different IP or help you move to another instance. > > If they can't or won't, you could consider recreating your installation > in a different Linode region and hope that that netblock isn't blocked > as well. The risk there is that you go to all the effort of moving and > then find that your new home is blacklisted as well. > > I guess if that doesn't work, there's always Digital Ocean or Vultr. > > The power of large companies like MSN to cause problems for the little > guys by introducing arbitrary bans is very frustrating. I understand why > they have to do it, and MSN certainly seem to be more responsive and > easier to appeal to than others ... but never knowing when you'll find > yourself blocked for mysterious reasons from one day to the next is > annoying. > > Angus > > David Bray wrote on 1/3/22 6:18 PM: > >> I've followed their (Microsoft's) instructions, forwarded mesaage to >> them and got a response >> >> That pointed me to https://sender.office.com to delist, which I did - >> but it said my ip was not listed ... >> >> It seems like a bigger block on Linodes IPs - so am in the process of >> chasing that >> >> but ... in the absense of a resolve there, its a major - change >> providors - holy smoke - that's a big response >> >> So I just thought I bounce here to see if others are in same (, Linode - >> or is it a bigger,) boat ... >> >> Cheers >> >> David Bray >> e. da...@brayworth.com >> >> January 4, 2022 9:01 AM, "Eric Broch" > > >> wrote: >> >> Did you do what the failure message said, i.e., forward the massage >> or go to web. >> >> On 1/3/2022 3:34 PM, David Bray wrote: >>> Hi all, does anyone see this issue ? >>> >>> Obviously not a toaster issue, but thought I'd bounce here ... >>> >>> I'm using Linode as my providor and having issues sending emails >>> to office365 accounts - live/hotmail are not affected >>> >>> I see this being reported at - and it describes my issue exactly: >>> https://docs.microsoft.com/en-us/answers/questions/674558/550-57511-access-denied-banned-sender.html >>> >>> The timing is precise, I became aware of the issue on 22 December. >>> >>> I've also initiated a conversation here: >>> https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365 >>> >>> My log message is >>> >>> delivery 1: failure: >>> 104.47.71.138_does_not_like_recipient./Remote_host_said:_550_5.7.511_Access_denied,_banned_sender[li >>> ode.ip]._To_request_removal_from_this_list_please_forward_this_message_to_delist@messaging.microsoft >>> com._For_more_information_please_go_to__http://go.microsoft.com/fwlink/?LinkId=526653._AS >>> >> osoft.com._For_more_information_please_go_to__http://go.microsoft.com/fwlink/?LinkId=526653._AS>(141 >>> )_[SY4AUS01FT006.eop-AUS01.prod.protection.outlook.com]/Giving_up_on_104.47.71.138./ >>> >>> Cheers >>> >>> David Bray >>> e. da...@brayworth.com > > - > 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
Re: [qmailtoaster] 550 5.7.511 Access denied, banned sender - Office 365
I've followed their (Microsoft's) instructions, forwarded mesaage to them and got a response That pointed me to https://sender.office.com/ (https://sender.office.com/) to delist, which I did - but it said my ip was not listed ... It seems like a bigger block on Linodes IPs - so am in the process of chasing that but ... in the absense of a resolve there, its a major - change providors - holy smoke - that's a big response So I just thought I bounce here to see if others are in same (, Linode - or is it a bigger,) boat ... Cheers David Bray e. da...@brayworth.com January 4, 2022 9:01 AM, "Eric Broch" mailto:ebr...@whitehorsetc.com?to=%22Eric%20Broch%22%20)> wrote: Did you do what the failure message said, i.e., forward the massage or go to web. On 1/3/2022 3:34 PM, David Bray wrote: Hi all, does anyone see this issue ? Obviously not a toaster issue, but thought I'd bounce here ... I'm using Linode as my providor and having issues sending emails to office365 accounts - live/hotmail are not affected I see this being reported at - and it describes my issue exactly: https://docs.microsoft.com/en-us/answers/questions/674558/550-57511-access-denied-banned-sender.html (https://docs.microsoft.com/en-us/answers/questions/674558/550-57511-access-denied-banned-sender.html) The timing is precise, I became aware of the issue on 22 December. I've also initiated a conversation here: https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365 (https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365) My log message is delivery 1: failure: 104.47.71.138_does_not_like_recipient./Remote_host_said:_550_5.7.511_Access_denied,_banned_sender[linode.ip]._to_request_removal_from_this_list_please_forward_this_message_to_del...@messaging.microsoft.com._For_more_information_please_go_to__http://go.microsoft.com/fwlink/?LinkId=526653._AS (mailto:linode.ip%5d._to_request_removal_from_this_list_please_forward_this_message_to_del...@messaging.microsoft.com._For_more_information_please_go_to__http://go.microsoft.com/fwlink/?LinkId=526653._AS)(1410)_[SY4AUS01FT006.eop-AUS01.prod.protection.outlook.com]/Giving_up_on_104.47.71.138./ Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com)
[qmailtoaster] 550 5.7.511 Access denied, banned sender - Office 365
Hi all, does anyone see this issue ? Obviously not a toaster issue, but thought I'd bounce here ... I'm using Linode as my providor and having issues sending emails to office365 accounts - live/hotmail are not affected I see this being reported at - and it describes my issue exactly: https://docs.microsoft.com/en-us/answers/questions/674558/550-57511-access-denied-banned-sender.html (https://docs.microsoft.com/en-us/answers/questions/674558/550-57511-access-denied-banned-sender.html) The timing is precise, I became aware of the issue on 22 December. I've also initiated a conversation here: https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365 (https://www.linode.com/community/questions/22287/550-57511-access-denied-banned-sender-office-365) My log message is delivery 1: failure: 104.47.71.138_does_not_like_recipient./Remote_host_said:_550_5.7.511_Access_denied,_banned_sender[linode.ip]._to_request_removal_from_this_list_please_forward_this_message_to_del...@messaging.microsoft.com._For_more_information_please_go_to__http://go.microsoft.com/fwlink/?LinkId=526653._AS(1410)_[SY4AUS01FT006.eop-AUS01.prod.protection.outlook.com]/Giving_up_on_104.47.71.138./ Cheers David Bray e. da...@brayworth.com
[qmailtoaster] Logwatch
Hi I get a logwatch report sent to me on my qmailtoaster It has a log of unmatched entries Has anybody got some pointers on filtering there out **Unmatched Entries** ~/var/qmail/simscan/1604880003.508496.28659/msg.1604880003.508496.28659: OK ~/var/qmail/simscan/1604880003.508496.28659/addr.1604880003.508496.28659: OK ~/var/qmail/simscan/1604880003.508496.28659/textfile0: OK ~/var/qmail/simscan/1604880003.508496.28659/textfile1: OK Thanks in advance Cheers David Bray e. da...@brayworth.com
Re: [qmailtoaster] 451_relay_not_permitted
Thanks for reply Tried it a couple of ways - results were consistent * It was noticed - client was CC'ing to this server * Tried CC'ing to GMail, same result * with CC, defered, without CC, went straight through All good, I agree - a recipient server issue Thanks for letting me bounce it off you Cheers David Bray e. da...@brayworth.com September 5, 2020 12:32 PM, "Eric Broch" mailto:ebr...@whitehorsetc.com?to=%22Eric%20Broch%22%20)> wrote: I would think that this is a recipient server issue. Is the CC'd address going to the same server? On 9/4/2020 7:31 PM, David Bray wrote: Hi With this message, I'm right to think that: * this is nothing to do with the sending side, * It has to be the serving side that is issuing this message, * there is no possible way that adding a CC address (or any other address, even an additional to address) could affect sending to the primary recipient Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com) September 3, 2020 2:00 PM, "David Bray" mailto:da...@brayworth.com?to=%22David%20Bray%22%20)> wrote: Hi I have an issue where * A client sends an email to a remote server * and cc's a copy to someone else under these circumstance I get: delivery 3555: deferral: _does_not_like_recipient./Remote_host_said:_451_relay_not_permitted!/Giving_up_on_./ it does eventually go through but the delay is several hours * If I test without the CC it goes through straight away * The CC'ed mail is delivered staright away * it only affects this server Their server has a signature if this helps: * signature spamexpert-2.servers.netregistry.net ESMTP Exim 20200825.1020 Thu, 03 Sep 2020 06:57:02 +0300 Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com)
Re: [qmailtoaster] 451_relay_not_permitted
Hi With this message, I'm right to think that: * this is nothing to do with the sending side, * It has to be the serving side that is issuing this message, * there is no possible way that adding a CC address (or any other address, even an additional to address) could affect sending to the primary recipient Cheers David Bray e. da...@brayworth.com September 3, 2020 2:00 PM, "David Bray" mailto:da...@brayworth.com?to=%22David%20Bray%22%20)> wrote: Hi I have an issue where * A client sends an email to a remote server * and cc's a copy to someone else under these circumstance I get: delivery 3555: deferral: _does_not_like_recipient./Remote_host_said:_451_relay_not_permitted!/Giving_up_on_./ it does eventually go through but the delay is several hours * If I test without the CC it goes through straight away * The CC'ed mail is delivered staright away * it only affects this server Their server has a signature if this helps: * signature spamexpert-2.servers.netregistry.net ESMTP Exim 20200825.1020 Thu, 03 Sep 2020 06:57:02 +0300 Cheers David Bray e. da...@brayworth.com (mailto:da...@brayworth.com)
[qmailtoaster] 451_relay_not_permitted
Hi I have an issue where * A client sends an email to a remote server * and cc's a copy to someone else under these circumstance I get: delivery 3555: deferral: _does_not_like_recipient./Remote_host_said:_451_relay_not_permitted!/Giving_up_on_./ it does eventually go through but the delay is several hours * If I test without the CC it goes through straight away * The CC'ed mail is delivered staright away * it only affects this server Their server has a signature if this helps: * signature spamexpert-2.servers.netregistry.net ESMTP Exim 20200825.1020 Thu, 03 Sep 2020 06:57:02 +0300 Cheers David Bray e. da...@brayworth.com
Re: [qmailtoaster] dspam -- yay or nay?
Hey cool thanks for the dir listing is the permissions critical here, noting that https://raw.githubusercontent.com/qmtoaster/dspam/master/dspamdb.sh leaves the ownership as root.root and perms 644 David Bray 0418 745334 2 ∞ & < On Mon, 31 Aug 2020 at 23:29, Eric Broch wrote: > Here's my domain level directory. There are no .qmail-user files only > .qmail-default : > > # ls -la /home/vpopmail/domains/mydomain.tld/ > total 24 > drwx-- 11 vpopmail vchkpw 4096 Oct 31 2019 . > drwx-- 8 vpopmail vchkpw 4096 Apr 6 2019 .. > drwx-- 3 vpopmail vchkpw 143 Dec 28 2016 user1 > drwx-- 3 vpopmail vchkpw 143 Dec 28 2016 user2 > drwx-- 4 vpopmail vchkpw 4096 Aug 16 13:39 user2 > drwx-- 3 vpopmail vchkpw 143 Dec 28 2016 user4 > drwx-- 3 vpopmail vchkpw 143 Dec 28 2016 user5 > drwx-- 3 vpopmail vchkpw 4096 Apr 8 2019 postmaster > -rw--- 1 vpopmail vchkpw 56 Sep 14 2017 .qmail-default > > Eric > > > On 8/31/2020 7:23 AM, Eric Broch wrote: > > In the PER USER configuration the > '/home/vpopmail/domains/mydomain.tld/.qmail-default' file doesn't change > and remains: > > | /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox > > > > On 8/31/2020 7:20 AM, Eric Broch wrote: > > So, here's what the directory directory looks like: > > # ls -la /home/vpopmail/domains/mydomain.tld/user > total 52 > drwx-- 4 vpopmail vchkpw 4096 Aug 16 13:39 . > drwx-- 11 vpopmail vchkpw 4096 Oct 31 2019 .. > drwx-- 357 vpopmail vchkpw 12288 Aug 31 07:10 Maildir > -rw--- 1 vpopmail vchkpw21 Dec 28 2016 .mailfilter.dspam > -rw--- 1 vpopmail vchkpw42 Aug 16 13:38 .qmail > > > .qmail file (one line no quotes): "| preline /usr/bin/maildrop > ./.mailfilter.dspam" > > > .mailfilter.dspam (here) > <https://github.com/qmtoaster/dspam/blob/master/.mailfilter.dspam>. > > > Eric > > > > On 8/31/2020 7:09 AM, Eric Broch wrote: > > When I do per user the file .qmail file resides in that person's home > email directory '/home/vpopmail/domains/mydomain.tld/user' (in the same > directory as Maildir). > > This .qmail file contains the following: > > | preline /usr/bin/maildrop ./.mailfilter.dspam > > .mailfilter.dspam here > <https://github.com/qmtoaster/dspam/blob/master/.mailfilter.dspam>. > > > It does NOT duplicate email. > > > On 8/30/2020 10:33 PM, Remo Mattei wrote: > > I have a little diff variant from Eric, > If I do the top level like Eric I do have the same config, if I do per > user I have the following in the .qmail-user > > |/usr/bin/dspam --deliver=innocent --user $EXT@$USER --debug --mode=teft > --feature=noise,whitelist --stdout -p -m | /home/vpopmail/bin/vdelivermail > '' /home/vpopmail/domains/domain.ht/user > > Keep in mind if you do use RC, this becomes tricky since the .qmail-user > will become .qmail inside of the user home dir and this will make > duplicates (emails). > > Just my 2 cents. Overall, it’s pretty similar to what Eric has. > > Remo > > On Aug 30, 2020, at 6:40 PM, David Bray wrote: > > Thanks > My understanding of the beast just increased > > Cheers > > David Bray > 0418 745334 > 2 ∞ & < > > > On Mon, 31 Aug 2020 at 11:29, Eric Broch wrote: > >> This is the contents of the .qmail-default (domain level) file that's >> existed since the beginning and never changed (directory: >> /home/vpopmail/domains/mydomain) : >> >> | /usr/bin/dspam --user "$EXT@$HOST" --deliver=stdout | >> /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox >> >> The .qmail file if one decides to run dspam by user (not domain) is as >> follows (/home/vpopmail/domains/mydomain/myuser) : >> >> | preline /usr/bin/maildrop ./.mailfilter.dspam >> >> .mailfilter.dspam here >> <https://github.com/qmtoaster/dspam/blob/master/.mailfilter.dspam>. >> >> The lines provided in the previous email do not call dspam at all (below): >> >> >> >> it creates the .qmail as a result >> >> |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: >> maildrop-toaster' /etc/mail/mailfilter >> >> >> if you then edit the account via the admin panel that file becomes: >> >> |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: >> maildrop-toaster' /etc/mail/mailfilter >> /home/vpopmail/domains/brayworth.com/[user]/Maildir/ >> <http://brayworth.com/%5Buser%5D/Maildir/> >> >> >> >> Eric >> >> On 8/30/2020 7:06 PM, David Bray wrote: >> >> Ok - working backwards from m
Re: [qmailtoaster] dspam -- yay or nay?
Thanks My understanding of the beast just increased Cheers David Bray 0418 745334 2 ∞ & < On Mon, 31 Aug 2020 at 11:29, Eric Broch wrote: > This is the contents of the .qmail-default (domain level) file that's > existed since the beginning and never changed (directory: > /home/vpopmail/domains/mydomain) : > > | /usr/bin/dspam --user "$EXT@$HOST" --deliver=stdout | > /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox > > The .qmail file if one decides to run dspam by user (not domain) is as > follows (/home/vpopmail/domains/mydomain/myuser) : > > | preline /usr/bin/maildrop ./.mailfilter.dspam > > .mailfilter.dspam here > <https://github.com/qmtoaster/dspam/blob/master/.mailfilter.dspam>. > > The lines provided in the previous email do not call dspam at all (below): > > > > it creates the .qmail as a result > > |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: > maildrop-toaster' /etc/mail/mailfilter > > > if you then edit the account via the admin panel that file becomes: > > |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: > maildrop-toaster' /etc/mail/mailfilter > /home/vpopmail/domains/brayworth.com/[user]/Maildir/ > <http://brayworth.com/%5Buser%5D/Maildir/> > > > > Eric > > On 8/30/2020 7:06 PM, David Bray wrote: > > Ok - working backwards from memory here > and when I read the install script I can see that the .qmail file is not > created > > so (and this is getting off topic now) > >- there should only be a .qmail-default and not a .qmail >- and >it's likely that these came from an older install > - so they should be removed .. > > > David Bray > 0418 745334 > 2 ∞ & < > > > On Mon, 31 Aug 2020 at 09:53, Eric Broch wrote: > >> Hmmm... >> >> I never had double delivery and mine's been installed for 5 years or more. >> >> The install script installs only one dot qmail file (.qmail-default), and >> only after a query to implement at domain level. >> >> You have the option to run dspam at domain or user level. >> >> Please show me where in the install procedure a .qmail file is created >> with the following line: >> >> |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: >> maildrop-toaster' /etc/mail/mailfilter >> >> ? >> >> The install script is for CentOS 5/6/7. I've yet to upgrade it for 8. >> >> I would recommend Dspam; however, it needs some attention. >> >> Eric >> >> >> On 8/30/2020 4:31 PM, David Bray wrote: >> >> I wondered this exact question and was going to ask this question >> I've wondered how it actually works >> I've disabled it >> >> if it works as documented at: >> >>- https://raw.githubusercontent.com/qmtoaster/dspam/ >> >> it creates the .qmail as a result >> >> |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: >> maildrop-toaster' /etc/mail/mailfilter >> >> >> if you then edit the account via the admin panel that file becomes: >> >> |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: >> maildrop-toaster' /etc/mail/mailfilter >> >> /home/vpopmail/domains/brayworth.com/[user]/Maildir/ >> <http://brayworth.com/%5Buser%5D/Maildir/> >> >> >> which results in a double up of delivery ... >> if you remove the file, the problem goes away >> >> so at best it needs to be carefully monitored, but it is still effective >> >> but the newer scripted install does a pretty good job with spamassassin >> anyway ... so I've disabled it.. >> >> >> David Bray >> 0418 745334 >> 2 ∞ & < >> >> >> On Mon, 31 Aug 2020 at 07:10, wrote: >> >>> I have used dspam from the early days so you could put this as an option >>> on your playbook. >>> >>> Just my 2cents >>> > Il giorno 30 ago 2020, alle ore 13:43, Angus McIntyre >>> ha scritto: >>> > >>> > I'm (still!) working on my Ansible role for installing qmailtoaster, >>> but I've switched to CentOS 8, based on Eric's new script, and it seems >>> much more straightforward and robust. >>> > >>> > One question I have is whether I should try to support dspam or not. >>> It looks as if the project was abandoned in 2014, amid reports that dspam >>> never performed as well as the developer claimed. >>> > >>> > Anyone have any thoughts or feelings (or, better, solid data) on >>> whether it's worth including dspam in a qmailtoaster install? >>> > >>> > 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 >> >>
Re: [qmailtoaster] dspam -- yay or nay?
Ok - working backwards from memory here and when I read the install script I can see that the .qmail file is not created so (and this is getting off topic now) - there should only be a .qmail-default and not a .qmail - and it's likely that these came from an older install - so they should be removed .. David Bray 0418 745334 2 ∞ & < On Mon, 31 Aug 2020 at 09:53, Eric Broch wrote: > Hmmm... > > I never had double delivery and mine's been installed for 5 years or more. > > The install script installs only one dot qmail file (.qmail-default), and > only after a query to implement at domain level. > > You have the option to run dspam at domain or user level. > > Please show me where in the install procedure a .qmail file is created > with the following line: > > |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: > maildrop-toaster' /etc/mail/mailfilter > > ? > > The install script is for CentOS 5/6/7. I've yet to upgrade it for 8. > > I would recommend Dspam; however, it needs some attention. > > Eric > > > On 8/30/2020 4:31 PM, David Bray wrote: > > I wondered this exact question and was going to ask this question > I've wondered how it actually works > I've disabled it > > if it works as documented at: > >- https://raw.githubusercontent.com/qmtoaster/dspam/ > > it creates the .qmail as a result > > |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: > maildrop-toaster' /etc/mail/mailfilter > > > if you then edit the account via the admin panel that file becomes: > > |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: > maildrop-toaster' /etc/mail/mailfilter > > /home/vpopmail/domains/brayworth.com/[user]/Maildir/ > <http://brayworth.com/%5Buser%5D/Maildir/> > > > which results in a double up of delivery ... > if you remove the file, the problem goes away > > so at best it needs to be carefully monitored, but it is still effective > > but the newer scripted install does a pretty good job with spamassassin > anyway ... so I've disabled it.. > > > David Bray > 0418 745334 > 2 ∞ & < > > > On Mon, 31 Aug 2020 at 07:10, wrote: > >> I have used dspam from the early days so you could put this as an option >> on your playbook. >> >> Just my 2cents >> > Il giorno 30 ago 2020, alle ore 13:43, Angus McIntyre >> ha scritto: >> > >> > I'm (still!) working on my Ansible role for installing qmailtoaster, >> but I've switched to CentOS 8, based on Eric's new script, and it seems >> much more straightforward and robust. >> > >> > One question I have is whether I should try to support dspam or not. It >> looks as if the project was abandoned in 2014, amid reports that dspam >> never performed as well as the developer claimed. >> > >> > Anyone have any thoughts or feelings (or, better, solid data) on >> whether it's worth including dspam in a qmailtoaster install? >> > >> > 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 > >
Re: [qmailtoaster] dspam -- yay or nay?
I wondered this exact question and was going to ask this question I've wondered how it actually works I've disabled it if it works as documented at: - https://raw.githubusercontent.com/qmtoaster/dspam/ it creates the .qmail as a result |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: maildrop-toaster' /etc/mail/mailfilter if you then edit the account via the admin panel that file becomes: |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: maildrop-toaster' /etc/mail/mailfilter /home/vpopmail/domains/brayworth.com/[user]/Maildir/ which results in a double up of delivery ... if you remove the file, the problem goes away so at best it needs to be carefully monitored, but it is still effective but the newer scripted install does a pretty good job with spamassassin anyway ... so I've disabled it.. David Bray 0418 745334 2 ∞ & < On Mon, 31 Aug 2020 at 07:10, wrote: > I have used dspam from the early days so you could put this as an option > on your playbook. > > Just my 2cents > > Il giorno 30 ago 2020, alle ore 13:43, Angus McIntyre > ha scritto: > > > > I'm (still!) working on my Ansible role for installing qmailtoaster, > but I've switched to CentOS 8, based on Eric's new script, and it seems > much more straightforward and robust. > > > > One question I have is whether I should try to support dspam or not. It > looks as if the project was abandoned in 2014, amid reports that dspam > never performed as well as the developer claimed. > > > > Anyone have any thoughts or feelings (or, better, solid data) on whether > it's worth including dspam in a qmailtoaster install? > > > > 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
Re: [qmailtoaster] Re: Email delivery repeats
I've noticed this too Could there be a bug in qmailadmin / mailfilter here By default there is no .qmail in a users folder and editing the account does not create one .. but qmailadmin does maintain it. if you install dspam https://raw.githubusercontent.com/qmtoaster/dspam/ it creates the .qmail as a result |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: maildrop-toaster' /etc/mail/mailfilter if you then edit the account |/var/qmail/bin/preline /usr/bin/maildrop -A 'Content-Filter: maildrop-toaster' /etc/mail/mailfilter /home/vpopmail/domains/brayworth.com/[user]/Maildir/ which results in a double up of delivery ... David Bray 0418 745334 2 ∞ & < On Wed, 5 Aug 2020 at 08:53, Chris wrote: > Working on extracting some clean logs. One thing I'm noticing is that the > two repeats I've had recently were both from amazonses.com and were TLS > encrypted. > > -Chris > > On Thu, Jul 30, 2020 at 6:44 AM Eric Broch > wrote: > >> It's be nice to have the smtp log and the email header. >> On 7/29/2020 12:40 PM, Chris wrote: >> >> I've had some recent repeats, but haven't had a chance to dig them out of >> the logs yet. I'll try to find time to do that tonight. >> >> On Thu, Jul 30, 2020 at 2:14 AM Eric Broch >> wrote: >> >>> Hi Chris, >>> >>> Did you save any of the SMTP logs for those messages that were >>> re-delivered and email headers? >>> >>> Eric >>> On 7/17/2020 7:09 PM, Chris wrote: >>> >>> As soon as I have something useful from recordio I'll post it. >>> >>> On Thu, Jul 16, 2020 at 6:54 AM Eric Broch >>> wrote: >>> >>>> Can you tell me what the log shows for one of these messages? >>>> On 7/15/2020 12:42 PM, Eric Broch wrote: >>>> >>>> And, what version of qmail? >>>> On 7/15/2020 12:41 PM, Eric Broch wrote: >>>> >>>> Did you turn on recordio? >>>> On 7/15/2020 11:33 AM, Boheme wrote: >>>> >>>> Nope. It’s insanely random. >>>> >>>> -Sent from my Pip-Boy 3000 >>>> >>>> On 16/07/2020, at 5:27 AM, Eric Broch >>>> wrote: >>>> >>>> >>>> >>>> Can you repeat this error at will? >>>> On 7/10/2020 2:15 AM, Chris wrote: >>>> >>>> I've disabled spamdyke, the source of the 421 timeout error; but I'm >>>> still getting re-delivery of emails. Not as frequently, but I've received >>>> the same two emails a dozen times today. >>>> >>>> Has anyone else experienced this before? >>>> >>>> -Chris >>>> >>>> On Tue, Jun 30, 2020 at 7:30 AM Chris wrote: >>>> >>>>> A few nights ago I shut down the VM that my qmailtoaster runs on, >>>>> bumped the memory up to 4g, and restarted it. First reboot in a long >>>>> while, so I was nervous. Everything seemed fine. >>>>> >>>>> The next day I noticed that there were a couple of emails I had >>>>> deleted that had re-appeared. I'd delete them again, and they'd come back >>>>> again. My mail client shows date sent and date received, and they were >>>>> definitely all the same sender time. Checking the logs, I see the same >>>>> set >>>>> of email being re-accepted in /var/log/qmail/smtp/current over and over. >>>>> >>>>> Finally I have a clue. Gmail sent me a delivery warning about one of >>>>> the emails, as it was a test message from myself, and it says my server is >>>>> responding with error: >>>>> >>>>> 421 Timeout. Talk faster next time. >>>>> >>>>> So it seems the email is getting accepted, but then the sending server >>>>> is given an error 421, so it queues it up for re-delivery. >>>>> >>>>> Any suggestions on what I should be looking at to figure this out? >>>>> >>>>> -Chris >>>>> >>>>
Re: [qmailtoaster] QMail Admin
Yes - this is spot on, the branding totally caught me by surprise. and the recommended install path pushed this out. David Bray 0418 745334 2 ∞ & < On Fri, 1 May 2020 at 07:26, Bill Silverstein wrote: > I think the point is that he was surprised by the branding. > > I am thinking, even in the development branch the branding should not be > included. > > > > > On Thu, April 30, 2020 2:03 pm, Eric Broch wrote: > > Your version is in the development tree for testing and input. Is that > > okay or shall I pull it down? > > > > On 4/30/2020 12:21 PM, Tahnan Al Anas wrote: > >> Hi Eriq, you have already put qmail admin for all user? > >> > >> On Thu, 30 Apr 2020, 10:01 pm Eric Broch, >> <mailto:ebr...@whitehorsetc.com>> wrote: > >> > >> yes > >> > >> On 4/29/2020 8:04 PM, David Bray wrote: > >>> > >>> When I updated using the command > >>> > >>> * yum --enablerepo=qmt-devel update > >>> > >>> It updated qmailAdmin ... and it looks like this ! > >>> > >>> Is that intended ? > >>> > > -- > William Silverstein > Certified Law Student > Anderson & Jung > Supervising Attorney: T. Valfrid Anderson, Esq. > > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > >
[qmailtoaster] QMail Admin
When I updated using the command - yum --enablerepo=qmt-devel update It updated qmailAdmin ... and it looks like this ! Is that intended ? [image: image.png] David Bray 0418 745334 2 ∞ & <
Re: [qmailtoaster] outlook dot com
I think my issue was just that, it seems to have gone away since I updated to latest version On Thu, 30 Apr 2020 at 2:19 am, Eric Broch wrote: > Has anyone experienced timeouts on incoming connections from outlook.com? > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > -- # David
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Just an update on this all seems to have resolved itself now I'm not sure exactly what the differential was 1. I ran the update - *yum --enablerepo=qmt-devel update* - before : qmail-1.03-3.1.1.qt.el7.x86_64 - after : qmail-1.03-3.2.qt.el7.x86_64 I did some other things, but that seems to have been the thing that made the change, I must have missed this step in the original install I also find this fail2ban filter useful - it has significantly reduced the load on the server: [Definition] failregex = vchkpw-smtps?: vpopmail user not found .*: vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*: spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: origin_rdns:.*$ spamdyke.*?: DENIED_RDNS_MISSING .*origin_ip: origin_rdns:.*$ Thanks to those that replied David Bray 0418 745334 2 ∞ & < On Thu, 23 Apr 2020 at 11:17, David Bray wrote: > no - but vchkpw, also spamdyke does > > so this is blocking people that are providing bad passwords etc ... > but agree, still trying to work out who is doing something other than this > > David Bray > 0418 745334 > 2 ∞ & < > > > On Thu, 23 Apr 2020 at 11:15, Remo Mattei wrote: > >> qmail does not log to maillog. >> Remo >> >> Inviato da iPad >> >> Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray < >> da...@brayworth.com.au> ha scritto: >> >> >> I agree, have them in place already, they are winners >> >>- I actually disagree slightly, if I'm not mistaken - it would be >>better to have those two entries combined, wouldn't fail2ban parse the >>maillog twice in his example ? >> >> I use: >> failregex = vchkpw-smtps?: vpopmail user not found .*: >> vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*: >> spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: >> origin_rdns:.*$ >> >> But - I'm not getting log entries for these guys, maillog is all silent I >> watch /var/log/qmail/smtps/current float up and down, CPU goes up and down, >> but /var/log/maillog is all silent >> >> David Bray >> 0418 745334 >> 2 ∞ & < >> >> >> On Thu, 23 Apr 2020 at 00:06, Jaime Lerner >> wrote: >> >>> David, >>> >>> >>> >>> You might try the suggestions here: >>> https://www.taverner-rich.com/mitigating-brute-force-attacks/ >>> >>> >>> >>> I put them in place on my server and it definitely helped. >>> >>> >>> >>> Jaime >>> >>> >>> >>> *From: *Eric Broch >>> *Reply-To: * >>> *Date: *Wednesday, April 22, 2020 at 9:40 AM >>> *To: * >>> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ? >>> >>> >>> >>> Hi David, >>> >>> I think you're on to something with fail2ban (keying off maillog). I was >>> monitoring my smtps port (watching the certificate and encryption scroll >>> by) using /usr/bin/recordio and /var/log/maillog and found that the bad >>> guys are trying to login. Here are some failures from maillog: >>> >>> vchkpw-smtps: vpopmail user not found >>> testforu...@whitehorsetc.com:92.118.38.83 >>> >>> vchkpw-smtps: password fail (pass: 'somepassword') >>> someu...@whitehorsetc.com:185.50.149.2 >>> >>> Maybe a fail2ban rule?! >>> >>> Eric >>> >>> >>> >>> On 4/18/2020 4:12 AM, David Bray wrote: >>> >>> Hi thanks - yes can block that IP >>> >>> But it’s not just one, and the solution is not fine enough >>> >>> I want more of a fail2ban rule, bad use bad pass 3 strikes your out >>> >>> >>> >>> I need to know they are mucking round. >>> >>> >>> >>> I tried sending myself through the port with a bad password- sure it >>> blocks it, but there is no log of the event - it looks like a legit, >>> connection from Ann IP >>> >>> >>> >>> On Sat, 18 Apr 2020 at 7:30 pm, Chris wrote: >>> >>> Here's a great article with instructions on how to implement an IP >>> blacklist in iptables. Unless you've got a user in Panama, it looks like >>> you's want to block 141.98.80.30 >>> >>> >>> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/ >>> >>> >>> >>> On Sat, Apr 18, 2020 at 5:49 PM David Bray >>> wrote: >>> >>> sure - thanks for replying, this comes in w
Re: [qmailtoaster] letsencrypt certificate issue
I make up a composite certificate and include lets-encrypt-x3-cross-signed.pem.txt https://letsencrypt.org/certificates/ I'm not sure if I still need to, but I must have at some stage David Bray 0418 745334 2 ∞ & < On Wed, 29 Apr 2020 at 19:38, ChandranManikandan wrote: > Hi Friends, > > It was working well before after getting the renewal date only the issue > is happened. > Anyone having the same issue? > Appreciate your help. > > On Wed, Apr 29, 2020 at 4:52 PM ChandranManikandan > wrote: > >> Hi Remo, >> >> FYI >> ssl_cert = > ssl_key = > # the following will likely be the default at some point >> ssl_dh_parameters_length = 2048 >> >> >> On Wed, Apr 29, 2020 at 11:48 AM Remo Mattei wrote: >> >>> You need to check the /etc/dovecot/toaster.conf file that’s where the >>> cert for outlook and thunder lives. >>> >>> Remo >>> >>> On Apr 28, 2020, at 20:38, ChandranManikandan wrote: >>> >>> Hi Friends, >>> >>> certbot renew command showing below message >>> Saving debug log to /var/log/letsencrypt/letsencrypt.log >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - - - >>> Processing /etc/letsencrypt/renewal/xxx.com.conf >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - - - >>> Cert not yet due for renewal >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> - - - - >>> >>> The following certs are not due for renewal yet: >>> /etc/letsencrypt/live/xxx.com/fullchain.pem expires on 2020-06-27 >>> (skipped) >>> No renewals were attempted. >>> - - - - - - - - - - - - - - - >>> >>> But outlook, thunderbird showing the certificate issue and certificate >>> expire date is showing 28-Apr-2020 in thunderbird, >>> I have checked in website in the same certificate expiry date is showing >>> 27-06-2020. >>> >>> Do i anything done mistake. >>> How do i check and fix the above issue. >>> Could anyone help me. >>> Appreciate your help. >>> >>> Note: Centos 7 with qmailtoaster >>> -- >>> >>> >>> *Regards,Manikandan.C* >>> >>> >>> >> >> -- >> >> >> *Regards,Manikandan.C* >> > > > -- > > > *Regards,Manikandan.C* >
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
no - but vchkpw, also spamdyke does so this is blocking people that are providing bad passwords etc ... but agree, still trying to work out who is doing something other than this David Bray 0418 745334 2 ∞ & < On Thu, 23 Apr 2020 at 11:15, Remo Mattei wrote: > qmail does not log to maillog. > Remo > > Inviato da iPad > > Il giorno 22 apr 2020, alle ore 5:36 PM, David Bray < > da...@brayworth.com.au> ha scritto: > > > I agree, have them in place already, they are winners > >- I actually disagree slightly, if I'm not mistaken - it would be >better to have those two entries combined, wouldn't fail2ban parse the >maillog twice in his example ? > > I use: > failregex = vchkpw-smtps?: vpopmail user not found .*: > vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*: > spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: > origin_rdns:.*$ > > But - I'm not getting log entries for these guys, maillog is all silent I > watch /var/log/qmail/smtps/current float up and down, CPU goes up and down, > but /var/log/maillog is all silent > > David Bray > 0418 745334 > 2 ∞ & < > > > On Thu, 23 Apr 2020 at 00:06, Jaime Lerner > wrote: > >> David, >> >> >> >> You might try the suggestions here: >> https://www.taverner-rich.com/mitigating-brute-force-attacks/ >> >> >> >> I put them in place on my server and it definitely helped. >> >> >> >> Jaime >> >> >> >> *From: *Eric Broch >> *Reply-To: * >> *Date: *Wednesday, April 22, 2020 at 9:40 AM >> *To: * >> *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ? >> >> >> >> Hi David, >> >> I think you're on to something with fail2ban (keying off maillog). I was >> monitoring my smtps port (watching the certificate and encryption scroll >> by) using /usr/bin/recordio and /var/log/maillog and found that the bad >> guys are trying to login. Here are some failures from maillog: >> >> vchkpw-smtps: vpopmail user not found >> testforu...@whitehorsetc.com:92.118.38.83 >> >> vchkpw-smtps: password fail (pass: 'somepassword') >> someu...@whitehorsetc.com:185.50.149.2 >> >> Maybe a fail2ban rule?! >> >> Eric >> >> >> >> On 4/18/2020 4:12 AM, David Bray wrote: >> >> Hi thanks - yes can block that IP >> >> But it’s not just one, and the solution is not fine enough >> >> I want more of a fail2ban rule, bad use bad pass 3 strikes your out >> >> >> >> I need to know they are mucking round. >> >> >> >> I tried sending myself through the port with a bad password- sure it >> blocks it, but there is no log of the event - it looks like a legit, >> connection from Ann IP >> >> >> >> On Sat, 18 Apr 2020 at 7:30 pm, Chris wrote: >> >> Here's a great article with instructions on how to implement an IP >> blacklist in iptables. Unless you've got a user in Panama, it looks like >> you's want to block 141.98.80.30 >> >> >> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/ >> >> >> >> On Sat, Apr 18, 2020 at 5:49 PM David Bray >> wrote: >> >> sure - thanks for replying, this comes in waves taking the server to it's >> maximum at times >> >> >> >> as far as I can see this only logs are this: >> >> >> >> ==> /var/log/qmail/smtps/current <== >> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 >> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 >> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::25638 >> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 >> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 >> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::14862 >> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 >> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 >> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::9646 >> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 >> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 >> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::54058 >> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 &
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Could I ask you command line for recordio Thanks in advance David Bray 0418 745334 2 ∞ & < On Wed, 22 Apr 2020 at 23:40, Eric Broch wrote: > Hi David, > > I think you're on to something with fail2ban (keying off maillog). I was > monitoring my smtps port (watching the certificate and encryption scroll > by) using /usr/bin/recordio and /var/log/maillog and found that the bad > guys are trying to login. Here are some failures from maillog: > > vchkpw-smtps: vpopmail user not found > testforu...@whitehorsetc.com:92.118.38.83 > > vchkpw-smtps: password fail (pass: 'somepassword') > someu...@whitehorsetc.com:185.50.149.2 > > Maybe a fail2ban rule?! > > Eric > > > On 4/18/2020 4:12 AM, David Bray wrote: > > Hi thanks - yes can block that IP > But it’s not just one, and the solution is not fine enough > I want more of a fail2ban rule, bad use bad pass 3 strikes your out > > I need to know they are mucking round. > > I tried sending myself through the port with a bad password- sure it > blocks it, but there is no log of the event - it looks like a legit, > connection from Ann IP > > On Sat, 18 Apr 2020 at 7:30 pm, Chris wrote: > >> Here's a great article with instructions on how to implement an IP >> blacklist in iptables. Unless you've got a user in Panama, it looks like >> you's want to block 141.98.80.30 >> >> https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/ >> >> On Sat, Apr 18, 2020 at 5:49 PM David Bray >> wrote: >> >>> sure - thanks for replying, this comes in waves taking the server to >>> it's maximum at times >>> >>> as far as I can see this only logs are this: >>> >>> ==> /var/log/qmail/smtps/current <== >>> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 >>> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 >>> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 >>> dev.brayworth.com:172.105.181.18:465 >>> :141.98.80.30::25638 >>> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 >>> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 >>> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 >>> dev.brayworth.com:172.105.181.18:465 >>> :141.98.80.30::14862 >>> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 >>> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 >>> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 >>> dev.brayworth.com:172.105.181.18:465 >>> :141.98.80.30::9646 >>> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 >>> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 >>> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 >>> dev.brayworth.com:172.105.181.18:465 >>> :141.98.80.30::54058 >>> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 >>> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60 >>> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256 >>> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60 >>> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256 >>> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60 >>> >>> David Bray >>> 0418 745334 >>> 2 ∞ & < >>> >>> >>> On Sat, 18 Apr 2020 at 15:41, Eric Broch >>> wrote: >>> >>>> Can you send the log of one of the "bad" connections? >>>> >>>> On 4/17/2020 10:59 PM, David Bray wrote: >>>> >>>> I can see I'm getting hammered on my smtps port >>>> >>>> How can I mitigate this? >>>> >>>> I can see the IP's in /var/log/qmail/smtps/current >>>> >>>> *but where do I actually see that the smtp auth actually fails ?* >>>> >>>> or do I need to increase the logging somewhere ? >>>> >>>> if I tail -f /var/log/dovecot.log >>>> >>>> I can see the imap and pop failures >>>> >>>> thanks in advance >>>> >>>> David Bray >>>> 0418 745334 >>>> 2 ∞ & < >>>> >>>> -- > # David > >
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
I agree, have them in place already, they are winners - I actually disagree slightly, if I'm not mistaken - it would be better to have those two entries combined, wouldn't fail2ban parse the maillog twice in his example ? I use: failregex = vchkpw-smtps?: vpopmail user not found .*: vchkpw-smtps?: password fail ([^)]*) [^@]*@[^:]*: spamdyke.*?: DENIED_RDNS_RESOLVE .*origin_ip: origin_rdns:.*$ But - I'm not getting log entries for these guys, maillog is all silent I watch /var/log/qmail/smtps/current float up and down, CPU goes up and down, but /var/log/maillog is all silent David Bray 0418 745334 2 ∞ & < On Thu, 23 Apr 2020 at 00:06, Jaime Lerner wrote: > David, > > > > You might try the suggestions here: > https://www.taverner-rich.com/mitigating-brute-force-attacks/ > > > > I put them in place on my server and it definitely helped. > > > > Jaime > > > > *From: *Eric Broch > *Reply-To: * > *Date: *Wednesday, April 22, 2020 at 9:40 AM > *To: * > *Subject: *Re: [qmailtoaster] SMTPS Port - Who is Failing ? > > > > Hi David, > > I think you're on to something with fail2ban (keying off maillog). I was > monitoring my smtps port (watching the certificate and encryption scroll > by) using /usr/bin/recordio and /var/log/maillog and found that the bad > guys are trying to login. Here are some failures from maillog: > > vchkpw-smtps: vpopmail user not found > testforu...@whitehorsetc.com:92.118.38.83 > > vchkpw-smtps: password fail (pass: 'somepassword') > someu...@whitehorsetc.com:185.50.149.2 > > Maybe a fail2ban rule?! > > Eric > > > > On 4/18/2020 4:12 AM, David Bray wrote: > > Hi thanks - yes can block that IP > > But it’s not just one, and the solution is not fine enough > > I want more of a fail2ban rule, bad use bad pass 3 strikes your out > > > > I need to know they are mucking round. > > > > I tried sending myself through the port with a bad password- sure it > blocks it, but there is no log of the event - it looks like a legit, > connection from Ann IP > > > > On Sat, 18 Apr 2020 at 7:30 pm, Chris wrote: > > Here's a great article with instructions on how to implement an IP > blacklist in iptables. Unless you've got a user in Panama, it looks like > you's want to block 141.98.80.30 > > > https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/ > > > > On Sat, Apr 18, 2020 at 5:49 PM David Bray wrote: > > sure - thanks for replying, this comes in waves taking the server to it's > maximum at times > > > > as far as I can see this only logs are this: > > > > ==> /var/log/qmail/smtps/current <== > 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 > 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 > 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::25638 > 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 > 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 > 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::14862 > 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 > 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 > 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::9646 > 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 > 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 > 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::54058 > 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 > 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60 > 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256 > 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60 > 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256 > 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60 > > > David Bray > > 0418 745334 > 2 ∞ & < > > > > > > On Sat, 18 Apr 2020 at 15:41, Eric Broch wrote: > > Can you send the log of one of the "bad" connections? > > On 4/17/2020 10:59 PM, David Bray wrote: > > I can see I'm getting hammered on my smtps port > > > > How can I mitigate this? > > > > I can see the IP's in /var/log/qmail/smtps/current > > > > *but where do I actually see that the smtp auth actually fails ?* > > > > or do I need to increase the logging somewhere ? > > > > if I tail -f /var/log/dovecot.log > > > > I can see the imap and pop failures > > > > thanks in advance > > > David Bray > > 0418 745334 > 2 ∞ & < > > -- > > # David > >
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Hey Remo, just looking at Andy's suggestion though tcpdump - that only copies the data from the port ? So if if I were to use Andy's idea - it would be an interference in the port and the data would have to be proxied to the correct port (or lost) tcpdump - can I use that on an existing connection What I have here is a lot of connections during the day, but then I notice the CPU going up (between swimming, running, hiking and other leisure activities) So I just want to say - *What are you doing and look * - can tcpdump do that ? I see tcpdump host is an option ... I'll see what I can discover there, thanks Remo/Andy David Bray 0418 745334 2 ∞ & < On Wed, 22 Apr 2020 at 09:46, wrote: > The other is to leverage some of Andy’s suggestions and use tcpdump on > that port and see > > > Il giorno 21 apr 2020, alle ore 16:40, Andrew Swartz < > awswa...@acsalaska.net> ha scritto: > > > > David, > > > > I have no idea where (or even if) incoming TLS sessions are logged. > > > > I've used "openssl s_client" numerous times to see the details of a > connection, but only from the client perspective. > > > > Openssl does have the "s_server" complement of s_client, but I've never > used it: > > > > https://www.openssl.org/docs/man1.1.0/man1/s_server.html > > > > Maybe you could: > > 1. set a firewall rule to redirect the offending IP to a new port, then > > 2. run openssl s_server listening on the new port in a terminal window > and thus watch the output of the TLS negotiation (or redirect the output to > a file). > > > > I've never done this. But it seems the easiest way to debug a TLS > negotiation from the server perspective (i.e. see what a remote client is > doing without access to that client). Others on the list may have better > ideas or even some experience doing this. > > > > -Andy > > > > > > > >> On 4/20/2020 8:15 PM, David Bray wrote: > >> Hi Andy - you have grasped the problem accurately > >> As I understand it, the transaction does not leave a great deal of > scope - negotiate the encryption, send a password successfully or > unsuccessfully - (at that point it's logged) > >> So it has to be the negotiation phase ... > >> but: > >> * I've only just built this server > >> * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB > >> o I think this adequate I've seen no OOM events - and the size is > >>what I've used before > >> The only thing I'm really seeing here that could be an issue is - the > newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing > >> I see lots of broken servers, and have to /make allowances/, I do this > by: > >>touch /var/qmail/control/notlshosts/ > >> Noting - that is an outbound thing ... (see > https://www.qmailtoaster.org/notls.html) > >> So .. is it possible that a broken client is hitting the port, not > being able to make the necessary handshake and causing this CPU load .... > >> It's reported in the logs when the server makes an outbound transaction > like that ... > >>deferral: > >> > TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./ > >> What would it look like in my logs if they where to have the reverse > issue > >> David Bray > >> 0418 745334 > >> 2 ∞ & < > >> On Tue, 21 Apr 2020 at 02:54, Andrew Swartz <mailto:awswa...@acsalaska.net>> wrote: > >>Port 465 should be SMTP over SSL/TLS. Therefore the sequence of > >>events is: > >>1. Establish TCP connection > >>2. Negotiate SSL/TLS session > >>3. Begin SMTP session > >>Of these, the SSL/TLS negotiation is by far the most CPU-intensive. > >>Consider trying to see what is happening with the SSL/TLS > negotiation. > >>It may be failing in a way which is slamming the CPU but not showing > up > >>in the SMTP logs because it never completes and thus an SMTP session > is > >>never initiated. > >>I'm unsure the best way to debug the incoming SSL/TLS negotiation. > You > >>might set a firewall rule where incoming port 465 from that single > >>IP is > >>forwarded to stunnel (on another machine) which is set to output > >>verbose > >>debug info??? > >>It would be interesting to know the cause. This could be some clever > >>DOS attack where a single connection accomplishes the DOS by slamming > >>
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Thankfully CentOS 7 using 1.0.2k so not affected - thanks for the tip though David Bray 0418 745334 2 ∞ & < On Wed, 22 Apr 2020 at 09:40, Andrew Swartz wrote: > David, > > I just received this OpenSSL security advisory which may be describing > your problem. It describes a vulnerability which allows a DOS attack by > submitting an invalid certificate. > > https://www.openssl.org/news/secadv/20200421.txt > > > -Andy > > > On 4/20/2020 8:15 PM, David Bray wrote: > > Hi Andy - you have grasped the problem accurately > > > > As I understand it, the transaction does not leave a great deal of scope > > - negotiate the encryption, send a password successfully or > > unsuccessfully - (at that point it's logged) > > > > So it has to be the negotiation phase ... > > but: > > > > * I've only just built this server > > * stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB > > o I think this adequate I've seen no OOM events - and the size is > > what I've used before > > > > The only thing I'm really seeing here that could be an issue is - the > > newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing > > I see lots of broken servers, and have to /make allowances/, I do this > by: > > > > touch /var/qmail/control/notlshosts/ > > > > > > Noting - that is an outbound thing ... (see > > https://www.qmailtoaster.org/notls.html) > > > > So .. is it possible that a broken client is hitting the port, not > > being able to make the necessary handshake and causing this CPU load > > It's reported in the logs when the server makes an outbound transaction > > like that ... > > > > deferral: > > > > TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./ > > > > > > What would it look like in my logs if they where to have the reverse > issue > > > > > > > > > > > > David Bray > > 0418 745334 > > 2 ∞ & < > > > > > > On Tue, 21 Apr 2020 at 02:54, Andrew Swartz > <mailto:awswa...@acsalaska.net>> wrote: > > > > Port 465 should be SMTP over SSL/TLS. Therefore the sequence of > > events is: > > > > 1. Establish TCP connection > > 2. Negotiate SSL/TLS session > > 3. Begin SMTP session > > > > Of these, the SSL/TLS negotiation is by far the most CPU-intensive. > > > > Consider trying to see what is happening with the SSL/TLS > negotiation. > > It may be failing in a way which is slamming the CPU but not showing > up > > in the SMTP logs because it never completes and thus an SMTP session > is > > never initiated. > > > > I'm unsure the best way to debug the incoming SSL/TLS negotiation. > You > > might set a firewall rule where incoming port 465 from that single > > IP is > > forwarded to stunnel (on another machine) which is set to output > > verbose > > debug info??? > > > > It would be interesting to know the cause. This could be some clever > > DOS attack where a single connection accomplishes the DOS by slamming > > the CPU by submitting something invalid to openSSL. But it might > just > > be that some spammer is using a home-brewed script which is buggy > > and is > > unintentionally causing this problem. > > > > There seems no efficient way to block this without figuring out the > > cause and doing something to make that cause be logged into some log > > file. Once that is accomplished, fail2ban (or something similar) can > > easily add firewall rules to block individual IP's which exhibit this > > behavior. > > > > -Andy > > > > > > > > > > > > On 4/19/2020 10:12 PM, David Bray wrote: > > > Hey thanks Remo > > > smtps is an inbound port, they are contacting me - this IP is in > > Russia > > > somewhere - so do I want to engage (perhaps, probably not but ..) > > > > > > I could of course block that IP - but that doesn't help, I'd have > to > > > block endless IPs > > > > > > I'd like to know what's taking the CPU load, in theory they > > should be > > > connecting, supplying a password (perhaps) and sending data > > > but, there are sometimes bad passwords (2 for the 20th recorded > > in
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Hi Eric - was that for Andy or me I'm on - qmail-1.03-3.1.1.qt.el7.x86_64 - qmailadmin-1.2.16-2.qt.el7.x86_64 - qmailmrtg-4.2-3.qt.el7.x86_64 David Bray 0418 745334 2 ∞ & < On Tue, 21 Apr 2020 at 23:34, Eric Broch wrote: > Andy, > > May I ask what version of qmail you're on? > > Eric > On 4/20/2020 10:15 PM, David Bray wrote: > > Hi Andy - you have grasped the problem accurately > > As I understand it, the transaction does not leave a great deal of scope - > negotiate the encryption, send a password successfully or unsuccessfully - > (at that point it's logged) > > So it has to be the negotiation phase ... > but: > >- I've only just built this server >- stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB > - I think this adequate I've seen no OOM events - and the size is > what I've used before > > The only thing I'm really seeing here that could be an issue is - the > newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing > I see lots of broken servers, and have to *make allowances*, I do this by: > > touch /var/qmail/control/notlshosts/ > > > Noting - that is an outbound thing ... (see > https://www.qmailtoaster.org/notls.html) > > So .. is it possible that a broken client is hitting the port, not > being able to make the necessary handshake and causing this CPU load > It's reported in the logs when the server makes an outbound transaction > like that ... > > deferral: > TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./ > > > What would it look like in my logs if they where to have the reverse issue > > > > > > David Bray > 0418 745334 > 2 ∞ & < > > > On Tue, 21 Apr 2020 at 02:54, Andrew Swartz > wrote: > >> Port 465 should be SMTP over SSL/TLS. Therefore the sequence of events >> is: >> >> 1. Establish TCP connection >> 2. Negotiate SSL/TLS session >> 3. Begin SMTP session >> >> Of these, the SSL/TLS negotiation is by far the most CPU-intensive. >> >> Consider trying to see what is happening with the SSL/TLS negotiation. >> It may be failing in a way which is slamming the CPU but not showing up >> in the SMTP logs because it never completes and thus an SMTP session is >> never initiated. >> >> I'm unsure the best way to debug the incoming SSL/TLS negotiation. You >> might set a firewall rule where incoming port 465 from that single IP is >> forwarded to stunnel (on another machine) which is set to output verbose >> debug info??? >> >> It would be interesting to know the cause. This could be some clever >> DOS attack where a single connection accomplishes the DOS by slamming >> the CPU by submitting something invalid to openSSL. But it might just >> be that some spammer is using a home-brewed script which is buggy and is >> unintentionally causing this problem. >> >> There seems no efficient way to block this without figuring out the >> cause and doing something to make that cause be logged into some log >> file. Once that is accomplished, fail2ban (or something similar) can >> easily add firewall rules to block individual IP's which exhibit this >> behavior. >> >> -Andy >> >> >> >> >> >> On 4/19/2020 10:12 PM, David Bray wrote: >> > Hey thanks Remo >> > smtps is an inbound port, they are contacting me - this IP is in Russia >> > somewhere - so do I want to engage (perhaps, probably not but ..) >> > >> > I could of course block that IP - but that doesn't help, I'd have to >> > block endless IPs >> > >> > I'd like to know what's taking the CPU load, in theory they should be >> > connecting, supplying a password (perhaps) and sending data >> > but, there are sometimes bad passwords (2 for the 20th recorded in >> maillog) >> > >> > So.. >> > What are they doing the other times and why is it taking so much CPU - >> > if it is just a port knock, why the CPU >> > >> > I need to be able to say, they are bad because ... *what is the >> because* ? >> > >> > David Bray >> > 0418 745334 >> > 2 ∞ & < >> > >> > >> > On Mon, 20 Apr 2020 at 15:32, Remo Mattei > > <mailto:r...@mattei.org>> wrote: >> > >> > Hi, >> > Can you reach the server? It maybe blocking you. So what does your >> > queue looks like? >> > >> > Here is mine for example: >> > >
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Hi Andy - you have grasped the problem accurately As I understand it, the transaction does not leave a great deal of scope - negotiate the encryption, send a password successfully or unsuccessfully - (at that point it's logged) So it has to be the negotiation phase ... but: - I've only just built this server - stuck to a standard install using a CentOS 7 VM - 4GB: 2 CPU, 80GB - I think this adequate I've seen no OOM events - and the size is what I've used before The only thing I'm really seeing here that could be an issue is - the newer machines are stricter on SSL - the TLS 1/1.2 deprecation thing I see lots of broken servers, and have to *make allowances*, I do this by: touch /var/qmail/control/notlshosts/ Noting - that is an outbound thing ... (see https://www.qmailtoaster.org/notls.html) So .. is it possible that a broken client is hitting the port, not being able to make the necessary handshake and causing this CPU load It's reported in the logs when the server makes an outbound transaction like that ... deferral: TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_103.27.32.20./ What would it look like in my logs if they where to have the reverse issue David Bray 0418 745334 2 ∞ & < On Tue, 21 Apr 2020 at 02:54, Andrew Swartz wrote: > Port 465 should be SMTP over SSL/TLS. Therefore the sequence of events is: > > 1. Establish TCP connection > 2. Negotiate SSL/TLS session > 3. Begin SMTP session > > Of these, the SSL/TLS negotiation is by far the most CPU-intensive. > > Consider trying to see what is happening with the SSL/TLS negotiation. > It may be failing in a way which is slamming the CPU but not showing up > in the SMTP logs because it never completes and thus an SMTP session is > never initiated. > > I'm unsure the best way to debug the incoming SSL/TLS negotiation. You > might set a firewall rule where incoming port 465 from that single IP is > forwarded to stunnel (on another machine) which is set to output verbose > debug info??? > > It would be interesting to know the cause. This could be some clever > DOS attack where a single connection accomplishes the DOS by slamming > the CPU by submitting something invalid to openSSL. But it might just > be that some spammer is using a home-brewed script which is buggy and is > unintentionally causing this problem. > > There seems no efficient way to block this without figuring out the > cause and doing something to make that cause be logged into some log > file. Once that is accomplished, fail2ban (or something similar) can > easily add firewall rules to block individual IP's which exhibit this > behavior. > > -Andy > > > > > > On 4/19/2020 10:12 PM, David Bray wrote: > > Hey thanks Remo > > smtps is an inbound port, they are contacting me - this IP is in Russia > > somewhere - so do I want to engage (perhaps, probably not but ..) > > > > I could of course block that IP - but that doesn't help, I'd have to > > block endless IPs > > > > I'd like to know what's taking the CPU load, in theory they should be > > connecting, supplying a password (perhaps) and sending data > > but, there are sometimes bad passwords (2 for the 20th recorded in > maillog) > > > > So.. > > What are they doing the other times and why is it taking so much CPU - > > if it is just a port knock, why the CPU > > > > I need to be able to say, they are bad because ... *what is the because* > ? > > > > David Bray > > 0418 745334 > > 2 ∞ & < > > > > > > On Mon, 20 Apr 2020 at 15:32, Remo Mattei > <mailto:r...@mattei.org>> wrote: > > > > Hi, > > Can you reach the server? It maybe blocking you. So what does your > > queue looks like? > > > > Here is mine for example: > > > > # qmHandle -L > > Messages in local queue: 0 > > Messages in remote queue: 0 > > > > My other server > > > > # qmHandle -L > > 10355792 (19, L) > >Return-path: r...@qmailx.com <mailto:r...@qmailx.com> > >From: Anacron mailto:r...@qmail.com>> > >To: r...@qmailx.com <mailto:r...@qmailx.com> > >Subject: Anacron job 'cron.daily' on qmailx.com > > <http://qmailx.com> > >Date: 19 Apr 2020 10:28:28 - > >Size: 509 bytes > > > > 10358746 (6, L) > >Return-path: > >From: mailer-dae...@qmailxx.com > > <mailto:mailer-dae...@qmailxx.com> > >To: r...@qmail.com <mai
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Hey thanks Remo smtps is an inbound port, they are contacting me - this IP is in Russia somewhere - so do I want to engage (perhaps, probably not but ..) I could of course block that IP - but that doesn't help, I'd have to block endless IPs I'd like to know what's taking the CPU load, in theory they should be connecting, supplying a password (perhaps) and sending data but, there are sometimes bad passwords (2 for the 20th recorded in maillog) So.. What are they doing the other times and why is it taking so much CPU - if it is just a port knock, why the CPU I need to be able to say, they are bad because ... *what is the because* ? David Bray 0418 745334 2 ∞ & < On Mon, 20 Apr 2020 at 15:32, Remo Mattei wrote: > Hi, > Can you reach the server? It maybe blocking you. So what does your queue > looks like? > > Here is mine for example: > > # qmHandle -L > Messages in local queue: 0 > Messages in remote queue: 0 > > My other server > > # qmHandle -L > 10355792 (19, L) > Return-path: r...@qmailx.com > From: Anacron > To: r...@qmailx.com > Subject: Anacron job 'cron.daily' on qmailx.com > Date: 19 Apr 2020 10:28:28 - > Size: 509 bytes > > 10358746 (6, L) > Return-path: > From: mailer-dae...@qmailxx.com > To: r...@qmail.com > Subject: failure notice > Date: 19 Apr 2020 11:30:30 - > Size: 1089 bytes > > Messages in local queue: 2 > Messages in remote queue: 0 > > Just wonder it looks that you are using the SMTPs 465, did you try the 587 > Submission that address and see if it goes? > Just wonder if this is tight to that service. > > Maybe none of the above but just for troubleshooting steps, I would try > that. > > Remo > > > On Apr 19, 2020, at 22:11, David Bray wrote: > > Ok - but after all the investigation etc, this is actually the trigger > which caught my eye in the first place > > How this comes about is: > >1. User say hey I can't send >2. I look and see this high CPU load and intermittent failures for >client to send > > Any thoughts on where to start looking .. > > > > > my smtp/smtps are currently *10*/11 connections > > > ==> /var/log/qmail/smtp/current <== > 2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0 > 2020-04-20 05:07:50.207300500 tcpserver: status: 0/60 > > ==> /var/log/qmail/smtps/current <== > 2020-04-20 05:07:54.903665500 tcpserver: status: 9/60 > 2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5 > 2020-04-20 05:07:54.936655500 tcpserver: ok 29725 dev.brayworth.com: > 172.105.181.18:465 :185.50.149.5::5622 > 2020-04-20 05:08:00.108657500 tcpserver: status: 10/60 > 2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5 > 2020-04-20 05:08:00.152910500 tcpserver: ok 29734 dev.brayworth.com: > 172.105.181.18:465 :185.50.149.5::62006 > 2020-04-20 05:08:05.172650500 tcpserver: status: *11*/60 > 2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5 > 2020-04-20 05:08:05.208984500 tcpserver: ok 29740 dev.brayworth.com: > 172.105.181.18:465 :185.50.149.5::19686 > 2020-04-20 05:08:13.601336500 tcpserver: end 29690 status 256 > 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60 > > David Bray > 0418 745334 > 2 ∞ & < > > > On Sun, 19 Apr 2020 at 10:04, David Bray wrote: > >> Thanks Eric >> >> It's hard to track things but I think I have had success monitoring the >> /var/log/maillog >> >> I'm not sure why I didn't pick this up earlier, I'm already using the >> fail2ban suggestion of the older qmailtoaster wiki ( >> http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to >> process it and have expanded on this now >> >> I've been running email servers most of my working life and still get >> tripped up by simple stuff >> >> Thank for your efforts in this area, it helps to talk things out >> >> cheers >> >> David Bray >> 0418 745334 >> 2 ∞ & < >> >> >> On Sun, 19 Apr 2020 at 01:12, Eric Broch wrote: >> >>> It looks like a connect and disconnect. If there was authentication >>> you'd see it. I don't think you have anything to worry about here. I'm not >>> saying there's not some jerk out there messing with your smtps...just >>> saying it may be harmless. That said, do you have a good firewall in place >>> that prevents DOS attacks. I use Sonicwall myself but you can do the same >>> thing as others have shown with iptables. >>> >>> Does anyone know how to do the same with the stock firewalld on COS7/8? >>> On 4/17/2020 11:49 PM, Da
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Ok - but after all the investigation etc, this is actually the trigger which caught my eye in the first place How this comes about is: 1. User say hey I can't send 2. I look and see this high CPU load and intermittent failures for client to send Any thoughts on where to start looking .. [image: image.png] my smtp/smtps are currently *10*/11 connections ==> /var/log/qmail/smtp/current <== 2020-04-20 05:07:50.207299500 tcpserver: end 29699 status 0 2020-04-20 05:07:50.207300500 tcpserver: status: 0/60 ==> /var/log/qmail/smtps/current <== 2020-04-20 05:07:54.903665500 tcpserver: status: 9/60 2020-04-20 05:07:54.936654500 tcpserver: pid 29725 from 185.50.149.5 2020-04-20 05:07:54.936655500 tcpserver: ok 29725 dev.brayworth.com:172.105.181.18:465 :185.50.149.5::5622 2020-04-20 05:08:00.108657500 tcpserver: status: 10/60 2020-04-20 05:08:00.152909500 tcpserver: pid 29734 from 185.50.149.5 2020-04-20 05:08:00.152910500 tcpserver: ok 29734 dev.brayworth.com:172.105.181.18:465 :185.50.149.5::62006 2020-04-20 05:08:05.172650500 tcpserver: status: *11*/60 2020-04-20 05:08:05.208983500 tcpserver: pid 29740 from 185.50.149.5 2020-04-20 05:08:05.208984500 tcpserver: ok 29740 dev.brayworth.com:172.105.181.18:465 :185.50.149.5::19686 2020-04-20 05:08:13.601336500 tcpserver: end 29690 status 256 2020-04-20 05:08:13.601337500 tcpserver: status: 10/60 David Bray 0418 745334 2 ∞ & < On Sun, 19 Apr 2020 at 10:04, David Bray wrote: > Thanks Eric > > It's hard to track things but I think I have had success monitoring the > /var/log/maillog > > I'm not sure why I didn't pick this up earlier, I'm already using the > fail2ban suggestion of the older qmailtoaster wiki ( > http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to > process it and have expanded on this now > > I've been running email servers most of my working life and still get > tripped up by simple stuff > > Thank for your efforts in this area, it helps to talk things out > > cheers > > David Bray > 0418 745334 > 2 ∞ & < > > > On Sun, 19 Apr 2020 at 01:12, Eric Broch wrote: > >> It looks like a connect and disconnect. If there was authentication you'd >> see it. I don't think you have anything to worry about here. I'm not saying >> there's not some jerk out there messing with your smtps...just saying it >> may be harmless. That said, do you have a good firewall in place that >> prevents DOS attacks. I use Sonicwall myself but you can do the same thing >> as others have shown with iptables. >> >> Does anyone know how to do the same with the stock firewalld on COS7/8? >> On 4/17/2020 11:49 PM, David Bray wrote: >> >> sure - thanks for replying, this comes in waves taking the server to it's >> maximum at times >> >> as far as I can see this only logs are this: >> >> ==> /var/log/qmail/smtps/current <== >> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 >> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 >> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::25638 >> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 >> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 >> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::14862 >> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 >> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 >> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::9646 >> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 >> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 >> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::54058 >> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 >> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60 >> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256 >> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60 >> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256 >> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60 >> >> David Bray >> 0418 745334 >> 2 ∞ & < >> >> >> On Sat, 18 Apr 2020 at 15:41, Eric Broch wrote: >> >>> Can you send the log of one of the "bad" connections? >>> >>> On 4/17/2020 10:59 PM, David Bray wrote: >>> >>> I can see I'm getting hammered on my smtps port >>> >>> How can I mitigate this? >>> >>> I can see the IP's in /var/log/qmail/smtps/current >>> >>> *but where do I actually see that the smtp auth actually fails ?* >>> >>> or do I need to increase the logging somewhere ? >>> >>> if I tail -f /var/log/dovecot.log >>> >>> I can see the imap and pop failures >>> >>> thanks in advance >>> >>> David Bray >>> 0418 745334 >>> 2 ∞ & < >>> >>>
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Thanks Eric It's hard to track things but I think I have had success monitoring the /var/log/maillog I'm not sure why I didn't pick this up earlier, I'm already using the fail2ban suggestion of the older qmailtoaster wiki ( http://wiki.qmailtoaster.com/index.php/Fail2Ban), actually had a rule to process it and have expanded on this now I've been running email servers most of my working life and still get tripped up by simple stuff Thank for your efforts in this area, it helps to talk things out cheers David Bray 0418 745334 2 ∞ & < On Sun, 19 Apr 2020 at 01:12, Eric Broch wrote: > It looks like a connect and disconnect. If there was authentication you'd > see it. I don't think you have anything to worry about here. I'm not saying > there's not some jerk out there messing with your smtps...just saying it > may be harmless. That said, do you have a good firewall in place that > prevents DOS attacks. I use Sonicwall myself but you can do the same thing > as others have shown with iptables. > > Does anyone know how to do the same with the stock firewalld on COS7/8? > On 4/17/2020 11:49 PM, David Bray wrote: > > sure - thanks for replying, this comes in waves taking the server to it's > maximum at times > > as far as I can see this only logs are this: > > ==> /var/log/qmail/smtps/current <== > 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 > 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 > 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::25638 > 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 > 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 > 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::14862 > 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 > 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 > 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::9646 > 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 > 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 > 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 > dev.brayworth.com:172.105.181.18:465 > :141.98.80.30::54058 > 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 > 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60 > 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256 > 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60 > 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256 > 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60 > > David Bray > 0418 745334 > 2 ∞ & < > > > On Sat, 18 Apr 2020 at 15:41, Eric Broch wrote: > >> Can you send the log of one of the "bad" connections? >> >> On 4/17/2020 10:59 PM, David Bray wrote: >> >> I can see I'm getting hammered on my smtps port >> >> How can I mitigate this? >> >> I can see the IP's in /var/log/qmail/smtps/current >> >> *but where do I actually see that the smtp auth actually fails ?* >> >> or do I need to increase the logging somewhere ? >> >> if I tail -f /var/log/dovecot.log >> >> I can see the imap and pop failures >> >> thanks in advance >> >> David Bray >> 0418 745334 >> 2 ∞ & < >> >>
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Hi Tony, thanks
But not so much looking for a solution to block ips.
I’m needing to identify which ips to block
On Sat, 18 Apr 2020 at 8:19 pm, Tony White wrote:
> Or this...
>
> -- snip --
> #!/bin/bash
> logf="/var/log/blockip.log"
> mdate=`date +%c`
> mip=$1
> ### must be root ###
> if [ `whoami` != "root" ]; then
> echo ""
> echo "$0 must be run as root"
> echo ""
> exit 1
> fi;
>
> if [ $mip == "--help" ]; then
>echo ""
>echo "Help: Block single and subnet IP's"
>echo ""
>echo "blockip 130.2.1.1"
>echo "blockip 130.2.1.0/24"
>echo ""
>exit 1
> fi;
>
> mip1=${mip:0:6};
> # your lan range if needed or comment out
> if [ $mip1 == "192.168.1." ]; then # change ip to suit
>echo "$mdate Discarding LAN drop request for $mip1" >> $logf
>exit 1
> fi;
>
>
> # whitelist special clients...
> # change the IP.ADDR.ESS to suit.
> # comment out to remove
> if [ $mip == "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [ $mip ==
> "IP.ADDR.ESS" ] || [ $mip == "IP.ADDR.ESS" ] || [
> $mip == "IP.ADDR.ESS" ] ; then
>echo "$mdate Discarding WAN drop request for $mip" >> $logf
>echo "$mdate Discarding WAN drop request for $mip"
>exit 1
> fi;
>
> export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> is_ip="grep -Ec
> '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
>
> if [ `echo $mip |eval $is_ip` != "1" ]; then
>echo "$mdate Error in IP address $mip" >> $logf
>echo "$mdate Error in IP address $mip"
> else
>iptables -I INPUT -s $mip -j DROP
>echo "iptables -I INPUT -s $mip -j DROP"
>echo "iptables -I INPUT -s $mip -j DROP" >> /etc/rc.d/rc.blockedips
>echo "$mdate now dropping all packets from $mip" >> $logf
> fi;
> -- snip --
>
> best wishes
>Tony White
>
> On 18/4/20 8:09 pm, Tony White wrote:
>
> > Hi David,
> > Sorry try this instead...
> >
> > -- snip --
> > #!/bin/sh
> > logf="/var/log/blacklist_ip.log"
> > mdate=`date +%c`
> > ### must be root ###
> > if [ `whoami` != "root" ]; then
> > echo ""
> > echo "$0 must be ran as root"
> > echo ""
> > exit 1
> > fi
> > export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
> > is_ip="grep -Ec
> '^[1-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9]\.[0-2]?[0-9]?[0-9](\/[0-3]?[0-9])?$'"
> >
> > if [ `echo $1 |eval $is_ip` != "1" ]; then
> > echo "$mdate Error in IP address $1" >> $logf
> > else
> > echo "$1" >> /opt/spamdyke/etc/blacklist_ip
> > echo "$mdate now dropping all packets from $1" >> $logf
> > fi
> > --snip --
> >
> > best wishes
> > Tony White
> > On 18/4/20 8:04 pm, Tony White wrote:
> >
> >> Hi David,
> >> Try using this little script...
> >>
> >> -- snip --
> >> #!/bin/bash
> >> logf="/var/log/blockip.log"
> >> mdate=`date +%c`
> >> mip=$1
> >> ### must be root ###
> >> if [ `whoami` != "root" ]; then
> >> echo ""
> >> echo "$0 must be run as root"
> >> echo ""
> >> exit 1
> >> fi;
> >>
> >> if [ $mip == "--help" ]; then
> >> echo ""
> >> echo "Help: Block single and subnet IP's"
> >> echo ""
> >> echo "blockip 132.2.1.1"
> >> echo "blockip 132.1.0/24"
> >> echo ""
> >> exit 1
> >> fi;
> >>
> >> -- snip --
> >>
> >> worked for me forever...
> >> Use qtp watchall to monitor the logs and use th output to manually
> block ips or subnets
> >>
> >> If you need more hit me off list.
> >>
> >> best wishes
> >> Tony White
> >> On 18/4/20 2:59 pm, David Bray wrote:
> >>
> >>> I can see I'm getting hammered on my smtps port
> >>>
> >>> How can I mitigate this?
> >>>
> >>> I can see the IP's in /var/log/qmail/smtps/current
> >>>
> >>> *but where do I actually see that the smtp auth actually fails ?*
> >>>
> >>> or do I need to increase the logging somewhere ?
> >>>
> >>> if I tail -f /var/log/dovecot.log
> >>>
> >>> I can see the imap and pop failures
> >>>
> >>> thanks in advance
> >>>
> >>> David Bray
> >>> 0418 745334
> >>> 2 ∞ & <
> >>
> >>
> >> -
> >> 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
> >
>
>
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
> --
# David
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
Hi thanks - yes can block that IP But it’s not just one, and the solution is not fine enough I want more of a fail2ban rule, bad use bad pass 3 strikes your out I need to know they are mucking round. I tried sending myself through the port with a bad password- sure it blocks it, but there is no log of the event - it looks like a legit, connection from Ann IP On Sat, 18 Apr 2020 at 7:30 pm, Chris wrote: > Here's a great article with instructions on how to implement an IP > blacklist in iptables. Unless you've got a user in Panama, it looks like > you's want to block 141.98.80.30 > > https://linux-audit.com/blocking-ip-addresses-in-linux-with-iptables/ > > On Sat, Apr 18, 2020 at 5:49 PM David Bray wrote: > >> sure - thanks for replying, this comes in waves taking the server to it's >> maximum at times >> >> as far as I can see this only logs are this: >> >> ==> /var/log/qmail/smtps/current <== >> 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 >> 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 >> 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::25638 >> 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 >> 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 >> 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::14862 >> 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 >> 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 >> 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::9646 >> 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 >> 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 >> 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 >> dev.brayworth.com:172.105.181.18:465 >> :141.98.80.30::54058 >> 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 >> 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60 >> 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256 >> 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60 >> 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256 >> 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60 >> >> David Bray >> 0418 745334 >> 2 ∞ & < >> >> >> On Sat, 18 Apr 2020 at 15:41, Eric Broch wrote: >> >>> Can you send the log of one of the "bad" connections? >>> >>> On 4/17/2020 10:59 PM, David Bray wrote: >>> >>> I can see I'm getting hammered on my smtps port >>> >>> How can I mitigate this? >>> >>> I can see the IP's in /var/log/qmail/smtps/current >>> >>> *but where do I actually see that the smtp auth actually fails ?* >>> >>> or do I need to increase the logging somewhere ? >>> >>> if I tail -f /var/log/dovecot.log >>> >>> I can see the imap and pop failures >>> >>> thanks in advance >>> >>> David Bray >>> 0418 745334 >>> 2 ∞ & < >>> >>> -- # David
Re: [qmailtoaster] SMTPS Port - Who is Failing ?
sure - thanks for replying, this comes in waves taking the server to it's maximum at times as far as I can see this only logs are this: ==> /var/log/qmail/smtps/current <== 2020-04-18 05:04:48.450871500 tcpserver: status: 6/60 2020-04-18 05:04:48.480785500 tcpserver: pid 13339 from 141.98.80.30 2020-04-18 05:04:48.480787500 tcpserver: ok 13339 dev.brayworth.com:172.105.181.18:465 :141.98.80.30::25638 2020-04-18 05:04:52.797644500 tcpserver: status: 7/60 2020-04-18 05:04:52.830767500 tcpserver: pid 13340 from 141.98.80.30 2020-04-18 05:04:52.830768500 tcpserver: ok 13340 dev.brayworth.com:172.105.181.18:465 :141.98.80.30::14862 2020-04-18 05:04:57.248902500 tcpserver: status: 8/60 2020-04-18 05:04:57.304003500 tcpserver: pid 13342 from 141.98.80.30 2020-04-18 05:04:57.304006500 tcpserver: ok 13342 dev.brayworth.com:172.105.181.18:465 :141.98.80.30::9646 2020-04-18 05:05:01.854790500 tcpserver: status: 9/60 2020-04-18 05:05:01.902265500 tcpserver: pid 13345 from 141.98.80.30 2020-04-18 05:05:01.902266500 tcpserver: ok 13345 dev.brayworth.com:172.105.181.18:465 :141.98.80.30::54058 2020-04-18 05:05:09.729711500 tcpserver: end 13338 status 256 2020-04-18 05:05:09.729713500 tcpserver: status: 8/60 2020-04-18 05:06:05.965715500 tcpserver: end 13342 status 256 2020-04-18 05:06:05.965716500 tcpserver: status: 7/60 2020-04-18 05:06:06.141272500 tcpserver: end 13340 status 256 2020-04-18 05:06:06.141273500 tcpserver: status: 6/60 David Bray 0418 745334 2 ∞ & < On Sat, 18 Apr 2020 at 15:41, Eric Broch wrote: > Can you send the log of one of the "bad" connections? > > On 4/17/2020 10:59 PM, David Bray wrote: > > I can see I'm getting hammered on my smtps port > > How can I mitigate this? > > I can see the IP's in /var/log/qmail/smtps/current > > *but where do I actually see that the smtp auth actually fails ?* > > or do I need to increase the logging somewhere ? > > if I tail -f /var/log/dovecot.log > > I can see the imap and pop failures > > thanks in advance > > David Bray > 0418 745334 > 2 ∞ & < > >
[qmailtoaster] SMTPS Port - Who is Failing ?
I can see I'm getting hammered on my smtps port How can I mitigate this? I can see the IP's in /var/log/qmail/smtps/current *but where do I actually see that the smtp auth actually fails ?* or do I need to increase the logging somewhere ? if I tail -f /var/log/dovecot.log I can see the imap and pop failures thanks in advance David Bray 0418 745334 2 ∞ & <
Re: [qmailtoaster] Re: Login activity report
Hi I'm not sure about a tool, but the information is in the dovecot log - tail /var/log/dovecot.log David Bray 0418 745334 2 ∞ & < On Wed, 15 Apr 2020 at 13:58, ChandranManikandan wrote: > Hi Friends, > > I hope you are well > > Now everyone is WFH, > So i would like to know if any way to take report for all the email > accounts login & logout and active hours report. > Anyone using any tool. > > Am using Centos 7 with qmailtoaster. > > Appreciate your help. > > On Thu, Apr 9, 2020 at 12:13 PM ChandranManikandan > wrote: > >> Hi Friends, >> >> I hope you are well >> >> Now everyone is WFH, >> So i would like to know if any way to take report for all the email >> accounts login & logout and active hours report. >> Anyone using any tool. >> >> Am using Centos 7 with qmailtoaster. >> >> Appreciate your help. >> >> -- >> >> >> *Regards,Manikandan.C* >> > > > -- > > > *Regards,Manikandan.C* >
[qmailtoaster] sslv3_alert_handshake_failure
I get these error messages with some servers Is it me or them or any suggestions I've just migrated to *CentOS Linux release 7.7.1908 (Core)* Error message from /var/log/qmail/send/current deferral: TLS_connect_failed:_error:14077410:SSL_routines:SSL23_GET_SERVER_HELLO:sslv3_alert_handshake_failure;_connected_to_209.222.82.135./ I checked with ckecktls their server and it seems to be a barracuda setup - d66963a.ess.barracudanetworks.com [209.222.82.141:25] David Bray 0418 745334 2 ∞ & <
[qmailtoaster] MariaDB port - Firewall
Hi - I have a very old Toaster install and considering upgrading etc. Could I ask: - port 3306/tcp is open on the firewall and my.cng doesn't restrict networking My old install bound localhost - bind=127.0.0.1 I notice you also open up 20/tcp,21/tcp and 113/tcp - and install vsftpd - are they necessary for a mail server ? David Bray 0418 745334 2 ∞ & <
Re: [qmailtoaster] Squirrelmail alternatives? Looking for recs
after logic is my choice - I use the lite - http://www.afterlogic.org/ Its equally as easy as round cube to setup *David Bray* http://www.brayworth.com.au da...@brayworth.com.au /*Done* is better than *Perfect*/ On 7/12/2012 3:24 AM, Diana Calder wrote: Anyone using something other than Squirrelmail for webmail with Qmailtoaster? I'm working my way through researching the options listed in the Wiki but I'd like to get some feedback from someone who's actually using one of the alternative webmail packages. So far, it looks like atmail is gone (the free community version, at least), and AfterLogic lite, eGroupware, Horde, and RoundCube all look like they're worth taking a deeper look at. I'd prefer something that looks a little less dated than Squirrelmail and that has a good mobile interface. Our Intranet is a hosted Noodle instance, so I'm not really interested in extra bells and whistles like calendars and such - just good solid email features like a decent address book (though a nice shared one in addition to personal ones would be nice), the ability to set a vacation response, basic filtering, and allowing individual users to change their password. eGroupware is probably overkill for our needs and even Horde may be a little over the top - but they're also the two nicest looking. I'll be continuing to research but some helpful comments from the Qmailtoaster community would be greatly appreciated. Hoping for some good recommendations, Diana
[qmailtoaster] DKIM - What should be the Server Name be ?
As in - what should be in */var/qmail/control/me* Traditionally I've always thought of the Server Name as it's canonical name - that's what goes in */var/qmail/control/me* by default I found https://help.ubuntu.com/community/Postfix/DomainKeys useful - it noted in addition to the wiki's TXT entry there should also be a _domainkey.domain.tld. IN TXT t=y; o=~; * note the *t=y;* section should be deleted once up and running Wikipedia is also useful, and this page: * http://wiki.qmailtoaster.com/index.php/How_to_Setup_DKIM_with_Qmail_Toaster But - and these things are always tricky to get working * The dkim implementation in the wiki uses */var/qmail/control/me* o specified in */var/qmail/control/dkim/signconf.xml* o someservername.domain.tld I couldn't get it to work correctly and would fail with - not sure if this is the last error but /permerror/ was a significant one (in the headers of a yahoo mail) So I changed /var/qmail/control/dkim/signconf.xml, changing the attribute * *domain=* to reflect * *domain=**domain.tld* and regenerated the keys* * * *Bingo !* * Yahoo liked it* * so in the end * /var/qmail/control/me = server.domain.tld * /var/qmail/control/dkim/signconf.xml = domain.tld if that makes sense ... -- *David Bray* w. http://www.brayworth.com.au m. 0418 745334 e. da...@brayworth.com.au /PS: I don't trust the cloud .../
Re: [qmailtoaster] re: backup question
Hi Hey when you send an image through a mail server this is the rule that's triggered .. 1.7 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of words It's enough to trigger my spam defences .. On 28/06/2012 10:14 AM, Cecil Yother, Jr. wrote: I have two servers, server A and server B. They are both Centos 5.8, built on the V2gnu iso. They are basically identical with all updates. I have about a dozen e mail domains on server A and 2 e mail domains on server B. Can I run the qtp-backup on server B and restore those on server A so that all my mail domains reside on one server? TIA --
Re: [qmailtoaster] Re: Qmail and squirrelmail query
Thanks for that - Linode is definitely my next one - I'll wait because I assume the Fedora 15 will be available soon now it is released *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 25/05/2011 3:59 AM, Postmaster wrote: I suggested Linode! I used to run Qmail on 384Mb RAM VPS on the Linode, but it was not easy as SpamAssassin took most of RAM so VPS had to be rebooted several times. Right now I run Qmail on two VPSs 512Mb and 768Mb with ClamAV and SpamAssassin without any issues. If you have a huge traffic (=1000 e-mails a day) I'd suggest to go for 768Mb RAM. Rgds Alex On 24/05/2011 00:10, David Bray wrote: Me 3 here, you can't do QMT on shared hosting, you need a VPS. Someone suggested the Linode and that looks good, VPSLink is one I've used, You need 512Mb once Clam and SpamAssassin start working. It is difficult to manage CLAM in a 512 container without swap - VPSLink don't have swap, Linode does. I'm currently using a Westnet/iiNet VPS - because it is close in Aus. *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 23/05/2011 11:56 PM, Eric Shubert wrote: On 05/23/2011 12:18 AM, Joselito Tapangan wrote: I have a question regarding this QMAIL. Right now our current mail server is a physical box running the Qmail toaster and we usually using the squirrelmail. Recently, Our company is planning to transfer it to a hosting providers. Here are the following question that needs to be answered. 1.) Does Qmail and squirrelmail can be installed in a shared hosting? If Yes/No please give me some explaination of how to do it. If you provide a link related this topic. Certainly. I don't have experience personally with hosting providers, but I think there are some in the community that run QMT in hosted environments. You'll need root access to your host. I would recommend 512M of RAM, and 6G HDD for the system plus whatever space you need for mailboxes. 2.) Does any shared hosting is already has already offered a service with Qmail and squirrelmail installed already? can you please suggest 1 or 2 samples of that Hosting Provider I'm not aware of any who provide a prebuilt QMT image.
Re: [qmailtoaster] Re: Qmail and squirrelmail query
Hi Eric, just to stop you wondering Truly - I am VPS all the way ... A number of years back I was hosting everything on the end of my ADSL line, after years of hosting on the end of 64k ISDN, Satelite connections etc .. the speed when ADSL came about was nice. It was business grade ADSL 512k/512k and had a Service Level Aggreement - pretty good and reliable. I was overseas and lightning took out the transformer at the end of the street, along with the UPS and popped the power supply - I never conceived that would happen. After a lengthy phone call to my Electrician Uncle in Law - who had the keys to the house and was at least an electrician and assuring him it wasn't that hard - hey how bad is not working at all. . Now - I have no hardware - was it Forest Gump who said, one less thing to worry about *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 24/05/2011 8:35 AM, Eric Shubert wrote: Thanks for clearing that up, David. I do wonder why people look to hosting providers for installing QMT. You can run a small QMT domain on a PII-266MH w/ 512M (that was my first QMT host). QMT really doesn't take much to run, especially with spamdyke installed. Building the rpms may take a little while, but so what? With qtp-newmodel, the server is still online while the rpms build. You can even run one on a dynamic IP address, provided you use a service such as DynDNS for dynamic DNS services and outbound email (smarthost) relay. To each his own though. I realize that self hosting isn't always practical, although it is more so than many seem to realize.
Re: [qmailtoaster] Re: Qmail and squirrelmail query
I know - but of the toaster recipes - this is one that works for VPS. *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 26/05/2011 9:42 AM, Eric Shubert wrote: Interesting, David. Thanks. Doesn't change my mind though. ;) On 05/25/2011 04:36 PM, David Bray wrote: Hi Eric, just to stop you wondering Truly - I am VPS all the way ... A number of years back I was hosting everything on the end of my ADSL line, after years of hosting on the end of 64k ISDN, Satelite connections etc .. the speed when ADSL came about was nice. It was business grade ADSL 512k/512k and had a Service Level Aggreement - pretty good and reliable. I was overseas and lightning took out the transformer at the end of the street, along with the UPS and popped the power supply - I never conceived that would happen. After a lengthy phone call to my Electrician Uncle in Law - who had the keys to the house and was at least an electrician and assuring him it wasn't that hard - hey how bad is not working at all. . Now - I have no hardware - was it Forest Gump who said, one less thing to worry about *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 24/05/2011 8:35 AM, Eric Shubert wrote: Thanks for clearing that up, David. I do wonder why people look to hosting providers for installing QMT. You can run a small QMT domain on a PII-266MH w/ 512M (that was my first QMT host). QMT really doesn't take much to run, especially with spamdyke installed. Building the rpms may take a little while, but so what? With qtp-newmodel, the server is still online while the rpms build. You can even run one on a dynamic IP address, provided you use a service such as DynDNS for dynamic DNS services and outbound email (smarthost) relay. To each his own though. I realize that self hosting isn't always practical, although it is more so than many seem to realize.
Re: [qmailtoaster] Re: Qmail and squirrelmail query
Me 3 here, you can't do QMT on shared hosting, you need a VPS. Someone suggested the Linode and that looks good, VPSLink is one I've used, You need 512Mb once Clam and SpamAssassin start working. It is difficult to manage CLAM in a 512 container without swap - VPSLink don't have swap, Linode does. I'm currently using a Westnet/iiNet VPS - because it is close in Aus. *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 23/05/2011 11:56 PM, Eric Shubert wrote: On 05/23/2011 12:18 AM, Joselito Tapangan wrote: I have a question regarding this QMAIL. Right now our current mail server is a physical box running the Qmail toaster and we usually using the squirrelmail. Recently, Our company is planning to transfer it to a hosting providers. Here are the following question that needs to be answered. 1.) Does Qmail and squirrelmail can be installed in a shared hosting? If Yes/No please give me some explaination of how to do it. If you provide a link related this topic. Certainly. I don't have experience personally with hosting providers, but I think there are some in the community that run QMT in hosted environments. You'll need root access to your host. I would recommend 512M of RAM, and 6G HDD for the system plus whatever space you need for mailboxes. 2.) Does any shared hosting is already has already offered a service with Qmail and squirrelmail installed already? can you please suggest 1 or 2 samples of that Hosting Provider I'm not aware of any who provide a prebuilt QMT image.
Re: [qmailtoaster] Re: SpamAssassin Version
Hi. Good comment about the Binary v Source - thats actually the strength of this recipe as I a see it, it blends source packages and provides a neat rpm install The challenge is not so much the disk space as the memory requirement to compile clam on the machine once the machine is deployed - man I dread the freshclam message (despite the large friendly letters ) DON'T PANIC! *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 3/05/2011 2:14 AM, Dan McAllister wrote: Just to throw my 2-cents worth in here... Binary packages are fine in a well-controlled environment, but source packages offer far more flexibility -- especially if the Makefiles are sophisticated enough to recognize advanced features and take advantage of them (without REQUIRING them). And while binary packages of SpamAssassin and ClamAV are likely available in binary form (and it may not be a bad idea to make the QMT dependent on the standard installation features and locations of each of these), the fact is that QMT grew up in a time when QMail itself was REQUIRED to be distributed in a source format -- part of the licensing requirement of Daniel Bernstein, author of QMail. (I don't think that's true anymore, since Daniel put QMail truly into the Public Domain, but I never worried about that so I'm not totally up-to-date on QMail licensing requirements). NOTE: I already use QMail in a VM environment (CentOS 5.6 is the host OS, Xen is the VM environment, and CentOS 5.5 is my current guest OS running QMT -- I'll update that at some time in the future, but I'm honestly expecting to wait for CentOS 6 before I upgrade the base QMT again). The point is, you are right that there is a sizable disk-space requirement to rebuild the entire QMT from source (*esp*. ClamAV)... but there is an easy way to patch that! Specifically, I mount an NFS volume from my Xen Host to supplement my Xen Client's storage while I build, then unmount and destroy the temp space when I'm done. NOTE: For ME this works especially well because I administer so many QMT installs -- I update the VM image, then distribute it to my clients. All of their actual data (the queue, the mailboxes, the control folder, etc.) are kept on NFS-mounted drives on the HOST OS -- so only the binary QMT is actually run on the Xen-Client... this is not a NORMAL config, and wouldn't be MY config if it weren't for my need to manage so many installs at the same time. Take from this what you wish -- discard the rest. It's worth every penny you paid for it! Dan IT4SOHO On 4/30/2011 1:23 AM, Martin Waschbüsch IT-Dienstleistungen wrote: Am 30.04.2011 um 05:40 schrieb David Bray: Thanks for the Feedback Understand about the Fedora Lifetime etc. I use VM's and Fedora 13 is the current Fedora. Tried Ubuntu, CentOS and keep coming back to Fedora - mainly because the php is more up to date The driving line is not so much SA - SpamAssassin as Clam, on my last server - Fedora 12 based, there was an issue with spam and the update to SA 3.3 did get me into later rule sets (via sa-update) You can - in the Fedora 13 case, substitute in yum install spamassassin with little difficulty, basically install the package, it pulls in what it needs, then create the scripts to run under daemontools. The clamav is harder, but I have it running, though untested. The end aim is just to let the rpm system update clam, rather than having to recompile to src rpm so why is that so bad ? well the toaster works fine on a VM with 20Gb HDD and 512k ram but to recompile the clam package you have to stop the services to free up memory ... so having a recipe for utilizing then yum package is nice ... which brings you back to your argument, Fedora 13 will only have a short life for clamav updates via yum David Bray http://www.brayworth.com.au da...@brayworth.com.au Not everything is perfect with QMT, I would agree, but at the same time: it works! And as Eric pointed out, CentOS / RHEL 5.x is the most current version of the recommended OS for QMT. Jake is working on QMTv2 which will incorporate some changes and it will actually address some of the things you mention (like an option to just install binary packages instead of compile from source). That being said, if you'd like to help with QMT, please join the qmailtoaster-devel list as well! Cheers, Martin - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr
Re: [qmailtoaster] Re: SpamAssassin Version
Thanks - looks good, good price ... Their distributions look up to the minute too - will give one of these a shot. David Bray http://www.brayworth.com.au da...@brayworth.com.au On 1/05/2011 8:37 PM, Postmaster wrote: Ref VMs try linode.com Regards Alex - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: SpamAssassin Version
I joined the Devel list as suggested, will look to what I can do there With the VM's - who sells cheap VM's with Swap, I'm using vpslink, no swap but ... only 512M - yes - M not k, used to have an XT with 512k, upgraded it to 640k .. long time ago ... They have a CentOS 5 option there - will look at it when I have a chance David Bray http://www.brayworth.com.au da...@brayworth.com.au On 1/05/2011 12:55 AM, Eric Shubert wrote: On 04/29/2011 10:23 PM, Martin Waschbüsch IT-Dienstleistungen wrote: Am 30.04.2011 um 05:40 schrieb David Bray: Thanks for the Feedback Understand about the Fedora Lifetime etc. I use VM's and Fedora 13 is the current Fedora. Tried Ubuntu, CentOS and keep coming back to Fedora - mainly because the php is more up to date Actually, F14 is current (released 2010/11/02), and F15 is scheduled for release this coming Monday (2011/05/02), which means that F13 will reach EOL on 2011/06/02. :( The driving line is not so much SA - SpamAssassin as Clam, on my last server - Fedora 12 based, there was an issue with spam and the update to SA 3.3 did get me into later rule sets (via sa-update) Would it be possible for you to work on getting the SA 3.3.1 source rolled into the spamassassin-toaster package? I'm sure Jake would welcome the help. As Martin suggested, we'd love to see you on the devel list. You can - in the Fedora 13 case, substitute in yum install spamassassin with little difficulty, basically install the package, it pulls in what it needs, then create the scripts to run under daemontools. Jake's been working on trying to use the upstream packages as much as possible. I'm sure he would welcome some help with this. Unfortunately, that won't help with getting SA3.3.1 into COS5.x though. There's probably a fairly decent reason though why RH hasn't brought SA3.3.x into v5.x. OTOH, SA3.3.1 *is* in the rpmforge-extras repo for CentOS5, so it could be had from there. The clamav is harder, but I have it running, though untested. The end aim is just to let the rpm system update clam, rather than having to recompile to src rpm In the meantime, Jake's been very good at keeping clamav-toaster up to date. That package is easily updated with qtp-newmodel. It does take some time to compile, but qtp-newmodel allows that to happen while your QMT is still online. so why is that so bad ? It's not. As previously mentioned, QMTv2 will be yum-able. :) well the toaster works fine on a VM with 20Gb HDD and 512k ram but to recompile the clam package you have to stop the services to free up memory ... so having a recipe for utilizing then yum package is nice ... My QMT is a VM w/ 512M RAM (I think you meant 512M, not 512k), and I have no problem building clamav-toaster on it using qtp-newmodel. # free total used free sharedbuffers cached Mem:514908 399284 115624 0 27004 117636 -/+ buffers/cache: 254644 260264 Swap: 1044216 721044144 Perhaps there's something in your Fedora configuration that's causing a problem there? Do you have ample swap available? which brings you back to your argument, Fedora 13 will only have a short life for clamav updates via yum BL, it might be possible that going with Fedora is causing as much of a problem as it's solving. I'm all for getting SA up to current on COS5. I think that if you were to use the rpmforge-extras repo along with a little help from the devel list, you can achieve your objectives while helping the community as well. I expect that you'd also free up some time to do other things, besides updating your Fedora release every 6 months. ;) David Bray http://www.brayworth.com.au da...@brayworth.com.au Thanks for your help with this David. I really don't mean to beat you up at all. I'm just trying to help you the best I can, and look forward to your continued participation in the community. Not everything is perfect with QMT, I would agree, but at the same time: it works! And as Eric pointed out, CentOS / RHEL 5.x is the most current version of the recommended OS for QMT. Jake is working on QMTv2 which will incorporate some changes and it will actually address some of the things you mention (like an option to just install binary packages instead of compile from source). That being said, if you'd like to help with QMT, please join the qmailtoaster-devel list as well! Cheers, Martin - +1 Martin. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today
[qmailtoaster] SpamAssassin Version
The SpamAssassin install installs version 3.2.5 These comments apply to Clam as well, Clam is more complex, but it makes the version updating a lot easier. If the Install was per Bill Schupp's notes: http://billslinuxqmail.sourceforge.net/toaster/ Then SpamAssassin version would be 3.3.2 I've just done an install on Fedora 13 and deviated from the recipe with SpamAssassin and Clam Just curious ... -- *David Bray* http://www.brayworth.com.au da...@brayworth.com.au
Re: [qmailtoaster] Re: SpamAssassin Version
I've just used the QMT Recipe - and the good thing is the RPM based Install, quite modular etc .. but the version of SpamAssassin winds up at 3.2.5, SpamAssassin at SpamAssassin is 3.3.1, Yum on Fedora 13 installs 3.3.2 I'm just trying to understand the reasoning behind sticking with a 3.2 based package There doesn't seem to be any issue running 3.3 with this recipe - and SpamA (and ClamAV) are packages that are always changing, the rest of QMT seems quite static. *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 30/04/2011 11:08 AM, Eric Shubert wrote: On 04/29/2011 03:47 PM, David Bray wrote: The SpamAssassin install installs version 3.2.5 These comments apply to Clam as well, Clam is more complex, but it makes the version updating a lot easier. If the Install was per Bill Schupp's notes: http://billslinuxqmail.sourceforge.net/toaster/ Then SpamAssassin version would be 3.3.2 I've just done an install on Fedora 13 and deviated from the recipe with SpamAssassin and Clam Just curious ... -- *David Bray* http://www.brayworth.com.au da...@brayworth.com.au I don't understand the point of this post. While Bill's Qmail Toaster is similar in many ways to QMT as they're both based on Life With Qmail, there are substantial differences as well. Sorry, but we do not support BQT here. See the corresponding email list for that.
Re: [qmailtoaster] Re: SpamAssassin Version
Thanks for the Feedback Understand about the Fedora Lifetime etc. I use VM's and Fedora 13 is the current Fedora. Tried Ubuntu, CentOS and keep coming back to Fedora - mainly because the php is more up to date The driving line is not so much SA - SpamAssassin as Clam, on my last server - Fedora 12 based, there was an issue with spam and the update to SA 3.3 did get me into later rule sets (via sa-update) You can - in the Fedora 13 case, substitute in /yum install spamassassin/ with little difficulty, basically install the package, it pulls in what it needs, then create the scripts to run under daemontools. The clamav is harder, but I have it running, though untested. The end aim is just to let the rpm system update clam, rather than having to recompile to src rpm so why is that so bad ? well the toaster works fine on a VM with 20Gb HDD and 512k ram but to recompile the clam package you have to stop the services to free up memory ... so having a recipe for utilizing then yum package is nice ... which brings you back to your argument, Fedora 13 will only have a short life for clamav updates via yum *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 30/04/2011 12:14 PM, Eric Shubert wrote: SpamAssassin 3.2.5 is current for CentOS 5.x. When CentOS 6.x is available (probably in a month or so), I expect that Jake will make a spamassassin-toaster 3.3.1 (which is current for RHEL6.0) package available. While there is probably not a major problem running SA3.3 with QMT presently, there is always a possibility. QMT is relying on perl rpm packages as opposed to CPAN for perl modules, which is also a consideration. I haven't personally looked at the guidelines for upgrading SA from 3.2 to 3.3, so I don't rightly know what the impact might be. FWIW, Fedora is not recommended for production use, primarily because of the short lifetime of each version. F13 will be EOL very soon (one month after F15 is available). Is there some feature of SA 3.3.1 that you're eager to have?
Re: [qmailtoaster] Re: patch utility under Fedora 13
Hi Jake thanks for replying this was my build results - I agree, don't worry about Fedora 13, 15 is just around the corner. But the VM at this providor is only 13 - I have this up and running now Where I had to manually specify the target, the first line of the patch refers to a file without path, adding ./ to the front of the file and using -p1 did the trick , -p0 is not the same as no -p at all daemontools-toaster-*.src.rpm = changes p0 - p1 ucspi-tcp-toaster-*.src.rpm = changes p0 - p1 = one patch had to manually specify target vpopmail-toaster-*.src.rpm = Unsure, think there was one p0 - p1, but made no notes libdomainkeys-toaster-*.src.rpm= no changes libsrs2-toaster-*.src.rpm= no changes qmail-toaster-*.src.rpm = changes p0 - p1 = two patchs had to manually specify target courier-authlib-toaster-*.src.rpm= no changes courier-imap-toaster-*.src.rpm= no changes autorespond-toaster-*.src.rpm= no changes control-panel-toaster-*.src.rpm = no changes = warning: line 529: prereq is deprecated: Prereq: /usr/bin/perl = warning: line 529: prereq is deprecated: Prereq: /usr/bin/perl = warning: line 632: prereq is deprecated: Prereq:/usr/bin/perl ezmlm-toaster-*.src.rpm= no changes qmailadmin-toaster-*.src.rpm= no changes qmailmrtg-toaster-*.src.rpm= no changes maildrop-toaster-*.src.rpm= no changes isoqlog-toaster-*.src.rpm = changes p0 - p1 = warning: line 517: buildprereq is deprecated: BuildPreReq: qmail-toaster = 1.03, control-panel-toaster = 0.2 vqadmin-toaster-*.src.rpm = changes p0 - p1 = one patch (user.c) had to manually specify target squirrelmail-toaster-*.src.rpm = changes p0 - p1 = warning: line 554: prereq is deprecated: Prereq: /usr/bin/perl = warning: line 554: prereq is deprecated: Prereq: /usr/bin/perl spamassassin-toaster-*.src.rpm= no changes clamav-toaster-*.src.rpm= no changes ripmime-toaster-*.src.rpm= no changes simscan-toaster-*.src.rpm= no changes *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 18/04/2011 12:03 AM, Jake Vickers wrote: On 04/15/2011 07:33 PM, David Bray wrote: Hi Martin It does help to understand how this work, but I'm still left puzzled. I can compile it manually, but work with a life of 6 month on the servers and update and move the data, so it important to me that I get the install process right to make the migration quick ... hence the time spent on this. You can send me a list of packages that fail. I have already re-diff'ed some packages to bring the patch files current. I will test this under F14, but I will not test under F13. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: patch utility under Fedora 13
Hi Martin It does help to understand how this work, but I'm still left puzzled. I can compile it manually, but work with a life of 6 month on the servers and update and move the data, so it important to me that I get the install process right to make the migration quick ... hence the time spent on this. My reading of the patch documentation says that the utility is working a intended, but the spec files are in error. Or Fedora changes the execution directories when applying the patch. It's is a battle and I have re-initialised the VM Container and am about to start again. I've managed to work out daemontools, that was pretty simple, change the patch from 0 to 1 But then ucspi-tcp-rbltimeout.patch.bz2 of the ucspi-tcp-toaster-0.88-1.3.9.src.rpm has me stumped This is decompressed on the fly and applied - the first line is: --- rblsmtpd.c2007-01-14 12:42:22.0 +0100 According to man patch this should be applied with no switches at all, or read --- ./rblsmtpd.c2007-01-14 12:42:22.0 +0100 but you can't just take the patch parameters away, fedora substitutes in -p0 as default. There is a path to apply Fedora 14 upgrades to the VM - wonder if parallels will handle a change in kernel *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 16/04/2011 2:55 AM, Martin Waschbüsch IT-Dienstleistungen wrote: Am 15.04.2011 um 02:17 schrieb David Bray: Did Jake have some thoughts on this - or should I just unpack, adjust the patch switch and compile ? - any shortcuts ? David Bray http://www.brayworth.com.au da...@brayworth.com.au On 12/04/2011 12:59 AM, Eric Shubert wrote: Jake can answer you question best. He manages the patch files. I gotta ask though, why F13? F14 is current, and F15 release is right around the corner (scheduled for 2011-05-24), which means that F13 will no longer be maintained in only a couple months (2011-06-24). See http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule Fedora is generally not a good choice for a production server, due to its relatively short lifetime. CentOS is a more stable platform, and is recommended for production QMT use. CentOS5.6 just came out this past weekend, and will not reach end of life for another 3 years (2014-03-31). By then, Fedora will be up to release 20. I think you get the picture. At the same time, we do appreciate people who install QMT on Fedora, so we can get things like this worked out well in advance of them arriving in CentOS. Thanks. Hi, The problem is not the patch utility itself, but the patch included in the package. It likely includes some fuzziness and the patch utility in Fedora is not tolerant when it comes to this. Personally, I think this is a good idea. The problem happens when you apply a patch that was calculated against e.g. software version 2 and is now applied to software version 2.1. If the file to patch has the lines to patch on different line numbers, some systems allow (by default) applying the patch with the offset (=fuzziness) while others do not. Hope that helps, Martin -- Martin Waschbüsch IT-Dienstleistungen Lautensackstr. 16 80687 München Telefon: +49 89 57005708 Fax: +49 89 57868023 Mobil: +49 170 2189794 serv...@waschbuesch.it http://www.waschbuesch.it - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: patch utility under Fedora 13
Did Jake have some thoughts on this - or should I just unpack, adjust the patch switch and compile ? - any shortcuts ? *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 12/04/2011 12:59 AM, Eric Shubert wrote: Jake can answer you question best. He manages the patch files. I gotta ask though, why F13? F14 is current, and F15 release is right around the corner (scheduled for 2011-05-24), which means that F13 will no longer be maintained in only a couple months (2011-06-24). See http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule Fedora is generally not a good choice for a production server, due to its relatively short lifetime. CentOS is a more stable platform, and is recommended for production QMT use. CentOS5.6 just came out this past weekend, and will not reach end of life for another 3 years (2014-03-31). By then, Fedora will be up to release 20. I think you get the picture. At the same time, we do appreciate people who install QMT on Fedora, so we can get things like this worked out well in advance of them arriving in CentOS. Thanks.
Re: [qmailtoaster] Re: patch utility under Fedora 13
THanks Eric Why Fedora ? * Well I like it ... * But overlying, with VM's which are off the shelf sort of things, It's more a case of what is available And with the toaster, I've been using it for a while and have got the machine scripted so I can migrate every few months to a later platform *David Bray* http://www.brayworth.com.au da...@brayworth.com.au On 12/04/2011 12:59 AM, Eric Shubert wrote: Jake can answer you question best. He manages the patch files. I gotta ask though, why F13? F14 is current, and F15 release is right around the corner (scheduled for 2011-05-24), which means that F13 will no longer be maintained in only a couple months (2011-06-24). See http://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule Fedora is generally not a good choice for a production server, due to its relatively short lifetime. CentOS is a more stable platform, and is recommended for production QMT use. CentOS5.6 just came out this past weekend, and will not reach end of life for another 3 years (2014-03-31). By then, Fedora will be up to release 20. I think you get the picture. At the same time, we do appreciate people who install QMT on Fedora, so we can get things like this worked out well in advance of them arriving in CentOS. Thanks.
[qmailtoaster] patch utility under Fedora 13
During the install process (amongst other things) the packages are installed from source and the patch utility applies patches then they are compiled .. The patch utility uses the switch p0 and this fails, but p1 works it fails on the new box: * it runs fine on the old box o the old box is Fedora release 12 (Constantine) 32bit o the new box is Fedora release 13 (Goddard) 64bit * patch is ... o patch-2.6.1-4.fc12.i686 o patch-2.6.1-8.fc13.x86_64 * it fails for assume all, but certainly the first 2 o daemontools o ucspi-tcp-toaster + /usr/bin/patch -s -p0 --fuzz=0 /usr/bin/patch: rejecting target file name with .. component: ../ucspi-tcp-0.88/error.h I've been able to successfully compile by changing the switch to p1 + /usr/bin/patch -s -p1 --fuzz=0 So do I need to mod all the srpms or is there something else ? Thanks in advance -- *David Bray* http://www.brayworth.com.au da...@brayworth.com.au
