Anyone know how to block emails such as the following: Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210] The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet). -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken Schneider wrote:
Anyone know how to block emails such as the following:
Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210]
The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet). Perhaps the mynetworks variable. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
On Sun, 2005-03-20 at 23:19 -0500, Ken Schneider wrote:
Anyone know how to block emails such as the following:
Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210]
The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet).
To answer my own question, found the solution using webmin to configure postfix. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
* Ken Schneider <suse-list@bout-tyme.net> [03-20-05 23:46]:
To answer my own question, found the solution using webmin to configure postfix.
And that solution was ????? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery
From: "Patrick Shanahan" <ptilopteri@gmail.com>
* Ken Schneider <suse-list@bout-tyme.net> [03-20-05 23:46]:
To answer my own question, found the solution using webmin to configure postfix.
And that solution was ????? --
Hiss........... He took the easy way out with the GUI, no one will every know..... -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
On Mon, 2005-03-21 at 17:40 -0500, Patrick Shanahan wrote:
* Ken Schneider <suse-list@bout-tyme.net> [03-20-05 23:46]:
To answer my own question, found the solution using webmin to configure postfix.
And that solution was ?????
reject_unknown_client in the server settings for Restrictions on client hostnames/addresses -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Mon, 2005-03-21 at 18:12 -0500, Ken Schneider wrote:
On Mon, 2005-03-21 at 17:40 -0500, Patrick Shanahan wrote:
* Ken Schneider <suse-list@bout-tyme.net> [03-20-05 23:46]:
To answer my own question, found the solution using webmin to configure postfix.
And that solution was ?????
reject_unknown_client in the server settings for Restrictions on client hostnames/addresses
Looking into the main.cf file: smtpd_client_restrictions = reject_unknown_client -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Ken Schneider wrote:
reject_unknown_client in the server settings for Restrictions on client hostnames/addresses
You'll be surprised how many perfectly legit (i.e. non-spam) businesses have mail-servers with IP-addresses without reverse mapping. Well, I certainly was when I tried reject_unknown_client. /Per Jessen, Zürich
On Tue, 2005-03-22 at 13:47 +0100, Per Jessen wrote:
Ken Schneider wrote:
reject_unknown_client in the server settings for Restrictions on client hostnames/addresses
You'll be surprised how many perfectly legit (i.e. non-spam) businesses have mail-servers with IP-addresses without reverse mapping. Well, I certainly was when I tried reject_unknown_client.
This is my home system so I am not to concerned, main concern is to cut back on spam (before it goes to spamassassin) and it is working. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Quoting Ken Schneider <suse-list@bout-tyme.net>:
On Tue, 2005-03-22 at 13:47 +0100, Per Jessen wrote:
Ken Schneider wrote:
reject_unknown_client in the server settings for Restrictions on client hostnames/addresses
You'll be surprised how many perfectly legit (i.e. non-spam) businesses have mail-servers with IP-addresses without reverse mapping. Well, I certainly was when I tried reject_unknown_client.
This is my home system so I am not to concerned, main concern is to cut back on spam (before it goes to spamassassin) and it is working.
Hey, if that's what you want, just turn off the mail server. Guaranteed zero spam. Coming to an INBOX near you, Real Soon Now (TM). ;} Jeffrey
On Tue, 2005-03-22 at 18:42 -0600, Jeffrey L. Taylor wrote:
Quoting Ken Schneider <suse-list@bout-tyme.net>:
You'll be surprised how many perfectly legit (i.e. non-spam) businesses have mail-servers with IP-addresses without reverse mapping. Well, I certainly was when I tried reject_unknown_client.
This is my home system so I am not to concerned, main concern is to cut back on spam (before it goes to spamassassin) and it is working.
Hey, if that's what you want, just turn off the mail server. Guaranteed zero spam. Coming to an INBOX near you, Real Soon Now (TM).
Oh you are so helpfull. I have a better suggestion for your type of help, it's call /dev/null. This is my home system that sees very little traffic but is starting to see more and more spam and I just want to try and nip it in the bud so to speak. Traffic that I want to see has entries in the config to allow that through. Here's one for you, why not turn off your PC permanently and never ever have to deal with any virii/worms. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
The Tuesday 2005-03-22 at 08:18 -0500, Ken Schneider wrote:
You'll be surprised how many perfectly legit (i.e. non-spam) businesses have mail-servers with IP-addresses without reverse mapping. Well, I certainly was when I tried reject_unknown_client.
This is my home system so I am not to concerned, main concern is to cut back on spam (before it goes to spamassassin) and it is working.
You might as well power off your computer, and revert to surface mail, in line with Jeffrey comment. You will be rejecting a lot of legitimate servers, bussiness and private, and users like me. One of the mail accounts I use doesn't have reverse dns, simply because the domain was not bought trough the ISP, and the ISP refuses to adjust reverse mapping (probably till you pay them extra, and maybe even if you do). -- Cheers, Carlos Robinson
On Wed, 2005-03-23 at 02:37 +0100, Carlos E. R. wrote:
You might as well power off your computer, and revert to surface mail, in line with Jeffrey comment.
You will be rejecting a lot of legitimate servers, bussiness and private, and users like me. One of the mail accounts I use doesn't have reverse dns, simply because the domain was not bought trough the ISP, and the ISP refuses to adjust reverse mapping (probably till you pay them extra, and maybe even if you do).
Why don't we all turn off our computers, go back in time 25 years and then no virii, no worms except for fishing for fish -not someone's personal info, Our children and grandkids will learn more in school, get rid of calculators in school so they can also learn how to add 2+2... The point is as I pointed out before is this is my home PC with my own domain that I only use for very few emails and I (not inferring everyone) don't care if some email gets missed, I have another address from my ISP I use for all other email (Earthlink with their -full- spamblocker setting which blocks 100% of addresses not in the address book). And the reverse DNS just needs something in the name even if it only maps to a name provided by your ISP and doesn't match what you provide, it will only block IP's that have nothing in the reverse lookup. If you want to test it send an email to my list address and see if it goes through. If I am wrong I am wrong and so be it. But then that is how we learn is it not, by our mistakes? -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
The Tuesday 2005-03-22 at 22:39 -0500, Ken Schneider wrote:
The point is as I pointed out before is this is my home PC with my own domain that I only use for very few emails and I (not inferring
I prefer to get used to good habits at home ;-)
everyone) don't care if some email gets missed, I have another address from my ISP I use for all other email (Earthlink with their -full- spamblocker setting which blocks 100% of addresses not in the address book). And the reverse DNS just needs something in the name even if it only maps to a name provided by your ISP and doesn't match what you provide, it will only block IP's that have nothing in the reverse lookup.
Ah, if that is so, then I have no objection. I thought it needed a reverse mapping matching the given domain.
If you want to test it send an email to my list address and see if it goes through. If I am wrong I am wrong and so be it. But then that is how we learn is it not, by our mistakes?
Correct :-) -- Cheers, Carlos Robinson
On Wednesday 23 March 2005 12:24, Carlos E. R. wrote:
everyone) don't care if some email gets missed, I have another address from my ISP I use for all other email (Earthlink with their -full- spamblocker setting which blocks 100% of addresses not in the address book). And the reverse DNS just needs something in the name even if it only maps to a name provided by your ISP and doesn't match what you provide, it will only block IP's that have nothing in the reverse lookup.
Ah, if that is so, then I have no objection. I thought it needed a reverse mapping matching the given domain.
This is dependant on who you are trying to send to... some domains will block mail if the forward and reverse don't match. Just an FYI.
If you want to test it send an email to my list address and see if it goes through. If I am wrong I am wrong and so be it. But then that is how we learn is it not, by our mistakes?
Correct :-)
-- Cheers, Carlos Robinson
On Wed, 2005-03-23 at 13:49 -0800, Herman Knief wrote:
On Wednesday 23 March 2005 12:24, Carlos E. R. wrote:
Ah, if that is so, then I have no objection. I thought it needed a reverse mapping matching the given domain.
This is dependant on who you are trying to send to... some domains will block mail if the forward and reverse don't match. Just an FYI.
Yes some do that but as I originally posted I was looking for something to block "unknown" connections which is produced from servers that don't resolve to a "host" in DNS, just resolving to a domain is not enough. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Wed, 2005-03-23 at 21:24 +0100, Carlos E. R. wrote:
The Tuesday 2005-03-22 at 22:39 -0500, Ken Schneider wrote:
The point is as I pointed out before is this is my home PC with my own domain that I only use for very few emails and I (not inferring
I prefer to get used to good habits at home ;-)
Yes good habits are good. As I said I only use this for home experimental use and only use it for a few mailing lists to see which ones get used by spammers.
everyone) don't care if some email gets missed, I have another address from my ISP I use for all other email (Earthlink with their -full- spamblocker setting which blocks 100% of addresses not in the address book). And the reverse DNS just needs something in the name even if it only maps to a name provided by your ISP and doesn't match what you provide, it will only block IP's that have nothing in the reverse lookup.
Ah, if that is so, then I have no objection. I thought it needed a reverse mapping matching the given domain.
After further checking the only email that will fall under this are ones that don't properly resolve the IP address to a host. Even if they resolve to some-domain.com(or net or whatever) the IP must resolve to a host name or else postfix reports unknown. Cheers, -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
Quoting Ken Schneider <suse-list@bout-tyme.net>: [snip]
If you want to test it send an email to my list address and see if it goes through. If I am wrong I am wrong and so be it. But then that is how we learn is it not, by our mistakes?
Uh, by another's mistakes? Jeffrey
Quoting Ken Schneider <suse-list@bout-tyme.net>:
Anyone know how to block emails such as the following:
Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210]
The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet).
Doing this will lose legitimate mail. I have been running my own mail server for three years and am surprised at how many badly configured servers there are out there. Even for big tech companies. I suggest you add warn_if_reject before the reject_unknown_hostname at first. If after a month, it hasn't had a false positive, then make it real. Below is what I use. Commented out lines are ones that produced unacceptable number of false positives, or no true positives. This set is now stable, so I should remove all the warn_if_reject lines. They have proven their uselessness by now. # UCE controls # smptd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/maps/client_access warn_if_reject reject_rbl_client bl.spamcop.net, warn_if_reject reject_rbl_client relays.ordb.org, warn_if_reject reject_rbl_client sbl.spamhaus.org, warn_if_reject reject_rbl_client proxies.relays.monkeys.com smtpd_helo_required=yes smtpd_helo_restrictions = permit_mynetworks check_helo_access hash:/etc/postfix/maps/helo_access warn_if_reject reject_invalid_hostname warn_if_reject reject_non_fqdn_hostname warn_if_reject reject_unauth_pipelining, # warn_if_reject reject_unknown_hostname, warn_if_reject reject_unauth_destination permit # removed reject_unauth_destination as 2nd to last restriction (2/26/03) smtpd_sender_restrictions = permit_mynetworks, check_sender_access hash:/etc/postfix/maps/sender_access reject_non_fqdn_sender, reject_unknown_sender_domain, # warn_if_reject reject_rhsbl_sender dsn.rfc-ignorant.org, permit smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, # check_recipient_access hash:/etc/postfix/maps/recipient_access, # reject_multi_recipient_bounce, reject_non_fqdn_recipient, warn_if_reject reject_unknown_recipient_domain, reject_unauth_destination
On Sunday 20 March 2005 11:18 pm, Jeffrey L. Taylor wrote:
Quoting Ken Schneider <suse-list@bout-tyme.net>:
Anyone know how to block emails such as the following:
Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210]
The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet).
Doing this will lose legitimate mail. I have been running my own mail server for three years and am surprised at how many badly configured servers there are out there. Even for big tech companies.
You mean this "may" lose legitimite email, not it "will". I've blocked unresolvable hosts at home for better than 5 years, and have not missed anything. By that I mean that I've received all email that was expected, and have not received any letters or phone calls informing me of rejected email (either destined to me, or to one of the users there). :) The same thing applies at work, but for just under 5 years.
I suggest you add warn_if_reject before the reject_unknown_hostname at first. If after a month, it hasn't had a false positive, then make it real. Below is what I use.
warn_if_reject reject_unknown_recipient_domain,
Why would you ever have to warn about rejecting unknown recipient domains? Did you expect to receive mail to domains that your mail server couldn't resolve, or send mail to similarly unresolvable domains? :) BTW, you could save a couple of lines in your rules by removing the "permit" as the last rule. It's redundant. --Danny
Quoting Danny Sauer <suse-linux-e.suselists@danny.teleologic.net>: [snip]
warn_if_reject reject_unknown_recipient_domain,
Why would you ever have to warn about rejecting unknown recipient domains? Did you expect to receive mail to domains that your mail server couldn't resolve, or send mail to similarly unresolvable domains? :)
I would like to know what I am about to reject before I actually start throwing mail in the trash sight unseen. Note: pogo.bearhouse.lan is a host name that is legitimate in MY system. If the wrong DNS server is being used to resolve addresses, it will be unknown. Any messages from it are likely to be critical. The bottom line is that I do not know the effect of all my restrictions before I try them out. The results of some have been surprising. I would rather look at a few extra e-mails in the possible spam folder than lose a message. There are messages that have been flagged as possible spam that were critical to my business and/or the health of my systems. Having them silently discarded would have cost me significant money. Jeffrey
On Friday 25 March 2005 04:44 pm, Jeffrey L. Taylor wrote:
Quoting Danny Sauer <suse-linux-e.suselists@danny.teleologic.net>: [snip]
warn_if_reject reject_unknown_recipient_domain,
Why would you ever have to warn about rejecting unknown recipient domains? Did you expect to receive mail to domains that your mail server couldn't resolve, or send mail to similarly unresolvable domains? :)
Note smilie. It's frequently used to denote something intended to be interpreted as kidding, ribbing, a joke, in good humor, etc. There was some truth to it, though, so I'll share the reasoning.
I would like to know what I am about to reject before I actually start throwing mail in the trash sight unseen. Note: pogo.bearhouse.lan is a host name that is legitimate in MY system. If the wrong DNS server is being used to resolve addresses, it will be unknown. Any messages from it are likely to be critical.
Unknown hostname messages are rejected with a 4xx error, which means "temporarily failure, try again later" (unless you've foolishly changed that setting). You'd probably notice if your DNS didn't work for more than 5 days, and the deferred message will be accepted once DNS is fixed. Either way, a message won't be discarded for a DNS error until the remote mail host has decided to stop trying, which is generally after 5 days, minimum, and even then, it's bounced by the remote host, not yours. More specifically, you should not be using DNS to determine 1) the local recipients (those are defined in postfix config files) or 2) relay domains (also defined in a config file). So, locally-destined messages are unaffected by DNS problems. Messages *from* local machines are explicitly allowed by permit_mynetworks, which is a short-circuit that skips the remaining rules. Therefore, the restriction won't ever apply to locally-originating mail or locally-destined mail. Knowing how it works gives you 100% assurance of that. Before reading that, you were just "pretty sure" that everything was alright, since random testing hadn't shown up a problem yet. Hooray for knowledge!
The bottom line is that I do not know the effect of all my restrictions before I try them out. The results of some have been surprising. I would rather look at a few extra e-mails in the possible spam folder than lose a message. There are messages that have been flagged as possible spam that were critical to my business and/or the health of my systems. Having them silently discarded would have cost me significant money.
Then it might be worth the time to learn about them, rather than blindly experimenting. If you don't know what they're doing, then how do you know that you've tested long enough? What if that million-dollar email comes through a few days after you've arbitrarily decided that testing is "good enough"? Testing on random messages - which may or may not be representative of all possibilities - for an arbitrary amount of time does not replace learning exactly what it is that you're doing. It may be that, in some cases, the testing is probably "good enough", but it doesn't sound like "probably good enough" is the goal. The only way to get the absolute reliability that you're after is to 1) learn exactly what's happening and 2) test with a defined set of messages that should pass and should fail. That's what the X-client capability is intended for - *structured* testing to be sure that your understanding is correct. --Danny, not limiting this point of view to SMTP, or even computers
Quoting Danny Sauer <suse-linux-e.suselists@danny.teleologic.net>:
On Friday 25 March 2005 04:44 pm, Jeffrey L. Taylor wrote:
Quoting Danny Sauer <suse-linux-e.suselists@danny.teleologic.net>: [snip]
warn_if_reject reject_unknown_recipient_domain,
Why would you ever have to warn about rejecting unknown recipient domains? Did you expect to receive mail to domains that your mail server couldn't resolve, or send mail to similarly unresolvable domains? :)
Note smilie. It's frequently used to denote something intended to be interpreted as kidding, ribbing, a joke, in good humor, etc. There was some truth to it, though, so I'll share the reasoning.
I would like to know what I am about to reject before I actually start throwing mail in the trash sight unseen. Note: pogo.bearhouse.lan is a host name that is legitimate in MY system. If the wrong DNS server is being used to resolve addresses, it will be unknown. Any messages from it are likely to be critical.
Unknown hostname messages are rejected with a 4xx error, which means "temporarily failure, try again later" (unless you've foolishly changed that setting). You'd probably notice if your DNS didn't work for more than 5 days, and the deferred message will be accepted once DNS is fixed. Either way, a message won't be discarded for a DNS error until the remote mail host has decided to stop trying, which is generally after 5 days, minimum, and even then, it's bounced by the remote host, not yours.
More specifically, you should not be using DNS to determine 1) the local recipients (those are defined in postfix config files) or 2) relay domains (also defined in a config file). So, locally-destined messages are unaffected by DNS problems. Messages *from* local machines are explicitly allowed by permit_mynetworks, which is a short-circuit that skips the remaining rules. Therefore, the restriction won't ever apply to locally-originating mail or locally-destined mail. Knowing how it works gives you 100% assurance of that. Before reading that, you were just "pretty sure" that everything was alright, since random testing hadn't shown up a problem yet. Hooray for knowledge!
The bottom line is that I do not know the effect of all my restrictions before I try them out. The results of some have been surprising. I would rather look at a few extra e-mails in the possible spam folder than lose a message. There are messages that have been flagged as possible spam that were critical to my business and/or the health of my systems. Having them silently discarded would have cost me significant money.
Then it might be worth the time to learn about them, rather than blindly experimenting. If you don't know what they're doing, then how do you know that you've tested long enough? What if that million-dollar email comes through a few days after you've arbitrarily decided that testing is "good enough"? Testing on random messages - which may or may not be representative of all possibilities - for an arbitrary amount of time does not replace learning exactly what it is that you're doing. It may be that, in some cases, the testing is probably "good enough", but it doesn't sound like "probably good enough" is the goal.
The only way to get the absolute reliability that you're after is to 1) learn exactly what's happening and 2) test with a defined set of messages that should pass and should fail. That's what the X-client capability is intended for - *structured* testing to be sure that your understanding is correct.
From smtpunit.sourceunit.net:
SmtpUnit is a smtp server written in java to be used for unit testing java code within a enterprise level or stand alone java application to test code that results in an email being sent. Not useful. The Postfix documentation is a bit terse at times. It is frequently best to test your interpretation before commiting to it. Oh, and a bounce message 5 days late for a message indicating a computer is severely over temperature is kind of useless. Jeffrey
On Saturday 26 March 2005 01:13 am, Jeffrey L. Taylor wrote:
Quoting Danny Sauer <suse-linux-e.suselists@danny.teleologic.net>: [...]
The only way to get the absolute reliability that you're after is to 1) learn exactly what's happening and 2) test with a defined set of messages that should pass and should fail. That's what the X-client capability is intended for - *structured* testing to be sure that your understanding is correct.
From smtpunit.sourceunit.net:
SmtpUnit is a smtp server written in java to be used for unit testing java code within a enterprise level or stand alone java application to test code that results in an email being sent.
Not useful.
What? I don't think emacs is useful, either. What does that have to do with anything, other than both can send email? If you're referring to the XCLIENT thing, this might help: http://www.postfix.org/XCLIENT_README.html
The Postfix documentation is a bit terse at times. It is frequently best to test your interpretation before commiting to it.
Yes, but that's [part of] learning how it works and then making sure you didn't make a mistake. It's not "I don't know what this does, so I'll test it for a while to see if it's OK". One is a good policy, the other's rather questionable. From the original message, it *sounded* like you were using the "questionable" policy.
Oh, and a bounce message 5 days late for a message indicating a computer is severely over temperature is kind of useless.
A mail server set up to reject mail from trusted internal hosts is kind of useless, too - that's what permit_mynetworks is for. :) --Danny, whose machines would probably overheat at 3AM when he'd miss the message anyway :(
Ken, If you're up to it, you could try out the FairUCE software IBM just announced. You meet the key requirements: Linux, Postfix and Apache (I assum). Also required are Java and SSL for Apache, but they're readily available to you if you don't already have them installed. FairUCE is at: <http://www.alphaworks.ibm.com/tech/fairuce/> If you decide to give it a try, please let us know how it goes. Randall Schulz On Sunday 20 March 2005 20:19, Ken Schneider wrote:
Anyone know how to block emails such as the following:
...
-- Ken Schneider
On Sunday 20 March 2005 10:19 pm, Ken Schneider wrote:
Anyone know how to block emails such as the following:
Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210]
The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet).
I know you solved the problem already, but this might be a good time to suggest reading over the docs at www.postfix.org. :) http://www.postfix.org/documentation.html indexes a lot of good stuff, and you're probably specifically interested in "Relay/access control overview", with "Address verification" and "Stopping backscatter mail" being handy reads if you're feeling a tad more aggressive. Using the address verification stuff has worked out well for me over the last 6 months or so since I implemented it - both internally as a way to save some bandwidth / queue processing time on my backup mail server (it verifies recipient addresses on the main MX before accepting messages), and as externally as a way to reject those made-up hotmail/yahoo addresses (verify the sender's address validity before accepting the message). You might also consider looking over the postconf man page - at http://www.postfix.org/postconf.5.html as well as under "man postconf". Normally I'm not big on just reading docs for the hell of it, but this one's a decent read, and it'll give you an idea of what postfix can do. I find that helpful when trying to solve a problem - often I'll recall "wasn't there something similar in that doc I read a while back?" --Danny, who likes postfix largely because it's so well documented
On Fri, 2005-03-25 at 08:44 -0600, Danny Sauer wrote:
On Sunday 20 March 2005 10:19 pm, Ken Schneider wrote: I know you solved the problem already, but this might be a good time to suggest reading over the docs at www.postfix.org. :)
http://www.postfix.org/documentation.html indexes a lot of good stuff, and you're probably specifically interested in "Relay/access control overview", Not an open relay.
with "Address verification" Looks interesting and may be more to what I am looking for but not fool
I guess you have not read the rest of the thread yet. proof.
and "Stopping backscatter mail" being handy reads if you're feeling a tad more aggressive. Using the address verification stuff has worked out well for me over the last 6 months or so since I implemented it - both internally as a way to save some bandwidth / queue processing time on my backup mail server (it verifies recipient addresses on the main MX before accepting messages), and as externally as a way to reject those made-up hotmail/yahoo addresses (verify the sender's address validity before accepting the message).
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 * Only reply to the list please* "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Friday 25 March 2005 08:46 am, Ken Schneider wrote:
On Fri, 2005-03-25 at 08:44 -0600, Danny Sauer wrote:
On Sunday 20 March 2005 10:19 pm, Ken Schneider wrote: I know you solved the problem already, but this might be a good time to suggest reading over the docs at www.postfix.org. :)
I guess you have not read the rest of the thread yet.
Not in detail, no. I saw "how do I solve this" and "it's solved via webmin, here's what webmin changed", and then just glanced at most of the "but you'll reject valid email! You're crazy!". This wasn't supposed to be a "RTFM, idiot" post, but rather one that notes docs you might have missed otherwise.
http://www.postfix.org/documentation.html indexes a lot of good stuff, and you're probably specifically interested in "Relay/access control overview",
Not an open relay.
Access control = controlling access to your mail server. That includes rejecting spam. There used to be a separate UCE section up there, but that got merged in with the access control stuff because it's technically access control. :)
with "Address verification"
Looks interesting and may be more to what I am looking for but not fool proof.
It's not, but with SMTP every little bit helps. :) --Danny
On Friday 25 March 2005 05:44 am, Danny Sauer wrote:
On Sunday 20 March 2005 10:19 pm, Ken Schneider wrote:
Anyone know how to block emails such as the following:
Mar 20 21:01:19 pc1 postfix/smtpd[8376]: connect from unknown[85.95.64.210] Mar 20 21:01:21 pc1 postfix/smtpd[8376]: 65F9CC6F2AD: client=unknown[85.95.64.210]
The connect from unknown is what I want blocked, not necessarily this address (although I have blocked this subnet).
I know you solved the problem already, but this might be a good time to suggest reading over the docs at www.postfix.org. :)
http://www.postfix.org/documentation.html indexes a lot of good stuff, and you're probably specifically interested in "Relay/access control overview", with "Address verification" and "Stopping backscatter mail" being handy reads if you're feeling a tad more aggressive.
Bringing this back on the topic of SuSE Linux... It should be pointed out that the Yast2 Installation and configuration of Postfix ENABLES RELAYING BY DEFAULT, and it offers NO ability to turn this off. You have to dig into the postfix settings and wade thru the postfix clear as mud documentation on their site. This happened to me on a brand new SuSE 9.1 install. For me, it was much quicker to fire up yast, de-install postfix and install sendmail, than it was to try to wade through the docs on postfix with terms that are never defined, examples that don't work, and a default install that is hopelessly vulnerable. This is a SuSE issue, they should not install postfix as an open relay. They don't install sendmail as an open relay. Whats up with that? -- _____________________________________ John Andersen
John Andersen wrote:
Bringing this back on the topic of SuSE Linux...
It should be pointed out that the Yast2 Installation and configuration of Postfix ENABLES RELAYING BY DEFAULT, and it offers NO ability to turn this off. You have to dig into the postfix settings and wade thru the postfix clear as mud documentation on their site.
Uh, I don't know how you managed to come to that conclusion. The default installation of Postfix is to listen to localhost only and allow only localhost to send mails. That is a bit different from what you describe. Anything else is something you define, whether it is through yast or by editing the config files. You probably misunderstood something when you configured the system. Sandy
On Saturday 26 March 2005 12:35 pm, Sandy Drobic wrote:
John Andersen wrote:
Bringing this back on the topic of SuSE Linux...
It should be pointed out that the Yast2 Installation and configuration of Postfix ENABLES RELAYING BY DEFAULT, and it offers NO ability to turn this off. You have to dig into the postfix settings and wade thru the postfix clear as mud documentation on their site.
Uh, I don't know how you managed to come to that conclusion. The default installation of Postfix is to listen to localhost only and allow only localhost to send mails. That is a bit different from what you describe. Anything else is something you define, whether it is through yast or by editing the config files.
You probably misunderstood something when you configured the system.
Quite possible, since I've only been using Linux for 10 years. However, if you go back and try it on a new machine (not likely, I know) and check the box in yast that says you will accept remote connections, you will find you have an open relay. Since you don't need an MTA at all if you were planning to pop your mail, this seems to be totally wrong headed way to do it. And, as I pointed out, its not the way Yast installs sendmail which has relaying denied. -- _____________________________________ John Andersen
John Andersen wrote:
Uh, I don't know how you managed to come to that conclusion. The default installation of Postfix is to listen to localhost only and allow only localhost to send mails. That is a bit different from what you describe. Anything else is something you define, whether it is through yast or by editing the config files.
You probably misunderstood something when you configured the system.
Quite possible, since I've only been using Linux for 10 years.
However, if you go back and try it on a new machine (not likely, I know) and check the box in yast that says you will accept remote connections, you will find you have an open relay.
That does seem a bit strange. Can't verify it at the moment, but I'll keep it in mind and try it the next time i set up a suse box. Do you need to any special format for the mail to be accepted for relaying?
Since you don't need an MTA at all if you were planning to pop your mail, this seems to be totally wrong headed way to do it. And, as I pointed out, its not the way Yast installs sendmail which has relaying denied.
Very strange indeed. Just a few days ago I installed postfix as a relay to secure a domino server that hat a problem with source routed mail messages and it works beautifully. Of course, I configured it manually by editing the config files. Sandy
On Saturday 26 March 2005 01:04 pm, Sandy Drobic wrote:
John Andersen wrote:
Uh, I don't know how you managed to come to that conclusion. The default installation of Postfix is to listen to localhost only and allow only localhost to send mails. That is a bit different from what you describe. Anything else is something you define, whether it is through yast or by editing the config files.
You probably misunderstood something when you configured the system.
Quite possible, since I've only been using Linux for 10 years.
However, if you go back and try it on a new machine (not likely, I know) and check the box in yast that says you will accept remote connections, you will find you have an open relay.
That does seem a bit strange. Can't verify it at the moment, but I'll keep it in mind and try it the next time i set up a suse box.
Do you need to any special format for the mail to be accepted for relaying?
Since you don't need an MTA at all if you were planning to pop your mail, this seems to be totally wrong headed way to do it. And, as I pointed out, its not the way Yast installs sendmail which has relaying denied.
Very strange indeed. Just a few days ago I installed postfix as a relay to secure a domino server that hat a problem with source routed mail messages and it works beautifully. Of course, I configured it manually by editing the config files.
Sandy
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3. Without the ability to set mynetworks via yast, postfix defaults mynetworks to use mynetworks-style, and THAT in turn defaults to mynetworks_style = subnet which means anyone with the same subnet can relay thru your box. In my case someone appearing to be (in reality, probably forged IP) on the same ISP was able to connect and relay. So the upshot is, that unless you know to check the main.cf, postfix will install insecurely if you accept smtp connections from remote and you configure it with Yast2. Of course this was fairly easy to dig out after the fact, but with my machine filling my bandwidth with spam I was in a big hurry to get the problem solved, and learning postfix under the barrel of a gun was mot something I wanted to do, and not something I expected to do after years of installing sendmail securely with Yast. Still, it was My-Bad for not testing the install for open relay initially. -- _____________________________________ John Andersen
John Andersen wrote:
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3.
Just peeked into my 9.2 config files. There is no access to $mynetworks in sysconfig.
Without the ability to set mynetworks via yast, postfix defaults mynetworks to use mynetworks-style, and THAT in turn defaults to mynetworks_style = subnet which means anyone with the same subnet can relay thru your box. In my case someone appearing to be (in reality, probably forged IP) on the same ISP was able to connect and relay.
Here in Europe we naturally assume you are behind a firewall and your network is a private network that's not accessible from the internet. For a host with a public ip this is indeed not acceptable. It would be a very good idea for Suse to check if the ip of the host is a public or a private ip and set relay to host/mynetwork accordingly.
So the upshot is, that unless you know to check the main.cf, postfix will install insecurely if you accept smtp connections from remote and you configure it with Yast2.
I think yast is meant to make it easier to set up an home pc, but when you set up a server you should indeed check the entire config.
Of course this was fairly easy to dig out after the fact, but with my machine filling my bandwidth with spam I was in a big hurry to get the problem solved, and learning postfix under the barrel of a gun was mot something I wanted to do, and not something I expected to do after years of installing sendmail securely with Yast.
Happens to all of us some day. (^-^) At least it is nicely documented and rather easy to configure. For me it was to secure the domino server against relaying some days ago.
Still, it was My-Bad for not testing the install for open relay initially.
You definitely need to check the installation. Just looking at the mail log will make anyone realize that who administers a public mail server. Sandy
Sandy Drobic wrote:
John Andersen wrote:
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3.
Just peeked into my 9.2 config files. There is no access to $mynetworks in sysconfig. You just need to add POSTFIX_ADD_MYNETWORKS="" to /etc/sysconfig/postfix. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
Joe Morris (NTM) wrote:
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3.
Just peeked into my 9.2 config files. There is no access to $mynetworks in sysconfig.
You just need to add POSTFIX_ADD_MYNETWORKS="" to /etc/sysconfig/postfix.
Now, that's cheating. (^-^) If you manually add it to the sysconfig file you might as well configure main.cf manually. The point was, if you configure postfix to receive mail from the network through yast you apparently don't get the hint or choice to configure mynetworks from the default config. Sandy
The Saturday 2005-03-26 at 13:37 -0900, John Andersen wrote:
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3.
Without the ability to set mynetworks via yast, postfix defaults mynetworks to use mynetworks-style, and THAT in turn defaults to mynetworks_style = subnet which means anyone with the same subnet can relay thru your box. In my case someone appearing to be (in reality, probably forged IP) on the same ISP was able to connect and relay.
So the upshot is, that unless you know to check the main.cf, postfix will install insecurely if you accept smtp connections from remote and you configure it with Yast2.
This was reported time ago in this list: |Date: 05 Sep 2003 08:58:54 -0500 |From: David Krider <david@ |To: suse-linux-e@ |Subject: [SLE] SuSE's default postfix config is an open relay? |X-Message-Number-for-archive: 158428 The recommendation at the time was to report the issue on the suse-security list. I don't know if it was, and what was the answer, if any. -- Cheers, Carlos Robinson
On Saturday 26 March 2005 05:31 pm, Carlos E. R. wrote:
So the upshot is, that unless you know to check the main.cf, postfix will install insecurely if you accept smtp connections from remote and you configure it with Yast2.
This was reported time ago in this list: |Date: 05 Sep 2003 08:58:54 -0500 |From: David Krider <david@ |To: suse-linux-e@ |Subject: [SLE] SuSE's default postfix config is an open relay? |X-Message-Number-for-archive: 158428
Right you are. Almost two years and 3 releases ago.... Still broken. -- _____________________________________ John Andersen
On Saturday 26 March 2005 10:57 pm, John Andersen wrote:
On Saturday 26 March 2005 05:31 pm, Carlos E. R. wrote:
So the upshot is, that unless you know to check the main.cf, postfix will install insecurely if you accept smtp connections from remote and you configure it with Yast2.
This was reported time ago in this list: |Date: 05 Sep 2003 08:58:54 -0500 |From: David Krider <david@ |To: suse-linux-e@ |Subject: [SLE] SuSE's default postfix config is an open relay? |X-Message-Number-for-archive: 158428
Right you are. Almost two years and 3 releases ago.... Still broken.
It's not broken - it's set up to be least restrictive. It's user friendly! --Danny
Op zaterdag 26 maart 2005 23:37, schreef John Andersen:
Sandy
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3.
I received this from the postfix maintainer:
The problem is that mynetworks does not appear in /etc/sysconfig/postfix so they have no way to set this via yast. You have to know this in advance. Perhaps it will be fixed in 9.2 or 9.3.
echo POSTFIX_ADD_MYNETWORKS_STYLE=host >> /etc/sysconfig/postfix or echo POSTFIX_ADD_MYNETWORKS_STYLE=subnet >> /etc/sysconfig/postfix or echo POSTFIX_ADD_MYNETWORKS_STYLE=class >> /etc/sysconfig/postfix and SuSEconfig -module postfix see # # POSTFIX_ADD_* # You may add any existing postfix parameter here. Just execute the # postconf command to get a complete list. You then have to uppercase # the parameter and prepend POSTFIX_ADD_. # Example: # Let's say you want to add the postfix parameter mailbox_size_limit. # Then just add # POSTFIX_ADD_MAILBOX_SIZE_LIMIT=0 # POSTFIX_ADD_MESSAGE_SIZE_LIMIT=30000000 in /etc/sysconfig/postfix
Without the ability to set mynetworks via yast, postfix defaults mynetworks to use mynetworks-style, and THAT in turn defaults to mynetworks_style = subnet which means anyone with the same subnet can relay thru your box. In my case someone appearing to be (in reality, probably forged IP) on the same ISP was able to connect and relay.
See above.
So the upshot is, that unless you know to check the main.cf, postfix will install insecurely if you accept smtp connections from remote and you configure it with Yast2.
That depends on your personal situation. I agree, that there's room for improvement.
Of course this was fairly easy to dig out after the fact, but with my machine filling my bandwidth with spam I was in a big hurry to get the problem solved, and learning postfix under the barrel of a gun was mot something I wanted to do, and not something I expected to do after years of installing sendmail securely with Yast.
I'm not aware of the fact that sendmail behaved different in the past. -- Richard Bos Without a home the journey is endless
Sat, 26 Mar 2005, by jsa@pen.homeip.net:
On Saturday 26 March 2005 12:35 pm, Sandy Drobic wrote:
John Andersen wrote:
Bringing this back on the topic of SuSE Linux...
It should be pointed out that the Yast2 Installation and configuration of Postfix ENABLES RELAYING BY DEFAULT, and it offers NO ability to turn this off. You have to dig into the postfix settings and wade thru the postfix clear as mud documentation on their site.
Uh, I don't know how you managed to come to that conclusion. The default installation of Postfix is to listen to localhost only and allow only localhost to send mails. That is a bit different from what you describe. Anything else is something you define, whether it is through yast or by editing the config files.
You probably misunderstood something when you configured the system.
Quite possible, since I've only been using Linux for 10 years.
However, if you go back and try it on a new machine (not likely, I know) and check the box in yast that says you will accept remote connections, you will find you have an open relay.
That is just *not* true. Stop spreading FUD about something you don't understand. If you like Sendmail better, fine, by all means use it, but trying to dis-inform others about Postfix or another MTA is something we (tinw) expect out of Redmond,WA, not from a Linux user.
Since you don't need an MTA at all if you were planning to pop your mail, this seems to be totally wrong headed way to do it. And, as I pointed out, its not the way Yast installs sendmail which has relaying denied.
You need at least a sendmail drop-in if you want something to accept the mail from e.g. fetchmail. And again, if you've got an open relay after installing and configuring Postfix it's your own damn fault. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info.
On Saturday 26 March 2005 03:54 pm, Theo v. Werkhoven wrote:
That is just *not* true. Stop spreading FUD about something you don't understand. If you like Sendmail better, fine, by all means use it, but trying to dis-inform others about Postfix or another MTA is something we (tinw) expect out of Redmond,WA, not from a Linux user.
Follow the thread, and you will find out it IS TRUE and has been confirmed by others. Your apology will be expected .... -- _____________________________________ John Andersen
Sat, 26 Mar 2005, by jsa@pen.homeip.net:
On Saturday 26 March 2005 03:54 pm, Theo v. Werkhoven wrote:
That is just *not* true. Stop spreading FUD about something you don't understand. If you like Sendmail better, fine, by all means use it, but trying to dis-inform others about Postfix or another MTA is something we (tinw) expect out of Redmond,WA, not from a Linux user.
Follow the thread, and you will find out it IS TRUE and has been confirmed by others.
Your apology will be expected ....
And here it is.. I read you explanation after sending my reply of course. Sorry. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info.
On Saturday 26 March 2005 04:03 pm, Theo v. Werkhoven wrote:
Sat, 26 Mar 2005, by jsa@pen.homeip.net:
On Saturday 26 March 2005 03:54 pm, Theo v. Werkhoven wrote:
That is just *not* true. Stop spreading FUD about something you don't understand. If you like Sendmail better, fine, by all means use it, but trying to dis-inform others about Postfix or another MTA is something we (tinw) expect out of Redmond,WA, not from a Linux user.
Follow the thread, and you will find out it IS TRUE and has been confirmed by others.
Your apology will be expected ....
And here it is.. I read you explanation after sending my reply of course. Sorry.
Theo
Thanks, for saying that. Many would have just run away from it. Sorry I was so confrontational. -- _____________________________________ John Andersen
participants (14)
-
Carlos E. R. -
Danny Sauer -
david rankin -
Herman Knief -
Jeffrey L. Taylor -
Joe Morris (NTM) -
John Andersen -
Ken Schneider -
Patrick Shanahan -
Per Jessen -
Randall R Schulz -
Richard Bos -
Sandy Drobic -
Theo v. Werkhoven