[qmailtoaster] Re: to catch all or no
On 05/20/2014 02:28 PM, Jim Shupert wrote: so ...kinda funny. I set my catch all to my s...@mydom.com that account had a quota of (default ) 40 MB now it is full. so my Question is: how do i empty a user mailbox? empty the queue.? thanks also , is it OK to not have a catch all? I currently have deleted my catchall. via the qmail admin ...in short - no red dot next to anybody. thanks jim - I have more to say about this subject, but for now, methinks that if your catchall account is getting that much email, then there's likely something you're not doing to reduce spam. Do you have spamdyke installed? If not, you should do so. If you have spamdyke installed, please post your config for it. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: to catch all or no
Il 20/05/2014 23:36, Dan McAllister ha scritto: Jim: Per the discussion Antonio and I have been having on this same thread: - I say to set the "invalid" behavior to "delete" (which it appears you have done) - Antonio says to send a bounce message (I disagree and say that this is the WORST of the 3 options) I never said to bounce messages. I said to reject them at SMTP level, which is completely different from bouncing messages. First option: reject at SMTP level (Save traffic, give the correct answer to sender) rcpt to: 511 sorry, no mailbox here by that name Regards, Tonino -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: to catch all or no
Jim: Per the discussion Antonio and I have been having on this same thread: - I say to set the "invalid" behavior to "delete" (which it appears you have done) - Antonio says to send a bounce message (I disagree and say that this is the WORST of the 3 options) - The "catchall" account is the 3rd option (which you have tried -- and seen fill up rather quickly) Again, my own personal recommendation is the delete option you are now using. Dan McAllister On 5/20/2014 5:28 PM, Jim Shupert wrote: so ...kinda funny. I set my catch all to my s...@mydom.com that account had a quota of (default ) 40 MB now it is full. so my Question is: how do i empty a user mailbox? empty the queue.? thanks also , is it OK to not have a catch all? I currently have deleted my catchall. via the qmail admin ...in short - no red dot next to anybody. thanks jim - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- 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] Re: to catch all or no
so ...kinda funny. I set my catch all to my s...@mydom.com that account had a quota of (default ) 40 MB now it is full. so my Question is: how do i empty a user mailbox? empty the queue.? thanks also , is it OK to not have a catch all? I currently have deleted my catchall. via the qmail admin ...in short - no red dot next to anybody. thanks jim - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: to catch all or no
Il 20/05/2014 17:23, Dan McAllister ha scritto: Antonio, While I understand your point, I think you have some misunderstandings about how the "real" mail (snail-mail) works. - If my address is 1234 Main St N, Anytown USA 12345 and you mail a letter to 123 Main St, Sometown USA 12346 -- that letter will likely *never *make it to *me *(You don't even have to bungle it in 3 places like I did -- any SINGLE of those errors not just MAY, but PROBABLY WILL, result in the failure of the INTENDED recipient getting the letter. The days of your local postal carrier looking closely and attempting (sometimes with great effort) to make the delivery to the RIGHT PERSON are long (in some areas LONG LONG) since gone! If the address is wrong, it'll be delivered to a nearby address (most likely wrong), where it'll most likely be trashed. Want to test this? Send a letter addressed to Daniel G McAllister, Saint Petersburg, FL 33712... and see if you get anything back. (You won't -- and I won't get the letter, either!) This may be in your case, but here in Italy, usually paper mails with wrong address are returned to sender. Of course, it is different if cards come from abroad, as returning them back has added costs. But that does not change the quality of service, which can be improved for free in electronic emails, returning the correct information to the sender (reject with reason explained). /- Sad but funny aside: a neighbor of mine got into trouble at the US post office by self-reporting that she received mail addressed to me, but improperly delivered to her. She was threatened with a fine and/or jail time because she gave me the mail instead of returning it to the post office for re-delivery./ - JUST like the mail service, there is no guarantee that an e-mail has been delivered UNLESS you ask for delivery confirmation. Default is delivered for both. But with electronic email it's more easy to report any failure. - UNLIKE the mail service, you can choose NOT to verify delivery in e-mail The default is email delivered. The real difference is not on delivery, but on reading receipt. - UNLIKE the mail service, email has ZERO security during the transmission of your message. (essentially, the "envelope" is NOT sealed!) Paper postcards are readable by anyone. With TLS you may have ends protected. In future we'll have TLS also on server to server commmunication probably. - LIKE the mail, email only promises a "best effort" to deliver the message -- and like mail, the definition of "best effort" has changed over the years. Yes, it should improve a lot with email, so best effort should be better than in the past. But you also mentioned RFCs, and believe me I am a believer in RFCs...however: - While SOME RFCs state that there should be REJECT messages sent, there are others that state that dropping undeliverable messages is equally valid (e.g.: RFC 5321, ca. 2008) which noted the increased implementation of NOT bouncing undeliverable messages for multiple reasons. While the RFC cautioned against being too aggressive in dropping messages, I think that reference was more to the act of dropping SPAM and other "legitimately addressed" mail, based on content. (And that is a DIFFERENT discussion) NOTE: The RFCs also state that you should NOT accept RELAY mail on port 25 (that is, outbound messages from users) [RFC 6409]. Unless you're careful (and I am), QMAIL (and more specifically, QMT) violates that RFC. Anyone know an ISP that blocks port 25 (Verizon residential)? How about one that accepts mail on port 8080? (That's supposed to be for non-root web servers) -- all "violations" of RFCs. But since RFCs are there for "easy interoperability", so long as all of your own clients know that you use port 8080 for SUBMISSION, you're perfectly OK you just have to handle it when a client comes to you and says "my mail program won't do that". We relay on port 25 of a dedicated address with forced authentication (it's a different server only for SMTP, not for MX), and also accept relay on authenticated submission port 587. So our authenticate customers can send anyway, because SMTP is different from MX. Our port 25 on MX do not relay. This change semplify life to our customers and does not affect in any way external communications. - RFCs are "standards" that are in place to make it easier for people to send/receive data on the Internet without having to separately negotiate and design the interfaces. They are not "laws" and not even "rules"... they are more "guidelines"... what happens when you VIOLATE RFCs is simply that you risk not being able to be easily accessed by others... and in many cases (like the ESPs that use port 8080), sometimes those "violations" are on purpose (to hide from abusers). Another RFC that is broken OFTEN is the message coding for REJECT messages -- 4.x.x messages are supposed to be f
Re: [qmailtoaster] Re: to catch all or no
Antonio, While I understand your point, I think you have some misunderstandings about how the "real" mail (snail-mail) works. - If my address is 1234 Main St N, Anytown USA 12345 and you mail a letter to 123 Main St, Sometown USA 12346 -- that letter will likely *never *make it to *me *(You don't even have to bungle it in 3 places like I did -- any SINGLE of those errors not just MAY, but PROBABLY WILL, result in the failure of the INTENDED recipient getting the letter. The days of your local postal carrier looking closely and attempting (sometimes with great effort) to make the delivery to the RIGHT PERSON are long (in some areas LONG LONG) since gone! If the address is wrong, it'll be delivered to a nearby address (most likely wrong), where it'll most likely be trashed. Want to test this? Send a letter addressed to Daniel G McAllister, Saint Petersburg, FL 33712... and see if you get anything back. (You won't -- and I won't get the letter, either!) /- Sad but funny aside: a neighbor of mine got into trouble at the US post office by self-reporting that she received mail addressed to me, but improperly delivered to her. She was threatened with a fine and/or jail time because she gave me the mail instead of returning it to the post office for re-delivery./ - JUST like the mail service, there is no guarantee that an e-mail has been delivered UNLESS you ask for delivery confirmation. - UNLIKE the mail service, you can choose NOT to verify delivery in e-mail - UNLIKE the mail service, email has ZERO security during the transmission of your message. (essentially, the "envelope" is NOT sealed!) - LIKE the mail, email only promises a "best effort" to deliver the message -- and like mail, the definition of "best effort" has changed over the years. But you also mentioned RFCs, and believe me I am a believer in RFCs...however: - While SOME RFCs state that there should be REJECT messages sent, there are others that state that dropping undeliverable messages is equally valid (e.g.: RFC 5321, ca. 2008) which noted the increased implementation of NOT bouncing undeliverable messages for multiple reasons. While the RFC cautioned against being too aggressive in dropping messages, I think that reference was more to the act of dropping SPAM and other "legitimately addressed" mail, based on content. (And that is a DIFFERENT discussion) NOTE: The RFCs also state that you should NOT accept RELAY mail on port 25 (that is, outbound messages from users) [RFC 6409]. Unless you're careful (and I am), QMAIL (and more specifically, QMT) violates that RFC. Anyone know an ISP that blocks port 25 (Verizon residential)? How about one that accepts mail on port 8080? (That's supposed to be for non-root web servers) -- all "violations" of RFCs. But since RFCs are there for "easy interoperability", so long as all of your own clients know that you use port 8080 for SUBMISSION, you're perfectly OK you just have to handle it when a client comes to you and says "my mail program won't do that". - RFCs are "standards" that are in place to make it easier for people to send/receive data on the Internet without having to separately negotiate and design the interfaces. They are not "laws" and not even "rules"... they are more "guidelines"... what happens when you VIOLATE RFCs is simply that you risk not being able to be easily accessed by others... and in many cases (like the ESPs that use port 8080), sometimes those "violations" are on purpose (to hide from abusers). Another RFC that is broken OFTEN is the message coding for REJECT messages -- 4.x.x messages are supposed to be for "delayed" delivery, and 5.x.x messages for solid rejects. Also, the x and x values are supposed to tell you the detailed REASON for the reject. Far too many ESPs use "generic" failure reject messages, or will reject a message with a 4.x.x result, or delay a message with a 5.x.x result... all in error. FINALLY: I'm not against users(senders) getting information back, but I'm also not about to _/facilitate /_/_abusers_ /in deceiving my clients/users either. The BOUNCE mechanism isn't solely about address phishing -- it is also abused by SPAMMERS who forge reply-to addresses so that the "payload" SPAM is delivered as a BOUNCE message from a legitimate server, even though the original source is illegitimate. I adhere to some basic principles: - properly addressed messages are ALWAYS delivered (even if SA gives it a 100 score!). - the only exceptions are when the sender's domain provides a mechanism to validate the source & tells me to reject messages that don't meet that validation. (This is what SPF, DomainKeys, DKIM, etc. all try to do). In that vein, I provide properly formatted and detailed REJECT messages (so that a user might know why I rejected him as a sender), but I do NOT provide BOUNCE messages. The difference? - a REJECT is a reply back to the original *sende
Re: [qmailtoaster] Re: to catch all or no
Il 19/05/2014 23:26, Angus McIntyre ha scritto: Tonix - Antonio Nati wrote: About deleting all email for not existing users, I consider it a bad service to customers, as they have legitimate raports with business partners, and if someone writes to the wrong address it is correct and ethical to report them back that address is wrong, so they can use another way to contact the recipient, instead of waiting for never coming reply messages. I take your point, but the volume of attempted deliveries to non-existent addresses is increasing continuously. Some of the domains I manage each receive messages daily sent to literally hundreds if not thousands of addresses that do not exist and have never existed. Sometimes the bogus addresses are clearly the result of bad de-munging by spamlist generators. For example, if you have a real address 'system-reports@', the spammer might try to send to 'reports@', having mistakenly stripped off the first part. I've also seen attempts to deliver to what were obviously once message IDs that have somehow been scraped up by spammers and added to a list under the impression that they were email addresses. Then there are the spammers who permute real addresses (i.e. if you have someuser@, they might create a fake sender address of 'xyzsomeuser@') and these get fed back into the address collectors as well. And some just seem to be invented by combining random characters. If you bounce all these, then you will generate huge amounts of email, much of it going back to real users whose addresses have been forged in the 'From' line of the spam message. Reject at SMTP level is the best practise, no traffic involved, and the email remain in charge of the sending server. SPF should help avoiding emails to real recipients from forged senders. More, the abuse of deletion and missing respect for RFC forces users to ask always for delivery and read receipt, incrementing the volume of useless emails. I don't like read receipts, but I think the volume of worthless mail generated is a fraction of what you'd get if you bounce every message to a non-existent user. Again, why do you bounce it instead of stopping it at SMTP level? Regards, Tonino Of course, I have to admit that the spammers who are targeting these nonsense addresses are more likely than others to be rejected at connection time by spamdyke's RDNS checks or SaneSecurity, so maybe the bounce volume would be smaller than I expect. Still, the potential is there. Angus - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: to catch all or no
Tonix - Antonio Nati wrote: > About deleting all email for not existing users, I consider it a bad > service to customers, as they have legitimate raports with business > partners, and if someone writes to the wrong address it is correct and > ethical to report them back that address is wrong, so they can use > another way to contact the recipient, instead of waiting for never > coming reply messages. I take your point, but the volume of attempted deliveries to non-existent addresses is increasing continuously. Some of the domains I manage each receive messages daily sent to literally hundreds if not thousands of addresses that do not exist and have never existed. Sometimes the bogus addresses are clearly the result of bad de-munging by spamlist generators. For example, if you have a real address 'system-reports@', the spammer might try to send to 'reports@', having mistakenly stripped off the first part. I've also seen attempts to deliver to what were obviously once message IDs that have somehow been scraped up by spammers and added to a list under the impression that they were email addresses. Then there are the spammers who permute real addresses (i.e. if you have someuser@, they might create a fake sender address of 'xyzsomeuser@') and these get fed back into the address collectors as well. And some just seem to be invented by combining random characters. If you bounce all these, then you will generate huge amounts of email, much of it going back to real users whose addresses have been forged in the 'From' line of the spam message. > More, the abuse of deletion and missing respect for RFC forces users to > ask always for delivery and read receipt, incrementing the volume of > useless emails. I don't like read receipts, but I think the volume of worthless mail generated is a fraction of what you'd get if you bounce every message to a non-existent user. Of course, I have to admit that the spammers who are targeting these nonsense addresses are more likely than others to be rejected at connection time by spamdyke's RDNS checks or SaneSecurity, so maybe the bounce volume would be smaller than I expect. Still, the potential is there. Angus - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: to catch all or no
Strange, I have an opposite opinion on the most of catch-all and delete usage I'm reading here in this thread. Personally, and as provider of email business, I consider catch-all account useful only when you have a new domain, and customer does not know which mailboxes were running. So you set up a catchall account and start creating all necessary accounts, and stop catch-all when the most of accounts are created. About deleting all email for not existing users, I consider it a bad service to customers, as they have legitimate raports with business partners, and if someone writes to the wrong address it is correct and ethical to report them back that address is wrong, so they can use another way to contact the recipient, instead of waiting for never coming reply messages. More, the abuse of deletion and missing respect for RFC forces users to ask always for delivery and read receipt, incrementing the volume of useless emails. About signing headers with authenticating sender address, is a must because it makes senders responsable for what they are sending, and the most of our business customers wants their domain to be used only for legitimate emails, Of course other opinions may be based on different needs, but I think respect of RFC should always be at first place, otherwise people will look soon for other stable and reliable message delivery methods. Something I think often about: as email providers, we should look like real postmen: we cannot read (intentionally I mean), lose, damage others emails. Virus and SPAM must be fought, and apart real viruses and real spam all the remaining MUST be delivered. Any not valid damage or loss could be legally pursued. Regards, Tonino Il 19/05/2014 21:10, Eric Shubert ha scritto: On 05/19/2014 08:06 AM, Jim Shupert wrote: How might one do - have a DELETE rule for badly addressed messages. I just drop them and forget about it? is it as easy as: " Set catchall email deleted " from admin in truth ... i thought you HAD to have a catch all account -- yes - i would rather not. thanks Personally, I use a catchall account for my domain, and I don't get very much spam there at all. I do a few use a few tools for mitigating this. 1) the badmailto file can specify addresses with a regex. So for example, if your domain accounts don't contain numbers or whatever special characters, or your accounts always follow a certain pattern, you can write badmailto rules to reject these attempts. I used to get a lot of spam with numbers in the account name, and eliminated them witha few badmailto rules. This file can also be used to reject messages to defunct accounts. 2) use spamdyke to blacklist local domains. This seems counter intuitive, but so long as legit users always authenticate and only send email via your server, this works nicely. That being said, I can see where some domains would want to simply delete these messages. While deleting messages goes against the RFCs, doing so certainly appears to be a best practice. Some rules, while well intended, have unintended consequences. I think this is one such rule. also that strategy of : " giving each user a separate mailbox name and e-mail address " yes , that is interesting -- I can see how that would work unfortunately in my current situation folks already have the "configuration " that we have. but maybe for a new bunch of folks a new domain This is a most excellent method of managing user accounts. I've considered doing this, but haven't actually implemented it yet. Along these lines, I've also considered modifying the header record qmail adds so that the authentication account isn't listed in its entirety. This would help to protect the actual account name. thanks for the food for thought ,,, a hardy meal. jim Thanks as well. -- Inter@zioniInterazioni di Antonio Nati http://www.interazioni.it to...@interazioni.it - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
[qmailtoaster] Re: to catch all or no
On 05/19/2014 08:06 AM, Jim Shupert wrote: How might one do - have a DELETE rule for badly addressed messages. I just drop them and forget about it? is it as easy as: " Set catchall email deleted " from admin in truth ... i thought you HAD to have a catch all account -- yes - i would rather not. thanks Personally, I use a catchall account for my domain, and I don't get very much spam there at all. I do a few use a few tools for mitigating this. 1) the badmailto file can specify addresses with a regex. So for example, if your domain accounts don't contain numbers or whatever special characters, or your accounts always follow a certain pattern, you can write badmailto rules to reject these attempts. I used to get a lot of spam with numbers in the account name, and eliminated them witha few badmailto rules. This file can also be used to reject messages to defunct accounts. 2) use spamdyke to blacklist local domains. This seems counter intuitive, but so long as legit users always authenticate and only send email via your server, this works nicely. That being said, I can see where some domains would want to simply delete these messages. While deleting messages goes against the RFCs, doing so certainly appears to be a best practice. Some rules, while well intended, have unintended consequences. I think this is one such rule. also that strategy of : " giving each user a separate mailbox name and e-mail address " yes , that is interesting -- I can see how that would work unfortunately in my current situation folks already have the "configuration " that we have. but maybe for a new bunch of folks a new domain This is a most excellent method of managing user accounts. I've considered doing this, but haven't actually implemented it yet. Along these lines, I've also considered modifying the header record qmail adds so that the authentication account isn't listed in its entirety. This would help to protect the actual account name. thanks for the food for thought ,,, a hardy meal. jim Thanks as well. -- -Eric 'shubes' On 5/19/2014 10:28 AM, Dan McAllister wrote: Jim, Exactly why do you want/need a catchall account at all? Albeit, while that is far better than having a REJECT rule for badly addressed messages, it also creates an ongoing headache of someone having to scan through tons of messages that you KNOW are most likely SPAM. First, some background -- you can do 3 things with badly addressed mail messages in QMail: - reject them - send them to a catchall account - delete them Personally, all of my servers have a DELETE rule for badly addressed messages. I just drop them and forget about it. First, most new admins want to use a REJECT option -- tell users they got a bad email address. This is the WORST option, however! Because of address phishing, you will get many times more SPAM than otherwise if you send REJECT messages. Why? Spammers will send 100,000 messages to your server addressed to a...@domain.com, a...@domain.com a...@domain.com... and so forth (usually, it is actually a dictionary/name attack more than a brute-force attack, but you get the idea). Their goal is to send you 100,000 emails and get only 99,998 bounce messages -- and voila! They have 2 "good" email addresses they can add to their "list of proven good addresses" that they sell to other spammers. Just having a domain that is "searchable" that way will increase your SPAM attacks many-fold! So accept EVERYTHING (they'll stop phishing when they realize you NEVER reject a message due to a bad address!) That leaves 2 options: - keep the bad messages, or - just silently delete them In my book, I delete them. If you WANT to read through hundreds (or thousands) of messages that are nearly always SPAM, that's your business... but there are other ways to determine that a badly addressed message was attempted -- like that the recipient never got it! === One last tidbit for security: A lot of us are essentially lazy when it comes to accounts for email. Consider this: if your email address is your login ID, then a hacker only needs to know your password to break in! Consider instead, giving each user a separate mailbox name and e-mail address: a...@gunsnroses.com is just the email address... it actually is an alias (forward in QMT) for the mailbox axyl...@gunsnroses.com. Axyl needs to know the mailbox name when he sets up his mail clients (or uses webmail), but other than that, everyone uses axyl@ as the email address. When an "attacker" wants to break into the mail server for gunsnroses.com, they can use the name a...@gunsnroses.com until the cows come back from the moon -- but it'll never work, because that isn't a valid account. FWIW: for my corporate accounts, I create a mailbox name (I won't disclose the formula), and then forwards for the actual user in the form of: fi...@domain.com, fl...@domain.com, f.l...@domain.com, firstl...@domain.com, & first.l...@domain.com (although first@ is
