Re: Limitations of smtpd_proxy_filter
* Wietse Venema wie...@porcupine.org: Stefan Foerster: One of the greatest improvements in the 2.7 tree is the ability to defer transmission of received messages to a SMTP proxy until the message receiption completes (smtpd_proxy_options = speed_adjust). Can you be more specific about the benefits? Number of filters is down by more than 40%. Comparing a typical day before and after we deployed that feature: http://www.incertum.net/~cite/speed_adjust.png Other sites might not notice such a large impact: Our setup includes a large number of clients connected via lines with little bandwidth (2MBit/s) which is typically used for other purposes besides sending mail. If the time a mail transmission takes is negligible, I expect the results to be vastly different. Furthermore (I'm not 100% sure about this, would be glad if you could confirm this) it's much harder to DoS a Postfix server with that patch: Previously, all you had to do was opening a number of connections equal to the number of pre-queue content filter processes, go through the initial (E)SMTP steps and then send a mail very slowly. With smtpd_proxy_options=speed_adjust, you'd have to DoS the Postfix SMTP server itself, and between postscreen guarding it, high process limits, access control and the stress adaptive server personality, this one is well able to take care of itself. Stefan
Re: Does Postfix cache resolv.conf?
Wietse Venema: Apparently postfix missed the switching of nameservers and did not learn of the new DNS until restart. Is this a bug or a feature? Like most programs, Postfix never reads /etc/resolv.conf. Yes, I suspected that. Instead, that file is read by the NSSWITCH system library functions, and the DNS system library functions. Postfix does not run on bare metal - instead it runs on an operating system that provides libraries and other runtime support. The strange thing is that postfix apparently was the only application on that box, which was unable to resolve names after the change of DNS. Following a restart it worked fine. So it must be something running in the context of postfix, e.g. a library, which causes the problem. I just try to figure out, what postfix does differently as compared to roughly a dozen of other applications, which were subject to the same change of DNS and eventually use the same system libraries. I'm just the kind of guy, who likes to know why something is happening. Since there are a lot of applications inventing wheels (the broken bind9 apparently crashes in its self-made memory manager), knowing that postfix doesn't is a useful input. Thanks a lot. Regards, - lars.
Re: Huge active queue and system idle, not delivering
Patrick Chemla: Wietse: OK, so you can turn back on that connection caching. Note that qmail creates and destroys two processes per SMTP session, so reusing a session is also a win from a CPU resource point of view. Patrick: If I do so, will postfix open more than one connexion to each qmail for parallel deliveries? Of course. Connection caching is a performance IMPROVEMENT feature. However, some qmail implementations are patched and turn on TARPIT delays when the client sends many messages or recipients over the same SMTP connection. Wietse
Re: Sender based relay server
On Sat, January 9, 2010 5:34 pm, Stan Hoeppner wrote: Jack Knowlton put forth on 1/9/2010 9:57 AM: Hi all. Our internal postfix server relays all outbound mail thru an external host. How can I set it to use a different relay server when the email comes from a specified domain? Eg. j...@domain1.com - xxx.xxx.xxx.xxx (default), m...@domain2.com - yyy.yyy.yyy.yyy This might help ya: sender_dependent_relayhost_maps (default: empty) A sender-dependent override for the global relayhost parameter setting. The tables are searched by the envelope sender address and @domain. A lookup result of DUNNO terminates the search without overriding the global relayhost parameter setting (Postfix 2.6 and later). This information is overruled with relay_transport, sender_dependent_default_transport_maps, default_transport and with the transport(5) table. For safety reasons, this feature does not allow $number substitutions in regular expression maps. This feature is available in Postfix 2.3 and later. Thank you. I figured out how to make a per-domain relay, but what is the format for having the message directly delivered? I tried both smtp: and :smtp but none seemed to work.. -JK
Re: Anyone else had this issue with maildrop?
On Sunday 10 January 2010 14:59:11 mouss wrote: Your maildrop needs to contact the courier authdaemon server. Make sure, authdaemon is running and correctly configured. if you don't need it, you'll need to rebuild maildrop without authlib support. anyway, this is not postfix related. maildrop is part of the courier suit. you'll get more help on the courier-maildrop mailing list. Hey, but thanks, it was enough to solve my problem! (I had problems with gentoo USE flags and rebuilt manually) signature.asc Description: This is a digitally signed message part.
Re: Limitations of smtpd_proxy_filter
Stefan Foerster: * Wietse Venema wie...@porcupine.org: Stefan Foerster: One of the greatest improvements in the 2.7 tree is the ability to defer transmission of received messages to a SMTP proxy until the message receiption completes (smtpd_proxy_options = speed_adjust). Can you be more specific about the benefits? Number of filters is down by more than 40%. Comparing a typical day before and after we deployed that feature: http://www.incertum.net/~cite/speed_adjust.png As with the first public release release, Postfix avoids the need for a forklist upgrade (that was geek talk for having to install more powerful hardware). Now I can claim it as a green option. Other sites might not notice such a large impact: Our setup includes a large number of clients connected via lines with little bandwidth (2MBit/s) which is typically used for other purposes besides sending mail. If the time a mail transmission takes is negligible, I expect the results to be vastly different. It also depends on how far away the clients are: each round-trip time adds to the duration of a session (from this location near New York I measure some 90ms RTT to europe and 175ms to Japan). Furthermore (I'm not 100% sure about this, would be glad if you could confirm this) it's much harder to DoS a Postfix server with that patch: Previously, all you had to do was opening a number of connections equal to the number of pre-queue content filter processes, go through the initial (E)SMTP steps and then send a mail very slowly. As long as the number of SMTP server slots is finite, there will always be saturation effects. The main trick of speed-adjust is that you can run more SMTP server processes than filters, and thereby reduce the impact of slow or non-cooperative clients. Of course the system still saturates immediately when the PEAK email volume exceeds the filter capacity. With after-queue filters, saturation happens when the AVERAGE volume exceeds filter capacity. With smtpd_proxy_options=speed_adjust, you'd have to DoS the Postfix SMTP server itself, and between postscreen guarding it, high process limits, access control and the stress adaptive server personality, this one is well able to take care of itself. I have been looking for incremental steps to improve Postfix's handling of non-cooperating clients, and speed-adjust is part of those steps. Postscreen greylisting support should also help a lot, but that will probably not be in Postfix 2.7. Of course all these things do is increase the threshold. No system except a wire cutter can deal with unlimited amounts of traffic. Wietse
FILTER nexthop woes
Hi, I'm trying to use header_checks in conjunction with a pcre map to distribute certain mail traffic to certain outgoing transports. I've got a setup like this: --- main.cf snip --- header_checks = pcre:/etc/postfix/header.pcre --- snap --- --- header.pcre snip --- /^X-CUSTOMER-ID: ([0-9])/ FILTER smtpout$1: --- snap --- In the master.cf I have smtpout0-9 transports like this one: --- master.cf snip --- smtpout0 unix - - - - - smtp -o smtp_helo_name=server1.isp.net -o smtp_bind_address=11.22.33.44 --- master.cf snap --- With this setup I try to distribute my mail traffic according to the rules defined in header.pcre. Unfortunately it does not work. According to http://www.postfix.org/postconf.5.html#default_transport and http://www.postfix.org/transport.5.html Postfix should use the recipient domain as the nexthop, but it doesn't. My Question: How can I filter my outgoing mail based on a header field to an smtp-transport? Best Regards, Dominik
Re: FILTER nexthop woes
l...@ds.gauner.org: Hi, I'm trying to use header_checks in conjunction with a pcre map to distribute certain mail traffic to certain outgoing transports. I've got a setup like this: --- main.cf snip --- header_checks = pcre:/etc/postfix/header.pcre --- snap --- --- header.pcre snip --- /^X-CUSTOMER-ID: ([0-9])/ FILTER smtpout$1: You MUST specify a nexthop destination. The purpose of FILTER is to send mail for MANY destinations through ONE filter destination. If you don't specify a next-hop destination, then Postfix will choose a default one. To make Postfix routing sender dependent, use sender_dependent_relayhost_maps (Postfix 2.3 and later) or sender_dependent_default_transport_maps (Postfix 2.7 and later). Wietse
TLS - Certificate not Trusted
I'm just getting started with version 2.5.5 and TLS is different that my previous version. I have everything thing working except some email will not go out because of the error delivery temporarily suspended: Server certificate not trusted. What parameter do I have wrong that requires trusted certificates? I want to enforce TLS but I don't care what certificate the receiver uses. Thanks. Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
Re: TLS - Certificate not Trusted
On Mon, 2010-01-11 at 11:04 -0500, Dennis Putnam wrote: I want to enforce TLS but I don't care what certificate the receiver uses. Thanks. Apart from the fact that enforcing TLS with SMTP is usually a bad idea, setting the smtp_tls_security_level = encrypt should usually do what you mean, enforce TLS with the remote SMTP server, but accept untrusted certs or even those with a wrong name. The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments. There is (at least in most countries) no legal ground for so called disclaimers and they're quite stupid and annoying when sending them to public mailing lists. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: reject_authenticated_sender_login_mismatch
2010/1/11 Michael p...@nettrust.co.nz: As follows smtpd_recipient_restrictions = ... check_recipient_access hash:/etc/postfix/access, permit_mynetworks, reject_authenticated_sender_login_mismatch mysql:/etc/postfix/mysql-sender-access.cf reject_unauth_destination ... RECEIVER ADDRESS (The server responded: 5.7.1 SENDER ADDRESS: Sender address rejected: not owned by user SASL USER) What;s going on? Running the query directly against the SQL database returns the desired result. I've not used this function before myself, but my reading of the docs indicates you might've misinterpreted the correct usage. I hopped through these three in order: http://www.postfix.org/postconf.5.html#reject_authenticated_sender_login_mismatch http://www.postfix.org/postconf.5.html#reject_sender_login_mismatch http://www.postfix.org/postconf.5.html#smtpd_sender_login_maps You haven't posted the output of `postconf -n`, so I don't know if your settings are correct, but I suspect you're needing something like: smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, check_recipient_access hash:/etc/postfix/access, permit_mynetworks, reject_authenticated_sender_login_mismatch, reject_unauth_destination smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-access.cf reject_authenticated_sender_login_mismatch doesn't take a type:table mapping, it just makes use of one defined elsewhere.
re-enqueue quarantined mails
hi, I have a postfix 2.3.3 with an amavis antivir. I need to resume some mails, moved into /var/virusmails from amavis, to /var/spool/postfix/incoming (I need that postfix try to resend them). If I move the single mail files (changing owner and permission) I obtain that postfix move it into corrupt dir after while. I have noticed that the files in virusmails have a plain- text format, but email in incoming seem to have a binary format (I sniffed one during a normal mail delivery). How can I resume my mails? TIA
Re: re-enqueue quarantined mails
On 1/11/2010 10:14 AM, rcolme...@libero.it wrote: hi, I have a postfix 2.3.3 with an amavis antivir. I need to resume some mails, moved into /var/virusmails from amavis, to /var/spool/postfix/incoming (I need that postfix try to resend them). If I move the single mail files (changing owner and permission) I obtain that postfix move it into corrupt dir after while. I have noticed that the files in virusmails have a plain- text format, but email in incoming seem to have a binary format (I sniffed one during a normal mail delivery). How can I resume my mails? Use the amavisd-release function to release mail out of the quarantine. See the amavisd RELEASE_NOTES for details, or see the amavis-user mail list archive. If you must requeue them with postfix, you need edit the text file and then resubmit them with the sendmail command. -- Noel Jones
Re: TLS - Certificate not Trusted
Hi Chris, Thanks for the reply. Please see embedded comments. On Jan 11, 2010, at 11:11 AM, Christoph Anton Mitterer wrote: On Mon, 2010-01-11 at 11:04 -0500, Dennis Putnam wrote: I want to enforce TLS but I don't care what certificate the receiver uses. Thanks. Apart from the fact that enforcing TLS with SMTP is usually a bad idea, setting the smtp_tls_security_level = encrypt should usually do what you mean, enforce TLS with the remote SMTP server, but accept untrusted certs or even those with a wrong name. I don't get to choose, I just have to do it. How these parameters work is still a little confusing to me. I have smtpd and smtp security levels set to 'may.' What I am trying to do it set up opportunistic TLS except for specific hosts that I need to enforce (smtp_tls_per_site). What I noticed is that this one site was using Thawte as the signing authority. I tried adding their root certificate to my config and now the error has changed to a warning about untrusted TLS connection but the mail seems to be moving now. Did I stumble on to a fix or am I still missing something? The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments. There is (at least in most countries) no legal ground for so called disclaimers and they're quite stupid and annoying when sending them to public mailing lists. I am quite familiar with the arguments but again it is not my choice. If you want, I can give you the number of our corporate lawyers and you can try to convince them. Perhaps you will have better luck than me. :-) Cheers, Chris. Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
Re: TLS - Certificate not Trusted
On Mon, 2010-01-11 at 11:04 -0500, Dennis Putnam wrote: I want to enforce TLS but I don't care what certificate the receiver uses. Thanks. Apart from the fact that enforcing TLS with SMTP is usually a bad idea, [..] Why is TLS w/ SMTP a bad idea? -- Noah Sheppard Assistant Computer Resource Manager Taylor University CSE Department nshep...@cse.taylor.edu
Re: Sender based relay server
On Mon, January 11, 2010 5:04 pm, David Koski wrote: On Monday 11 January 2010, Jack Knowlton wrote: Thank you. I figured out how to make a per-domain relay, but what is the format for having the message directly delivered? I tried both smtp: and :smtp but none seemed to work.. Is transport (man transport) what you are looking for? David Koski da...@kosmosisland.com I believe so, yet I could not find any example to match what I need. When the relay map is set as @domain2.com smtp: @domain3.com [yyy.yyy.yyy.yyy]:25 And I send a message from u...@domain2.com, I get this: Jan 11 17:53:47 dsrv3 postfix/smtp[7561]: C8890252DCE: to=x...@gmail.com, relay=none, delay=0.13, delays=0.03/0.07/0.02/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=smtp type=: Host not found) -JK
Re: TLS - Certificate not Trusted
On Mon, Jan 11, 2010 at 11:53:35AM -0500, Noah Sheppard wrote: [attribution to Chris is missing] On Mon, 2010-01-11 at 11:04 -0500, Dennis Putnam wrote: I want to enforce TLS but I don't care what certificate the receiver uses. Thanks. Apart from the fact that enforcing TLS with SMTP is usually a bad idea, [..] Why is TLS w/ SMTP a bad idea? TLS with SMTP is a fine idea. *Enforcing* TLS with SMTP is usually a bad idea. Many sites might not support it, and if you require TLS, you cannot get their mail nor send to them. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: TLS - Certificate not Trusted
Hi Noel, Thanks. I thing you pointed me in the right direction. Am I correct that the per_site table is different under 2.5.5 than pre 2.3? I had trouble getting that to work on the old server so I didn't change it for the migration. What I have is: .somedomain.com MUST I think it now can be a hash and should look like: [somedomain.com] encrypt Is that correct? I guessing the old 'MUST' is being interpreted as 'secure' in this version. On Jan 11, 2010, at 12:02 PM, Noel Jones wrote: On 1/11/2010 10:38 AM, Dennis Putnam wrote: Upon further investigation, apparently mail is not moving. There seems to be 2 domains associated with this site but I was only asked to enforce TLS on one of them. That is why it appeared to be working. Getting back to Chris' comments, I think setting the security level to 'encrypt' forces everything to be TLS and that will not work. I need it to work as I previously described. Postfix client TLS settings are described in http://www.postfix.org/TLS_README.html#client_tls For a general-purpose MTA the main.cf setting should be none or may. To force encryption for a specific recipient domain, see http://www.postfix.org/TLS_README.html#client_tls_policy If your mail is deferred due to certificate errors, this implies you're using a security level above encrypt. Don't do that unless you have the proper root certificates installed. If you need more help, please refer to http://www.postfix.org/DEBUG_README.html#mail and show us your postconf -n output, any related policy map contents, and related logging. -- Noel Jones Dennis Putnam Sr. IT Systems Administrator AIM Systems, Inc. 11675 Rainwater Dr., Suite 200 Alpharetta, GA 30009 Phone: 678-240-4112 Main Phone: 678-297-0700 FAX: 678-297-2666 or 770-576-1000 The information contained in this e-mail and any attachments is strictly confidential. If you are not the intended recipient, any use, dissemination, distribution, or duplication of any part of this e-mail or any attachment is prohibited. If you are not the intended recipient, please notify the sender by return e-mail and delete all copies, including the attachments.
Re: TLS - Certificate not Trusted
On 1/11/2010 11:16 AM, Dennis Putnam wrote: Hi Noel, Thanks. I thing you pointed me in the right direction. Am I correct that the per_site table is different under 2.5.5 than pre 2.3? I had trouble getting that to work on the old server so I didn't change it for the migration. What I have is: .somedomain.com MUST I think it now can be a hash and should look like: [somedomain.com http://somedomain.com] encrypt Is that correct? I guessing the old 'MUST' is being interpreted as 'secure' in this version. According to the example in http://www.postfix.org/TLS_README.html#client_tls_policy the policy table should contain somedomain.tld encrypt To include subdomains of somedomain.tld also include .somedomain.tld encrypt -- Noel Jones
Spam Attack on my outgoing server
Hello everyone, I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. Postconf -n output: alias_database = hash:/etc/postfix/aliases alias_maps = hash:/etc/postfix/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 html_directory = no local_recipient_maps = local_transport = error:local mail delivery is disabled mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /usr/local/man mydestination = mydomain = cht.com.ar myhostname = xxx.cht.com.ar mynetworks = 127.0.0.0/8, xxx.xx.xx.xx/29, xxx.xxx.xx.xx/29 myorigin = cht.com.ar newaliases_path = /usr/bin/newaliases parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps queue_directory = /var/spool/postfix readme_directory = no relay_domains = cht.com.ar, skalbue.com.ar, ci-educ.com.ar, hispanoamericana.com.ar, aaovyt.com.ar, consulthouse.travel, consul.travel sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop smtpd_delay_reject = yes smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks,reject_non_fqdn_hostname, reject_invalid_hostname, permit smtpd_sender_restrictions = permit_mynetworks,check_sender_access = hash :/etc/postfix/sender_map, reject_non_fqdn_sender, reject_unknown_s ender_domain, permit strict_rfc821_envelopes = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = hash:/etc/postfix/virtual sender_map: cht.com.ar OK aaovyt.com.ar OK hispanoamericana.com.ar OK cht.tur.ar OK consulthouse.travel OK If you need anything else, please let me know. Regards.- Damián
Re: Spam Attack on my outgoing server
On Mon, 11 Jan 2010 15:27:05 -0300 Damian Rivas dam...@cht.com.ar wrote: Hello everyone, I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. You seem to be allowing anyone forging one of your domains to relay. That is not good. smtpd_sender_restrictions = permit_mynetworks, check_sender_access = hash:/etc/postfix/sender_map, reject_non_fqdn_sender, reject_unknown_sender_domain, permit That 'check_sender_access' is evil. Please remove it. Replace it with: reject_unauth_destination
Re: Spam Attack on my outgoing server
On 1/11/2010 1:27 PM, Damian Rivas wrote: Hello everyone, I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. check_sender_access is not the right tool IMO. Saying OK in the wrong place will make you an even bigger open relay. Anyone could easily say they were MAIL FROM your domain with a simple telnet or script. What you really want is to enable SASL and tell your users to utilize it to provide extra security while minimizing risk. Bad/common passwords can still be guessed by spammers See http://www.postfix.org/SASL_README.html for details.
Re: TLS - Certificate not Trusted
On Mon, Jan 11, 2010 at 11:36:42AM -0600, Noel Jones wrote: According to the example in http://www.postfix.org/TLS_README.html#client_tls_policy the policy table should contain somedomain.tld encrypt To include subdomains of somedomain.tld also include .somedomain.tld encrypt And only when one's transport table or relayhost specifies a nexthop of the form: [gateway.example.com] does the TLS policy table need an entry of the same form: [gateway.example.com] encrypt|secure|fingerprint ... For [gateway] nexthops there is no real difference between secure and verify, both test for the same nexthop address, unless match values are specified explicitly. In retrospect, it an interface design error to provide both levels, just one would have been enough, with backwards compatibility for tls_per_site provided via different match values for verify not a different security level. Both, verify certificates using a slightly different default set of match values. :-( The damage is fairly minor... -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. To unsubscribe from the postfix-users list, visit http://www.postfix.org/lists.html or click the link below: mailto:majord...@postfix.org?body=unsubscribe%20postfix-users If my response solves your problem, the best way to thank me is to not send an it worked, thanks follow-up. If you must respond, please put It worked, thanks in the Subject so I can delete these quickly.
Re: TLS - Certificate not Trusted
On 11-Jan-2010, at 09:27, Dennis Putnam wrote: I am quite familiar with the arguments but again it is not my choice. If you want, I can give you the number of our corporate lawyers and you can try to convince them. Perhaps you will have better luck than me. :-) I will be happy to email them daily links to publicly accessible web pages containing emails sent from that domain to a mailing list with that 'disclaimer' attached. I will use, disseminate, distribute, and republish any post with a disclaimer on it as a matter of course. -- INDIAN BURNS ARE NOT OUR CULTURAL HERITAGE Bart chalkboard Ep. 3F05
Re: Spam Attack on my outgoing server
On 1/11/2010 1:00 PM, brian moore wrote: On Mon, 11 Jan 2010 15:27:05 -0300 Damian Rivasdam...@cht.com.ar wrote: Hello everyone, I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. You seem to be allowing anyone forging one of your domains to relay. That is not good. smtpd_sender_restrictions = permit_mynetworks, check_sender_access = hash:/etc/postfix/sender_map, reject_non_fqdn_sender, reject_unknown_sender_domain, permit That 'check_sender_access' is evil. Please remove it. Replace it with: reject_unauth_destination Damian, Please ignore the above bad advice. An OK in smtpd_sender_restrictions can not possibly make you an open relay. Likely it didn't work as expected because the mail isn's submitted via SMTP. Before you waste time on any other bad advice you may get, examine your logs to see where the mail comes from. Once you know the problem, a solution is much easier. Post logs here if you don't know how to evaluate them. My wild guess is that you have an abused web form, but check the logs before you go running around telling everyone your web server is hacked. -- Noel Jones
Re: Spam Attack on my outgoing server
On 1/11/2010 1:11 PM, Brian Evans - Postfix List wrote: On 1/11/2010 1:27 PM, Damian Rivas wrote: Hello everyone, I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. check_sender_access is not the right tool IMO. Saying OK in the wrong place will make you an even bigger open relay. Anyone could easily say they were MAIL FROM your domain with a simple telnet or script. The OK in smtpd_sender_restrictions is fine, but probably doesn't address the real problem. At any rate, it would prevent the MTA from receiving any outside mail. That's OK if this is a outbound-only relay. What you really want is to enable SASL and tell your users to utilize it to provide extra security while minimizing risk. Bad/common passwords can still be guessed by spammers See http://www.postfix.org/SASL_README.html for details. While SASL is generally a good idea, it probably doesn't address the problem. -- Noel Jones
RE: Spam Attack on my outgoing server
Damian, Please ignore the above bad advice. An OK in smtpd_sender_restrictions can not possibly make you an open relay. Likely it didn't work as expected because the mail isn's submitted via SMTP. Before you waste time on any other bad advice you may get, examine your logs to see where the mail comes from. Once you know the problem, a solution is much easier. Post logs here if you don't know how to evaluate them. My wild guess is that you have an abused web form, but check the logs before you go running around telling everyone your web server is hacked. -- Noel Jones Thanks to everyone for your quick answers. Noel, it's not my web server the problem, or I guess it isn't, it's my outgoing mail server that has the problem and it is because I'm not finding a way to properly check my valid senders. In an inconming mail relay built on Postfix you can build a list of valid recipients and reject the invalid ones. Isn't there a similar option to validate senders? And, is there a way validate if that sender has come out from my network? I was thinking in those two things to stop this. Anyway, I'm posting some logs from the mailqueue: Jan 11 16:42:43 impcht3 postfix/qmgr[29558]: DC2C94D86B: from=t...@963.net, size=6006, nrcpt=1 (queue active) Jan 11 16:42:43 impcht3 postfix/error[29904]: D1CD350F60: to=southernprincess_...@yahoo.com, relay=none, delay=220465, delays=220453/0.64/0/12, dsn=4.7.0, status=deferred (delivery temporarily suspended: host e.mx.mail.yahoo.com[67.195.168.230] refused to talk to me: 421 4.7.0 [TS01] Messages from 200.55.14.253 temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html) Jan 11 16:42:43 impcht3 postfix/error[30919]: DCEFB46E53: to=mohammedv...@yahoo.com, relay=none, delay=229978, delays=229976/0.78/0/0.41, dsn=4.7.0, status=deferred (delivery temporarily suspended: host e.mx.mail.yahoo.com[67.195.168.230] refused to talk to me: 421 4.7.0 [TS01] Messages from 200.55.14.253 temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html) Jan 11 16:42:43 impcht3 postfix/error[30949]: D472A47F38: to=sanju_sudha...@yahoo.com, relay=none, delay=225147, delays=225138/2.5/0/6.3, dsn=4.7.0, status=deferred (delivery temporarily suspended: host e.mx.mail.yahoo.com[67.195.168.230] refused to talk to me: 421 4.7.0 [TS01] Messages from 200.55.14.253 temporarily deferred due to user complaints - 4.16.55.1; see http://postmaster.yahoo.com/421-ts01.html) Jan 11 16:42:43 impcht3 postfix/error[30976]: D9875481D6: to=t...@963.net, relay=none, delay=205984, delays=205980/3.5/0/0.49, dsn=4.0.0, status=deferred (delivery temporarily suspended: host msg.963.net[202.96.154.167] refused to talk to me: 554 IP is rejected: 188.) Jan 11 16:42:43 impcht3 postfix/smtp[29668]: D89044B978: host hrndva-smtpin01.mail.rr.com[71.74.56.243] refused to talk to me: 554 5.7.1 - ERROR: Mail refused - 200.55.14.253 - See http://security.rr.com/cgi-bin/block-lookup?200.55.14.253 Jan 11 16:42:43 impcht3 postfix/error[30941]: D73DF58B14: to=t...@963.net, relay=none, delay=165707, delays=165706/0.17/0/0.47, dsn=4.0.0, status=deferred (delivery temporarily suspended: host msg.963.net[202.96.154.167] refused to talk to me: 554 IP is rejected: 188.) As you can see, Yahoo and some others have already blocked my IP and that mail address t...@963.net has filled up my mail queue not only with mails sent but also with bounces. Just ask if you want to know anything else. Regards, Damian
Re: Spam Attack on my outgoing server
On Mon, Jan 11, 2010 at 03:27:05PM -0300, Damian Rivas wrote: I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. Who/what sent you that warning? It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. No evidence below suggests that you might be an open relay. LOGS! Postconf -n output: mynetworks = 127.0.0.0/8, xxx.xx.xx.xx/29, xxx.xxx.xx.xx/29 These are the hosts allowed to relay. Don't mung the IP addresses. They can probably be looked up anyway, using the domain names that weren't hidden (good). relay_domains = cht.com.ar, skalbue.com.ar, ci-educ.com.ar, hispanoamericana.com.ar, aaovyt.com.ar, consulthouse.travel, consul.travel If this is outgoing only, why are there relay_domains ? smtpd_sender_restrictions = permit_mynetworks, check_sender_access = hash :/etc/postfix/sender_map, reject_non_fqdn_sender, reject_unknown_sender_domain, permit The second = is not correct syntax. Except for the two reject_* restrictions, this stage does nothing. And as documented, it CANNOT permit relaying; this is controlled only in smtpd_recipient_restrictions . sender_map: cht.com.ar OK aaovyt.com.ar OK hispanoamericana.com.ar OK cht.tur.ar OK consulthouse.travel OK If you need anything else, please let me know. A cup of tea, please. :) YOU need to stop the spam, and if you need help in determining how your system was allowing it, please see: http://www.postfix.org/DEBUG_README.html#mail -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Spam Attack on my outgoing server
On Mon, Jan 11, 2010 at 04:44:23PM -0300, Damian Rivas wrote: Noel Jones Post logs here if you don't know how to evaluate them. My wild guess is that you have an abused web form, but check the logs before you go running around telling everyone your web server is hacked. Noel, it's not my web server the problem, or I guess it isn't, it's my outgoing mail server that has the problem and it is because I'm not finding a way to properly check my valid senders. Your guess is not correct. The logs we would need to see are ones where suspected spam arrives. You showed the ones going out, not useful at all. In an inconming mail relay built on Postfix you can build a list of valid recipients and reject the invalid ones. Isn't there a similar option to validate senders? Yes, but this is not the problem you are seeing. And, is there a way validate if that sender has come out from my network? I was thinking in those two things to stop this. This is Postfix default behavior. Anyway, I'm posting some logs from the mailqueue: Jan 11 16:42:43 impcht3 postfix/qmgr[29558]: DC2C94D86B: from=t...@963.net, size=6006, nrcpt=1 (queue active) Do you suspect this one is spam? Find when queue ID DC2C94D86B first appeared in your logs, and the correlated smtpd Connect from line which preceded it, or postfix/pickup line if Noel's guess was right (I bet it was.) Repeat for one or two other suspects. Post results. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: Spam Attack on my outgoing server
On 1/11/2010 1:44 PM, Damian Rivas wrote: Damian, Please ignore the above bad advice. An OK in smtpd_sender_restrictions can not possibly make you an open relay. Likely it didn't work as expected because the mail isn's submitted via SMTP. Before you waste time on any other bad advice you may get, examine your logs to see where the mail comes from. Once you know the problem, a solution is much easier. Post logs here if you don't know how to evaluate them. My wild guess is that you have an abused web form, but check the logs before you go running around telling everyone your web server is hacked. -- Noel Jones Thanks to everyone for your quick answers. Noel, it's not my web server the problem, or I guess it isn't, it's my outgoing mail server that has the problem and it is because I'm not finding a way to properly check my valid senders. In an inconming mail relay built on Postfix you can build a list of valid recipients and reject the invalid ones. Isn't there a similar option to validate senders? And, is there a way validate if that sender has come out from my network? I was thinking in those two things to stop this. Anyway, I'm posting some logs from the mailqueue: You need to show where the mail ENTERS postfix. These will be logged as postfix/smtpd for SMTP mail, or postfix/pickup for command-line mail. To limit valid SMTP senders, you can use check_sender_access. Your postconf -n output looked a little odd, maybe your syntax is wrong or maybe the mail didn't arrive via SMTP. The logs will show where the mail arrived from. Kill the spam at the source as shown in the logs. Forcing your local domain as sender will just encourage the spammer to use your own domain, further damaging your reputation. smtpd_sender_restrictions = permit_mynetworks,check_sender_access = hash :/etc/postfix/sender_map, reject_non_fqdn_sender, reject_unknown_s ender_domain, permit Assuming this is an outbout-only relay, and valid senders are listed in sender_map, your smtpd_sender_restrictions should look like: smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_map, reject -- Noel Jones
RE: Spam Attack on my outgoing server
De: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] En nombre de /dev/rob0 Enviado el: lunes, 11 de enero de 2010 16:50 Para: postfix-users@postfix.org Asunto: Re: Spam Attack on my outgoing server On Mon, Jan 11, 2010 at 03:27:05PM -0300, Damian Rivas wrote: I have a Postfix box basically configured to send mail from my organization to the Internet. Today I received a warning message telling me that the mail queue was full. Who/what sent you that warning? My apologies, I haven't expressed myself correctly. What I received was a Postfix message telling me that the hard disk was full (it is a small 4GB disk). When I checked a bit the queue, I was bombarded by this t...@963.net's guy, I had thousands of deferred mails from this address. There were also some mails like thismailisnotchec...@gmail.com, the guy has some nice humour after all, he he. Other messages where from the null sender , just bounces to t...@963.net. Now the address has changed to t...@citsclub.cn. It seems that some Spammer is using my server as an Open Relay, so I used the check_sender_access function to only allow my domains to send mail to the outside, but it is not working and I don't know what to do, perhaps you can give me some tips. No evidence below suggests that you might be an open relay. LOGS! Postconf -n output: mynetworks = 127.0.0.0/8, 200.55.14.248/29, 190.210.52.88/29 These are the hosts allowed to relay. Don't mung the IP addresses. They can probably be looked up anyway, using the domain names that weren't hidden (good). Yeah you are totally right, I'm a bit silly today, sorry about that. relay_domains = cht.com.ar, skalbue.com.ar, ci-educ.com.ar, hispanoamericana.com.ar, aaovyt.com.ar, consulthouse.travel, consul.travel If this is outgoing only, why are there relay_domains? That's because I was copying a config file from another postfix server (for relaying incoming mail) to rewrite this one, but I was in a rush because of the situation and I forgot to remove that line. Same as before, I'm totally dumb today. smtpd_sender_restrictions = permit_mynetworks, check_sender_access = hash :/etc/postfix/sender_map, reject_non_fqdn_sender, reject_unknown_sender_domain, permit The second = is not correct syntax. Except for the two reject_* restrictions, this stage does nothing. And as documented, it CANNOT permit relaying; this is controlled only in smtpd_recipient_restrictions . I took a very quick and bad guess of what really was happening, I knew it was impossible to be an Open Relay, but when I found no clues I didn't know what to think. Probably it's because is Monday and I'm taking vacations next week, so, my mind is in another place. Noel suggested a problem with the web server, a vulnerable form. I talked with the webmaster and he told me that the forms are possibly unsecure but I also was reported that the web was down during the weekend AND the mailing issue started during weekend. Well it could be a coincidence or not, gotta check. I started to search in the web access logs, there was no trace of the spammer IP during the weekend. So, there was no evidence pointing a problem on the web server. Time to get back to Postfix. I have corrected the main.cf to adapt to what Noel suggested. Until that moment I was not receiving any postfix/stmpd message in the logs, but after that they started to appear magically and I discover something interesting. All mailing incomes seem to come from ns1.cht.com.ar, which is a gateway for the internal mail server, this is by the way, where they are normally sent. There were no smtpd outputs before because the Spam was cycling and there was no room for any new mail. (I deleted all the spammer mails, of course they keep coming). I have checked the internal mail server today and there were no clues to point out that spam was generated inside and sent to the Postfix box. But now, at this precise moment, I'm watching a lot of junk being generated on the server so, there is the source of the problem, I have a worm on my internal web server, no postfix issue. Thank you all for your help I'm going to solve this now. Regards.- Damián
Lower-case for incoming mail
I've got the following in my /var/log/maillog while running
postfix-2.3.3-2.1.centos.mysql with mysql for account information.
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) ESMTP::10024
/var/amavis/tmp/amavis-20100111T163707-14138: t...@gmail.com -
test...@dest.example.com SIZE=1954 Received: from
mailserver.example.com([127.0.0.1]) by localhost (
mailserver.example.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP for
test...@dest.example.com; Mon, 11 Jan 2010 16:39:57 -0500 (EST)
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) Checking: qSdglaHOIgx3
t...@gmail.com - test...@dest.example.com
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) FWD via SMTP:
t...@gmail.com - test...@dest.example.com,BODY=7BIT 250 2.6.0 Ok,
id=14138-11, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as E72D9EFD27
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) Passed CLEAN,
[209.85.219.217] t...@gmail.com - test...@dest.example.com, Message-ID:
c6d46a88100339l34b9610fm7124a054fd434...@mail.gmail.com, mail_id:
qSdglaHOIgx3, Hits: -2.599, size: 1954, queued_as: E72D9EFD27, 527 ms
Jan 11 16:39:57 mailserver postfix/smtp[13749]: 2F3B1EFD25: to=
test...@dest.example.com, relay=127.0.0.1[127.0.0.1]:10024, delay=0.91,
delays=0.38/0/0/0.53, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
E72D9EFD27)
Jan 11 16:39:58 mailserver deliver(test...@dest.example.com): msgid=
c6d46a88100339l34b9610fm7124a054fd434...@mail.gmail.com: saved mail to
INBOX
Jan 11 16:39:58 mailserver postfix/pipe[13810]: E72D9EFD27: to=
test...@dest.example.com, relay=dovecot, delay=0.2, delays=0.04/0/0/0.16,
dsn=2.0.0, status=sent (delivered via dovecot service)
When email comes in to an address in upper case:
test...@dest.example.com
it stays upper case, until handed off to Dovecot.
I currently have in master.cf
dovecot unix- n n - - pipe
flags=DR user=vuser:vuser argv=/usr/libexec/dovecot/deliver -f ${sender}
-d ${us...@${nexthop} -n -m ${extension}
I think I can lower case it on it's way into dovecot, with something like:
dovecot unix- n n - - pipe
flags=DRhu user=vuser:vuser argv=/usr/libexec/dovecot/deliver -f ${sender}
-d ${us...@${nexthop} -n -m ${extension}
(the hu in the flags)
but I'd rather lc it as it enters the system (in part because we use +Spam
as an extension for spam filtering, and I'd rather not change that to +spam
when it enters dovecot). Is there a way to change the email address to LC in
postfix before it goes through amavis?
thanks
rick
Re: reject_authenticated_sender_login_mismatch
Michael a écrit : As follows smtpd_recipient_restrictions = reject_invalid_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, useless. RCPT TO is an asynchronous command, so there is no unauth_pipelining at this stage. read the pipelining RFC for more. check_recipient_access hash:/etc/postfix/access, Avoid check_foo_access before reject_unauth_destination. an error will make you an open relay. what are you tryng to do with that? permit_mynetworks, reject_authenticated_sender_login_mismatch mysql:/etc/postfix/mysql-sender-access.cf As Barney pointed out, errax syntor (syntax error). you want something like: smtpd_sender_login_maps = mysql:/etc/postfix/mysql-sender-access.cf smtpd_sender_restrictions = reject_authenticated_sender_login_mismatch (there's no point polluting smtpd_recipient_restrictions with this). PS. next time, show output of 'postconf -n' instead of personally selected main.cf snippets. [snip]
Re: Lower-case for incoming mail
On 1/11/2010 4:32 PM, Rick wrote:
I've got the following in my /var/log/maillog while running
postfix-2.3.3-2.1.centos.mysql with mysql for account information.
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) ESMTP::10024
/var/amavis/tmp/amavis-20100111T163707-14138: t...@gmail.com
mailto:t...@gmail.com - test...@dest.example.com
mailto:test...@dest.example.com SIZE=1954 Received: from
mailserver.example.com http://mailserver.example.com ([127.0.0.1]) by
localhost (mailserver.example.com http://mailserver.example.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP for
test...@dest.example.com mailto:test...@dest.example.com; Mon, 11
Jan 2010 16:39:57 -0500 (EST)
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) Checking:
qSdglaHOIgx3 t...@gmail.com mailto:t...@gmail.com -
test...@dest.example.com mailto:test...@dest.example.com
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) FWD via SMTP:
t...@gmail.com mailto:t...@gmail.com - test...@dest.example.com
mailto:test...@dest.example.com,BODY=7BIT 250 2.6.0 Ok, id=14138-11,
from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as E72D9EFD27
Jan 11 16:39:57 mailserver amavis[14138]: (14138-11) Passed CLEAN,
[209.85.219.217] t...@gmail.com mailto:t...@gmail.com -
test...@dest.example.com mailto:test...@dest.example.com,
Message-ID: c6d46a88100339l34b9610fm7124a054fd434...@mail.gmail.com
mailto:c6d46a88100339l34b9610fm7124a054fd434...@mail.gmail.com,
mail_id: qSdglaHOIgx3, Hits: -2.599, size: 1954, queued_as: E72D9EFD27,
527 ms
Jan 11 16:39:57 mailserver postfix/smtp[13749]: 2F3B1EFD25:
to=test...@dest.example.com mailto:test...@dest.example.com,
relay=127.0.0.1[127.0.0.1]:10024, delay=0.91, delays=0.38/0/0/0.53,
dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as E72D9EFD27)
Jan 11 16:39:58 mailserver deliver(test...@dest.example.com
mailto:test...@dest.example.com):
msgid=c6d46a88100339l34b9610fm7124a054fd434...@mail.gmail.com
mailto:c6d46a88100339l34b9610fm7124a054fd434...@mail.gmail.com:
saved mail to INBOX
Jan 11 16:39:58 mailserver postfix/pipe[13810]: E72D9EFD27:
to=test...@dest.example.com mailto:test...@dest.example.com,
relay=dovecot, delay=0.2, delays=0.04/0/0/0.16, dsn=2.0.0, status=sent
(delivered via dovecot service)
When email comes in to an address in upper case:
test...@dest.example.com mailto:test...@dest.example.com
it stays upper case, until handed off to Dovecot.
I currently have in master.cf http://master.cf
dovecot unix- n n - - pipe
flags=DR user=vuser:vuser argv=/usr/libexec/dovecot/deliver -f
${sender} -d ${us...@${nexthop} -n -m ${extension}
I think I can lower case it on it's way into dovecot, with something like:
dovecot unix- n n - - pipe
flags=DRhu user=vuser:vuser argv=/usr/libexec/dovecot/deliver -f
${sender} -d ${us...@${nexthop} -n -m ${extension}
(the hu in the flags)
but I'd rather lc it as it enters the system (in part because we use
+Spam as an extension for spam filtering, and I'd rather not change that
to +spam when it enters dovecot). Is there a way to change the email
address to LC in postfix before it goes through amavis?
thanks
rick
Postfix has no built-in support to automatically lower-case
addresses other than the pipe flags you've already found.
Conversely, postfix makes a great effort to *not* change the
case of the address. (those pesky RFC's and their MUST NOT
clauses.)
As an ugly workaround, you can craft an SQL query for
virtual_alias_maps that does 1:1 user mapping ONLY IF the user
actually exists -- don't return an answer for invalid
recipients as that will break recipient validation.
-- Noel Jones
Auto-whitelist policy
Does anyone have an auto-whitelisting policy daemon? I want to have a test early in sender checks that would bypass most of my other spam prevention if a sender is in the whitelist - and have that whitelist automatically updated by internal users sending to those remote senders. -- Daniel
Postfix as an MTA question
Hi, I'm trying to use Postfix as an MTA. I don't want to deliver any mail locally, just relay everything to an external mail server. I would also like everything that runs though this MTA to be sent as a particular user, however I don't want messages intended for users on the system such as root to be delivered. I have gotten everything to work except I am getting messages for the root user sent to the sendas address. If the system users have to be delivered, that is fine, I can just use the aliases to redirect them to a single user and then deal with the mail there. I would prefer that they go to a black hole though. I've been trying to find a solutions to this for some time now and haven't been successful so far. Any direction you can provide is appreciated. Thanks, Casper My configuration looks like this. # Main Conf File # Server Stuff myorigin = testdomain.int masquerade_domains = testdomain.int relayhost = [10.0.22.25] inet_interfaces = 127.0.0.1 alias_database = hash:/etc/aliases # SASL Auth stuff smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_security_options = Generic map file @localhost.localdomain sendas email @localhost sendas email @localdomain sendas email @testdomain.int sendas email
Re: Does Postfix cache resolv.conf? [SOLVED]
Thanks Stefan, The Debian packages of Postfix are running smtpd in a chroot by default. The files necessary for this are copied by the init script /etc/init.d/postfix - and amongst them is the resolv.conf you changed. It's exactly this. The chroot has its own copy of (caches) resolv.conf. Regards, - lars.
Re: Does Postfix cache resolv.conf? [SOLVED]
On Jan 11, 2010, at 4:23 PM, Dr. Lars Hanke wrote: It's exactly this. The chroot has its own copy of (caches) resolv.conf. And the command 'postfix check' will tell you if there's a problem (my server just now): r...@server# postfix check postfix/postfix-script: warning: /var/spool/postfix/etc/hosts and /etc/hosts differ -- Glenn English g...@slsware.com
Re: Does Postfix cache resolv.conf? [SOLVED]
On Tue, 2010-01-12 at 00:23 +0100, Dr. Lars Hanke wrote: Thanks Stefan, The Debian packages of Postfix are running smtpd in a chroot by default. The files necessary for this are copied by the init script /etc/init.d/postfix - and amongst them is the resolv.conf you changed. It's exactly this. The chroot has its own copy of (caches) resolv.conf. Using the resolvconf package, should solve your problems, the Debian postfix package ships rules for resolvconf in order to automatically update the chroot resolv.conf. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: Spam Attack on my outgoing server
On Mon, Jan 11, 2010 at 06:15:21PM -0300, Damian Rivas wrote: mynetworks = 127.0.0.0/8, 200.55.14.248/29, 190.210.52.88/29 These are the hosts allowed to relay. Don't mung the IP addresses. snip All mailing incomes seem to come from ns1.cht.com.ar, which is a gateway for the internal mail server, this is by the way, where ns1.cht.com.ar. 3600IN A 200.55.14.250 Indeed, this host is in your $mynetworks. Exclude it using the ! syntax, see example at postconf.5.html#mynetworks . they are normally sent. There were no smtpd outputs before because the Spam was cycling and there was no room for any new mail. (I deleted all the spammer mails, of course they keep coming). Stop this at once! The ongoing abuse has probably gotten you blacklisted. The sooner you stop it, the better your chances of repairing the damage. But now, at this precise moment, I'm watching a lot of junk being generated on the server so, there is the source of the problem, I have a worm on my internal web server, no postfix issue. Another possibility, as you mentioned that this is the gateway for Postfix, is that it has a misconfigured firewall that is doing both source and destination NAT of port 25 to your Postfix. I just tested this, and was unable to connect to 200.55.14.250:25, so if that was the case, it is probably fixed now. -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Messages are stuck in maildrop
I had some issues with free disk space so I had to start the server, expand the partition and restart it again. I did the following: postsuper -r ALL It reported that it re-queued a bunch of messages and I can see that they're sitting in maildrop queue. postqueue -p reports that queue is empty (which one???) And those messages just sit there, pickup dameon is ignoring them. Where do I look? Thanks!
