Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Suggested options (not sure how to do it -- hurt my back and not thinking 100% this morning): - Users are the only ones who should be using SMTP AUTH, and they should NOT be using port 25 when they do it... so the SMTP daemon on port 25 should NOT ALLOW SMTP AUTH at all - Its up to you whether you support SUBMISSION connections on port 587 with or without SSL, but in my case I REQUIRE SSL on both ports 587 and 465 (several mail clients will specifically look for 465 with SSL before even trying 587). Of course, this means that I either pay for a publicly signed SSL certificate, or make my users import my self-signed certificate. Once you're connecting on ports 587 or 465 over SSL, the AUTH method is less important -- it's all encrypted in the SSL connection. Just my thoughts... Dan McAllister On 9/10/2013 9:59 AM, Eric Shubert wrote: On 09/10/2013 02:34 AM, Johannes Weberhofer wrote: Dear all! For security reasons I have disabled the storage of vpopmail's plain-text passwords. Upon connection the qmail-server still responds with 250-server.test.com - Welcome to Qmail Toaster Ver. 1.03.5 SMTP Server 250-STARTTLS 250-PIPELINING 250-8BITMIME 250-SIZE 20971520 250 AUTH LOGIN PLAIN CRAM-MD5 Qmail's implementation of cram-md5 is implemented in a way, that the plain-text password is required [1] for CRAM-MD5 authentication. My problem is, that some clients are sending the CRAM-MD5 response, but Qmail is not able to process it correctly. Unfortunately I have not found a way to turn this feature off. Does someone know, how to? Best regards, Johannes [1] http://en.wikipedia.org/wiki/CRAM-MD5 You're one step ahead of me, Johannes. :) I had planned to do so by having spamdyke handle authentication. The current version doesn't implement this quite rightly though, but it'll be fixed in the soon to be released version. In the meantime, check for qmail config options in the .spec file. There might be a ./configure option for turning cram-md5 off. I don't know off hand, but I would expect so. Either that or vpopmail. I don't recall off hand how qmail makes the determination of which auth methods are available. Please let me know how you make out with this. Thanks! P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail! - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] SPAM Emails generating from server
Please find below SMTP log. 2013-09-12 17:08:05.533459500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt onessaad...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.533460500 policy_check: remote internalrevenueserv...@internalrevenue.org - remote onessaad...@yahoo.com(UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.533461500 policy_check: policy allows transmission 2013-09-12 17:08:05.579302500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt oni...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.579305500 policy_check: remote internalrevenueserv...@internalrevenue.org - remote oni...@yahoo.com(UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.579306500 policy_check: policy allows transmission 2013-09-12 17:08:05.581583500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt opensky...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.581585500 policy_check: remote internalrevenueserv...@internalrevenue.org - remote opensky...@yahoo.com(UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.581586500 policy_check: policy allows transmission 2013-09-12 17:08:05.663348500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt onurgo...@uaeu.ac.ae : client allowed to relay 2013-09-12 17:08:05.663352500 policy_check: remote internalrevenueserv...@internalrevenue.org - remote onurgo...@uaeu.ac.ae(UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.663353500 policy_check: policy allows transmission Such spam emails are getting generated from server. Where do I look for source of the same? What will happen if I blacklist 127.0.0.1 IP in spamdyke? Regards, Amit
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister On 9/10/2013 12:39 PM, Eric Shubert wrote: On 09/10/2013 08:06 AM, Johannes Weberhofer wrote: P.S. Just to be clear, plain-text passwords are required for any implementation of cram-md5, not just qmail's. That's a weakness which is inherent in the protocol. The wiki page says, that some (dovecot) implementation stores a intermediate step of HMAC, so I guess there is anoter way to do that, too. I sit corrected. :) http://wiki2.dovecot.org/HowTo/CRAM-MD5 Again, I don't know off hand. I suspect that it's vpopmail which needs the clear text for it's implementation of cram-md5. If vpopmail can be configured/changed in such a way that it uses a password hash instead of clear text for cram-md5, that would seem to be ideal. I'm not adverse to keeping cram-md5, but I think the storage of plain text passwords needs to go bye-bye. I know of several potential users we've lost due to this, and it's simply a bad practice. I know there are some users who have expressed a preference to keep plain text passwords. It would be nice to have an option whereby they could continue this insecure practice, and I will try to provide this option if it doesn't take too much work. I think the 'stock' QMT should not be configured in this manner though, and someone else may need to do the development to make this possible if I can't come up with an easy way to accommodate it. -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail! - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Fwd: ezmlm warning
Sorry about that -- I implemented DMARC for my own domain, and gmail was grabbing that because there was no DMARC record in qmailtoaster.com. Mail for the qmailtoaster.com domain doesn't go through my systems, so its odd that gmail is doing that... I've queried google about it (DMARC is kinda new, so there are some odd implementations out there), but haven't heard back. In the mean time, I gave qmailtoaster.com its own DMARC record in the DNS and I believe that will settle the issue. Dan McAllister QMT DNS/Mirror Admin (NOT the mail admin! -- but now you see how dependent we are on DNS... again!) On 9/10/2013 6:42 PM, Roxanne Sandesara wrote: Looks like Gmail/Google is getting cranky about it4soho's policies or configuration. Is anyone else seeing these problems? Roxie Begin forwarded message: *From: *qmailtoaster-list-h...@qmailtoaster.com mailto:qmailtoaster-list-h...@qmailtoaster.com *Subject: **ezmlm warning* *Date: *September 10, 2013 4:29:04 AM EDT *To: *roxie.sil...@gmail.com mailto:roxie.sil...@gmail.com Hi! This is the ezmlm program. I'm managing the qmailtoaster-list@qmailtoaster.com mailto:qmailtoaster-list@qmailtoaster.com mailing list. I'm working for my owner, who can be reached at qmailtoaster-list-ow...@qmailtoaster.com mailto:qmailtoaster-list-ow...@qmailtoaster.com. Messages to you from the qmailtoaster-list mailing list seem to have been bouncing. I've attached a copy of the first bounce message I received. If this message bounces too, I will send you a probe. If the probe bounces, I will remove your address from the qmailtoaster-list mailing list, without further notice. I've kept a list of which messages from the qmailtoaster-list mailing list have bounced from your address. Copies of these messages may be in the archive. To retrieve a set of messages 123-145 (a maximum of 100 per request), send an empty message to: qmailtoaster-list-get.123_...@qmailtoaster.com mailto:qmailtoaster-list-get.123_...@qmailtoaster.com To receive a subject and author list for the last 100 or so messages, send an empty message to: qmailtoaster-list-in...@qmailtoaster.com mailto:qmailtoaster-list-in...@qmailtoaster.com Here are the message numbers: 14778 14791 --- Enclosed is a copy of the bounce message I received. Return-Path: Received: (qmail 10672 invoked for bounce); 29 Aug 2013 03:28:43 - Date: 29 Aug 2013 03:28:43 - From: mailer-dae...@mail.qmailtoaster.com mailto:mailer-dae...@mail.qmailtoaster.com To: qmailtoaster-list-return-147...@qmailtoaster.com mailto:qmailtoaster-list-return-147...@qmailtoaster.com Subject: failure notice Hi. This is the qmail-send program at mail.qmailtoaster.com http://mail.qmailtoaster.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. roxie.sil...@gmail.com mailto:roxie.sil...@gmail.com: User and password not set, continuing without authentication. roxie.sil...@gmail.com mailto:roxie.sil...@gmail.com 173.194.69.26 failed after I sent the message. Remote host said: 550-5.7.1 Unauthenticated email from it4soho.com http://it4soho.com is not accepted due to domain's 550-5.7.1 DMARC policy. Please contact administrator of it4soho.com http://it4soho.com domain if 550-5.7.1 this was a legitimate mail. Please visit 550-5.7.1 http://support.google.com/mail/answer/2451690 to learn about DMARC 550 5.7.1 initiative. t9si59667bkh.168 - gsmtp -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail!
Re: [qmailtoaster] Re: how to move all failure notice message to one email address
Actually, I usually see this when the catchall setting is set to an address that doesn't exist, or forwards to an address that doesn't exist. This also happens when, as Eric was alluding to, the failure is actually fake -- the message it's complaining about wasn't your message to begin with (thus, backscatter). My solution is a simple one... I stop playing so nicely because I'm tired of being taken advantage of... that is, I set all of my domains catchall setting to DELETED. Now, if you send mail to d...@it4soho.com instead of d...@it4soho.com... you won't know you screwed up... my mail server will accept the mis-addressed mail and delete it. The reduction in SPAM when I did that was measurable! Specifically because people could no longer mine my mailserver for email addresses. They're all accepted, so miners quit trying -- everything they try appears to succeed, so they don't have a clue which ones actually get delivered. An alternative (if you're worried about valid mis-directed mail) is to setup a special catchall account -- but be prepared to get a lot of mail in there! I hope this helps Dan McAllister On 9/11/2013 12:36 PM, Eric Shubert wrote: On 09/10/2013 08:14 PM, ChandranManikandan wrote: Hi All, Am getting below message from server Hi. This is the qmail-send program at mail..net http://mail..net. I tried to deliver a bounce message to this address, but the bounce bounced! and shows unknown email address which is not sent email or communicate with them earlier. but they tried to send spam and am getting bounce message of our email address and it's receive this message randomly . So all our users forward to me instead of they are getting this message. So how to receive all failure notice message in single email address only instead of receiving all our domain email account. if possible to catch all failure notice bounce message to only one email account. Please help me anyone. -- */Thanks Best Regards, Manikandan.C /* This is what's called backscatter. http://en.wikipedia.org/wiki/Backscatter_%28email%29 Setting up SPF should help. http://wiki.qmailtoaster.com/index.php/Spf Dan posted a message to this list recently regarding SPF as well. -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail! - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] DENIED_RDNS_MISSING and DENIED_OTHER
Vivek: You appear to believe that every message your server receives is legitimate and should be delivered... a belief that was common in the 1980's and 1990's and resulted in SMTP (the protocol) being so very easy to use for SPAM. We've learned our lesson, but are stuck in backward compatibility hell and thus, about 80% of email hosting activities these days is some form of SPAM control. If you are receiving mail from a server that has no RDNS, you are most likely receiving SPAM or mail from a mis-configured domain (or, in a small percentage of cases - mail from a domain that just changed IP addresses and forgot to have the RDNS entry created -- but that will be very rare, and its on them to fix it! Your error message tells them what is wrong, so they'll have to fix it themselves!). Effective SPAM control requires that public mail servers (that is, the ones that send mail from one domain to another) be on a static IP address and have a valid (non-generic) PTR record on that IP address. The RDNS_Missing message says that they didn't implement that PTR record, and so you rejected it... FWIW, Google, Yahoo!, Outlook, AOL, and all of the other big mail providers will block those messages too! As for the denied other message, you should look at other nearby lines in the log file -- there is likely another program blocking it for virus content or because its in an RBL you're subscribed to, or something similar. One final word from me on this: - whitelisting sending domains is something that should only be done when the two domains (sending and receiving) are well known to each other and have a legitimate reason for making sure all messages are received. One example I have seen is that I whitelist the local courthouse (clerk of the court) for my attorney clients so that legal service emails are not processed for SPAM content. My thoughts, my ideas... if you like them, keep them as your own... if not, kindly discard them in an environmentally friendly manner! :-) Dan McAllister On 9/11/2013 1:12 AM, Linux wrote: Hi All, I have the problem with receiving the mails, when I go through SMTP logs I found maximum error DENIED_RDNS_MISSING and DENIED_OTHER If I put the domain in adjust whitelist senders, then it solved, but there are lots of domain that I can't put it manually or monitor daily. Please give me the best solution so that I can fixed that issue. Regards, Vivek Patil system admin -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail!
Re: [qmailtoaster] Re: how to move all failure notice message to one email address
If you want to include your ISP's mail services, you'll need to know if your ISP even uses SPF (most do). - You could call them... good luck getting to talk to someone who knows what SMTP even stands for with most ISPs!... - Or, you could dig around a little Locally, brighthouse networks (actually roadrunner) is a major ISP -- but until now, I didn't know if they used SPF... how did I find out? - *dig txt tampabay.rr.com* tells me that they have a dedicated record for SPF entries: a._spf.rr.com - *dig txt a._spf.rr.com* tells me that all rr mail is getting sent through one of 4 public servers So, assuming my private mail server is at address 1.1.1.1, and assuming (for example) that you're a roadrunner customer, your SPF record would look like: *@ IN TXT v=spf1 include:a._spf.rr.com ip4:1.1.1.1 ~all* NOTE: At least for a while, I recommend using the ~all -- once you're sure things are working, switch to -all. - the ~all means you're just testing SPF... failures are soft fail failures, so most servers will still accept failed SPF messages on your domain. - the -all says you're fully implementing SPF and failures are hard failures and you're asking receiving servers to reject failed messages This'll get you started! Dan McAllister On 9/12/2013 1:13 AM, ChandranManikandan wrote: Hi Eric, Thanks for your help. I understand my problem now. My domain is hosting with my service provider. But our email and web server is running in house. So they are redirect our domain to our server public ip. My server spfbehaviour is 3 now and suggest me How to make spf for my domain. This spf need to make myself or hosting provider. If i need to make myself kindly give me the default spf syntax example. I saw the spf syntax but some how afraid to make myself. if you give some example it will help full for me. On Thu, Sep 12, 2013 at 12:36 AM, Eric Shubert e...@shubes.net mailto:e...@shubes.net wrote: On 09/10/2013 08:14 PM, ChandranManikandan wrote: Hi All, Am getting below message from server Hi. This is the qmail-send program at mail..net http://mail..net http://mail..net. I tried to deliver a bounce message to this address, but the bounce bounced! and shows unknown email address which is not sent email or communicate with them earlier. but they tried to send spam and am getting bounce message of our email address and it's receive this message randomly . So all our users forward to me instead of they are getting this message. So how to receive all failure notice message in single email address only instead of receiving all our domain email account. if possible to catch all failure notice bounce message to only one email account. Please help me anyone. -- */Thanks Best Regards, Manikandan.C /* This is what's called backscatter. http://en.wikipedia.org/wiki/Backscatter_%28email%29 Setting up SPF should help. http://wiki.qmailtoaster.com/index.php/Spf Dan posted a message to this list recently regarding SPF as well. -- -Eric 'shubes' - 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 -- */Thanks Best Regards, Manikandan.C /* -- PLEASE TAKE NOTE OF OUR NEW ADDRESS === IT4SOHO, LLC 33 - 4th Street N, Suite 211 St. Petersburg, FL 33701-3806 CALL TOLL FREE: 877-IT4SOHO 877-484-7646 Phone 727-647-7646 Local 727-490-4394 Fax We have support plans for QMail!
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Am 12.09.2013 14:21, schrieb Dan McAllister: Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister Dan, the problem is easily described: when someone gets access to the database (content, dumps, backups) this person will have full access to the plain passwords; as many users re-use the passwords that's a very critical issue. Best regards, Johannes -- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
Hi, My 2 cents: On Thu, Sep 12, 2013 at 7:22 PM, Johannes Weberhofer jweberho...@weberhofer.at wrote: Am 12.09.2013 14:21, schrieb Dan McAllister: Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister Dan, the problem is easily described: when someone gets access to the database (content, dumps, backups) this person will have full access to the plain passwords; as many users re-use the passwords that's a very critical issue. Would it be possible to encrypt the passwords in the db but at the same time also offer a tool to print out the password in clear text (decrypt it) if one knows a master password? An another option would be to make the postmaster password a master password that could be used to access all accounts in that domain. I can imagine many occasions for small service providers that they need to access their customers' webmails to check some preferences or to debug if their email is working / not working. Changing the client's password every time to do this feels cumbersome... Regards, Peter
[qmailtoaster] Re: how to move all failure notice message to one email address
On 09/12/2013 05:35 AM, Dan McAllister wrote: Actually, I usually see this when the catchall setting is set to an address that doesn't exist, or forwards to an address that doesn't exist. This also happens when, as Eric was alluding to, the failure is actually fake -- the message it's complaining about wasn't your message to begin with (thus, backscatter). My solution is a simple one... I stop playing so nicely because I'm tired of being taken advantage of... that is, I set all of my domains catchall setting to DELETED. Now, if you send mail to d...@it4soho.com instead of d...@it4soho.com... you won't know you screwed up... my mail server will accept the mis-addressed mail and delete it. The reduction in SPAM when I did that was measurable! Specifically because people could no longer mine my mailserver for email addresses. They're all accepted, so miners quit trying -- everything they try appears to succeed, so they don't have a clue which ones actually get delivered. An alternative (if you're worried about valid mis-directed mail) is to setup a special catchall account -- but be prepared to get a lot of mail in there! I hope this helps Dan McAllister I agree with Dan that bouncing misaddressed email is a bad idea, to keep miners at bay. I do choose to use a catchall account account. I hardly get any messages there at all, mostly misaddressed emails (eg DAM@). I can imagine that some domains might get a lot of spam though. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/12/2013 11:12 AM, Peter Peltonen wrote: Hi, My 2 cents: On Thu, Sep 12, 2013 at 7:22 PM, Johannes Weberhofer jweberho...@weberhofer.at mailto:jweberho...@weberhofer.at wrote: Am 12.09.2013 14:21, schrieb Dan McAllister: Eric, Why wouldn't it be possible to keep the plaintext password field in the vpopmail database, but protect it? I would think you could compile vpopmail to keep the cleartext passwords, but then create an additional user in the DB (an admin user) and restrict rights to view that field to the admin user. (NOTE: You still have to have write permission to that field from the vpopmail user so that updates/changes can be recorded). Just an idea... Dan McAllister Dan, the problem is easily described: when someone gets access to the database (content, dumps, backups) this person will have full access to the plain passwords; as many users re-use the passwords that's a very critical issue. Would it be possible to encrypt the passwords in the db but at the same time also offer a tool to print out the password in clear text (decrypt it) if one knows a master password? An another option would be to make the postmaster password a master password that could be used to access all accounts in that domain. I can imagine many occasions for small service providers that they need to access their customers' webmails to check some preferences or to debug if their email is working / not working. Changing the client's password every time to do this feels cumbersome... Regards, Peter I know it seems cumbersome, but it's really not all that bad. Administrators should be able to change passwords, but not see in any way what they currently are. What's the point of encrypting a password if someone can decrypt it? That's not the way encryption works. It's a one-way street (which is why it works). Who's watching the watchers? - Enemy Of The State (movie, IIRC) ;) -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: SPAM Emails generating from server
On 09/12/2013 05:20 AM, Amit wrote: Please find below SMTP log. 2013-09-12 17:08:05.533459500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt onessaad...@yahoo.com mailto:onessaad...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.533460500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote onessaad...@yahoo.com mailto:onessaad...@yahoo.com (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.533461500 policy_check: policy allows transmission 2013-09-12 17:08:05.579302500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt oni...@yahoo.com mailto:oni...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.579305500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote oni...@yahoo.com mailto:oni...@yahoo.com (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.579306500 policy_check: policy allows transmission 2013-09-12 17:08:05.581583500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt opensky...@yahoo.com mailto:opensky...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.581585500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote opensky...@yahoo.com mailto:opensky...@yahoo.com (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.581586500 policy_check: policy allows transmission 2013-09-12 17:08:05.663348500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt onurgo...@uaeu.ac.ae mailto:onurgo...@uaeu.ac.ae : client allowed to relay 2013-09-12 17:08:05.663352500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote onurgo...@uaeu.ac.ae mailto:onurgo...@uaeu.ac.ae (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.663353500 policy_check: policy allows transmission Such spam emails are getting generated from server. Where do I look for source of the same? What will happen if I blacklist 127.0.0.1 IP in spamdyke? Regards, Amit I would configure your squirrelmail to authenticate in /etc/squirrelmail/config_local.php: # these are added so SM authenticates, # eliminating need for 127.: line in /etc/tcprules.d/tcp.smtp file $smtpServerAddress = 'localhost'; $smtpPort = 587; $smtp_auth_mech = 'login'; and restart httpd: # service httpd restart Then remove the 127. line from /etc/tcprules.d/tcp.smtp file, and rebuild the cdb file: # qmailctl cdb This will keep any rogue process on your host from using QMT as an open relay. See if this fixes things, and we can go from there. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: DENIED_RDNS_MISSING and DENIED_OTHER
On 09/12/2013 05:49 AM, Dan McAllister wrote: As for the denied other message, you should look at other nearby lines in the log file -- there is likely another program blocking it for virus content or because its in an RBL you're subscribed to, or something similar. Just to be clear, RBLs are processed by spamdyke (not rblsmtpd), so you will see a DENIED_RBL_MATCH message which even names the blacklist which it matched on. Pretty cool. DENIED_OTHER messages are rejections due to anything which is not a spamdyke filter. Dan's correct, that you'll usually find a message just before the DENIED_OTHER message which describes the other mechanism which rejected it, usually SpamAssassin. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/12/2013 05:16 AM, Dan McAllister wrote: Suggested options (not sure how to do it -- hurt my back and not thinking 100% this morning): - Users are the only ones who should be using SMTP AUTH, and they should NOT be using port 25 when they do it... so the SMTP daemon on port 25 should NOT ALLOW SMTP AUTH at all I agree that submissions SHOULD NOT use port 25, and I'd like to have all client submissions use port 587. I just don't think it's practical to deny authentications on port 25 though. I think forcing clients to use port 587 would create a lot of helpdesk issues, and to what benefit? I think all it would accomplish would be to tick off some users, unless you could somehow get them all converted to use port 587 ahead of implementing the restriction. In any case, I think QMT is going to need to allow for configuring port 25 to accept authentication (submissions). However, once spamdyke is handling authentication (running on both ports 25 and 587), it should be trivial to configure it to prohibit authentication on port 25. I'll mention this to Sam, to see how this might work. - Its up to you whether you support SUBMISSION connections on port 587 with or without SSL, but in my case I REQUIRE SSL on both ports 587 and 465 (several mail clients will specifically look for 465 with SSL before even trying 587). Of course, this means that I either pay for a publicly signed SSL certificate, or make my users import my self-signed certificate. I agree entirely with this. The stock QMT will support SMTPS(465) in a future release (although it's not exactly compliant with RFCs, many clients and servers have implemented it). I hope to use spamdyke to enforce encrypted authentication as well (deny plain text authorization), the same as dovecot presently does. Of course on port 465, this wouldn't be necessary since the entire session is encrypted. Once you're connecting on ports 587 or 465 over SSL, the AUTH method is less important -- it's all encrypted in the SSL connection. 10-4. Just my thoughts... Thanks! -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On 09/12/2013 06:48 PM, Eric Shubert wrote: I'll mention this to Sam, to see how this might work. Good thing I checked the documentation before I posted: http://www.spamdyke.org/documentation/README.html#SMTP_AUTH The none value will effectively turn off smtp-auth, disabling submissions on port 25 (except for domains in rcpthosts). -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Can I disable CRAM-MD5 authentication for submission service?
On Wed, 11 Sep 2013 15:07:31 +0200, Johannes Weberhofer wrote:
this line in the spec will remove CRAM-MD5 completely:
%{__perl} -pi -e s|\#define CRAM_MD5||g qmail-smtpd.c
I'd like to do this as well to remove the dependence on pw_clear_passwd. It's
really this easy? And the clients that were using CRAM MD5 before will then use
the alternative available option(s) during the smtp/submission transaction?
I look forward to seeing this as a full howto up on the wiki. ;)
Quinn
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: SPAM Emails generating from server
I'm using roundcube webmail as well. Anyway I had already blacklisted 127.0.0.1 in my spamdyke configuration and it worked. Thanks. Amit Dalia -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 13 September 2013 06:42 To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: SPAM Emails generating from server On 09/12/2013 05:20 AM, Amit wrote: Please find below SMTP log. 2013-09-12 17:08:05.533459500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt onessaad...@yahoo.com mailto:onessaad...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.533460500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote onessaad...@yahoo.com mailto:onessaad...@yahoo.com (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.533461500 policy_check: policy allows transmission 2013-09-12 17:08:05.579302500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt oni...@yahoo.com mailto:oni...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.579305500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote oni...@yahoo.com mailto:oni...@yahoo.com (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.579306500 policy_check: policy allows transmission 2013-09-12 17:08:05.581583500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt opensky...@yahoo.com mailto:opensky...@yahoo.com : client allowed to relay 2013-09-12 17:08:05.581585500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote opensky...@yahoo.com mailto:opensky...@yahoo.com (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.581586500 policy_check: policy allows transmission 2013-09-12 17:08:05.663348500 CHKUSER relaying rcpt: from internalrevenueserv...@internalrevenue.org:: remote User:unknown:127.0.0.1 rcpt onurgo...@uaeu.ac.ae mailto:onurgo...@uaeu.ac.ae : client allowed to relay 2013-09-12 17:08:05.663352500 policy_check: remote internalrevenueserv...@internalrevenue.org mailto:internalrevenueserv...@internalrevenue.org - remote onurgo...@uaeu.ac.ae mailto:onurgo...@uaeu.ac.ae (UNAUTHENTICATED SENDER) 2013-09-12 17:08:05.663353500 policy_check: policy allows transmission Such spam emails are getting generated from server. Where do I look for source of the same? What will happen if I blacklist 127.0.0.1 IP in spamdyke? Regards, Amit I would configure your squirrelmail to authenticate in /etc/squirrelmail/config_local.php: # these are added so SM authenticates, # eliminating need for 127.: line in /etc/tcprules.d/tcp.smtp file $smtpServerAddress = 'localhost'; $smtpPort = 587; $smtp_auth_mech = 'login'; and restart httpd: # service httpd restart Then remove the 127. line from /etc/tcprules.d/tcp.smtp file, and rebuild the cdb file: # qmailctl cdb This will keep any rogue process on your host from using QMT as an open relay. See if this fixes things, and we can go from there. -- -Eric 'shubes' - 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
