Re: strange behaviour : incoming queue
On 12/07/2011 14:28, Wietse Venema wrote: Wietse Venema: If it's an abort in a library routine, then these instructions may help to identify the culprit. http://www.postfix.org/DEBUG_README.html#gdb Wietse morning List The output of the debugging as advised by Wietse produces as error as below: Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x7f5729ef2995 in waitpid () from /lib64/libc.so.6 (gdb) Continuing. Program received signal SIGPIPE, Broken pipe. 0x7f5729f16f90 in __write_nocancel () from /lib64/libc.so.6 (gdb) #0 0x7f5729f16f90 in __write_nocancel () from /lib64/libc.so.6 #1 0x7f572c21156c in master_notify () from /usr/lib64/libpostfix-master.so.1 #2 0x7f572c20f1a9 in ?? () from /usr/lib64/libpostfix-master.so.1 #3 0x7f572c20f4c3 in ?? () from /usr/lib64/libpostfix-master.so.1 #4 0x7f572b799412 in event_loop () from /usr/lib64/libpostfix-util.so.1 #5 0x7f572c20f099 in single_server_main () from /usr/lib64/libpostfix-master.so.1 #6 0x7f572c64099f in main () from /usr/lib/postfix/smtpd The installed OS is: SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 thx Tom
Re: Best method to post master.conf
Victor Duchovni: On Tue, Jul 12, 2011 at 05:56:42PM -0400, Jerry wrote: On Tue, 12 Jul 2011 17:35:56 -0400 Victor Duchovni articulated: Indeed. Returning to the original topic though, I have a postmast(1) patch that adds a new utility that does with master.cf what postconf(1) does with main.cf. In particular it supports: postmast - show all entries in a machine-parseable normal form postmast -n - show non-default entries postmast -d - show default entries postmast -e - edit or add master.cf entries via CLI. I don't whether this is of sufficiently broad utility to warrant inclusion in the official release. It gets a Thumbs Up from me. Perhaps a link similar to the postfinger tool might a adequate, although I favor the inclusion concept. The utility uses various Postfix library functions, and builds properly only within the Postfix source distribution, so if not adopted by Wietse, it would be an unofficial patch, and I don't think that releasing it as a patch makes much sense. If the community feels it's useful, perhaps Wietse will adopt it, otherwise it can quitely disappear... I think this is an example of 0.1% benefit. It makes the learning curve steeper, because it inserts an unfamiliar program between the user and an unfamiliar file format. It does not help the people who make the mistakes. Like other mistakes, this user's mistake could be addressed by adding an extra helpful error message to the master daemon (if the line starts with '-letter then it's pretty surely a bad line continuation). Wietse
Re: strange behaviour : incoming queue
Tom Kinghorn: On 12/07/2011 14:28, Wietse Venema wrote: Wietse Venema: If it's an abort in a library routine, then these instructions may help to identify the culprit. http://www.postfix.org/DEBUG_README.html#gdb Wietse morning List The output of the debugging as advised by Wietse produces as error as below: Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 0x7f5729ef2995 in waitpid () from /lib64/libc.so.6 (gdb) Continuing. Program received signal SIGPIPE, Broken pipe. This is irrelevant. SIGPIPE does not result in program abort. It happens routinely when yoiu execute postfix reload, or when a down-stream daemon dies. 0x7f5729f16f90 in __write_nocancel () from /lib64/libc.so.6 (gdb) #0 0x7f5729f16f90 in __write_nocancel () from /lib64/libc.so.6 #1 0x7f572c21156c in master_notify () from /usr/lib64/libpostfix-master.so.1 #2 0x7f572c20f1a9 in ?? () from /usr/lib64/libpostfix-master.so.1 #3 0x7f572c20f4c3 in ?? () from /usr/lib64/libpostfix-master.so.1 #4 0x7f572b799412 in event_loop () from /usr/lib64/libpostfix-util.so.1 #5 0x7f572c20f099 in single_server_main () from /usr/lib64/libpostfix-master.so.1 #6 0x7f572c64099f in main () from /usr/lib/postfix/smtpd This is irrelevant. This is not the cleanup daemon! Please can you at the very least instrument the RIGHT PROGRAM (cleanup), and please can you look for the RIGHT ERROR (signal 6). Wietse
Re: Best method to post master.conf
On Wed, Jul 13, 2011 at 07:07:25AM -0400, Wietse Venema wrote: The utility uses various Postfix library functions, and builds properly only within the Postfix source distribution, so if not adopted by Wietse, it would be an unofficial patch, and I don't think that releasing it as a patch makes much sense. If the community feels it's useful, perhaps Wietse will adopt it, otherwise it can quitely disappear... I think this is an example of 0.1% benefit. It makes the learning curve steeper, because it inserts an unfamiliar program between the user and an unfamiliar file format. It does not help the people who make the mistakes. Like other mistakes, this user's mistake could be addressed by adding an extra helpful error message to the master daemon (if the line starts with '-letter then it's pretty surely a bad line continuation). Not claiming that postconf(1) will protect users from themselves, it is just a CLI for querying and modifying master.cf. Indeed for most users vi(1) is just fine. POSTMAST(1) POSTMAST(1) NAME postmast - Postfix master.cf command-line editor SYNOPSIS postmast [-c config_dir] [-dn] [-s service] [-t type] postmast [-c config_dir] -e definition -s service -t type postmast [-c config_dir] -# [-s service] -t type So one can list the definition (or the default definition, or a non-default definition) of all services or a specific service or service type. Or edit the definition of a service, or comment-out a service. I agree it is not essential. I'll just keep it in-house... -- Viktor.
reject mail to undisclosed recipients and with our addresses in From:
Hello, is it possible to reject/redirect on postfix level (to a spam catcher account we monitor) - - all mail sent to undisclosed recipients - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) For the second case I read about SPF, but as far as I understand SPF is for the others to check if e-mail originates from us and it seems it is not simple to implement (at least I read about drawbacks). What I am thinking is of a way to prevent spoofed our addresses reaching our recipients. Thank you very much, Geert
Re: reject mail to undisclosed recipients and with our addresses in From:
On Wed, Jul 13, 2011 at 04:57:02PM +0200, Geert Mak wrote: is it possible to reject/redirect on postfix level (to a spam catcher account we monitor) - - all mail sent to undisclosed recipients Why not focus on spam, rather than weakly correlated factors. It is probably best to deploy a decent spam filter. - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) This would be a mistake. For example, you'd never see your own posts to this list. This said, you may find that filtering the envelope sender (rather than the From: header) is reasonably effective. The main collateral damage is forward an article newspaper sites, ... which send email with envelope address set to the visitor's alleged address. -- Viktor.
Re: reject mail to undisclosed recipients and with our addresses in From:
On 13.07.2011, at 17:07, Victor Duchovni wrote: On Wed, Jul 13, 2011 at 04:57:02PM +0200, Geert Mak wrote: is it possible to reject/redirect on postfix level (to a spam catcher account we monitor) - - all mail sent to undisclosed recipients Why not focus on spam, rather than weakly correlated factors. It is probably best to deploy a decent spam filter. We have Spamassassin. But I thought that this is a simple enough case to be handled directly on Postfix level before even entering Spamassassin. - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) This would be a mistake. For example, you'd never see your own posts to this list. Oh... I see. This said, you may find that filtering the envelope sender (rather than the From: header) is reasonably effective. The main collateral damage is forward an article newspaper sites, ... which send email with envelope address set to the visitor's alleged address. I see, this seems not an easy one. Thank you! Geert
Re: reject mail to undisclosed recipients and with our addresses in From:
Am 13.07.2011 17:07, schrieb Victor Duchovni: - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) This would be a mistake. For example, you'd never see your own posts to this list you missed that the envelope-from is relevant and correct form the mailing-list because it must not send with foreign envelopes Sender: owner-postfix-us...@postfix.org Return-Path: owner-postfix-us...@postfix.org signature.asc Description: OpenPGP digital signature
Backscatter Email
Hi All, can anyone advise on how to effectively fight backscatter email. Below a typical header of the tons of backscatter email users get a day Return-Path: MAILER-DAEMON X-Original-To: u...@domain.tld Delivered-To: u...@domain.tld Received: from host.domain.tld (unknown [xxx.xxx.xxx.xx]) by mail.domain.tld (Postfix) with ESMTP id 3A23B8A037; Wed, 13 Jul 2011 07:13:39 -0700 (PDT) Received: from host.domain.tld (localhost [127.0.0.1]) by host.domain.tld (Postfix) with ESMTP id ED8D5958D5 for u...@domain.tld; Wed, 13 Jul 2011 07:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at domain.tld X-Spam-Flag: NO X-Spam-Score: 4.137 X-Spam-Level: X-Spam-Status: No, score=4.137 tagged_above=-999 required=6.31 tests=[BAYES_50=1.8, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, URIBL_BLACK=1.725, URIBL_PH_SURBL=0.61] autolearn=no Received: from host.domain.tld ([127.0.0.1]) by host.domain.tld (host.domain.tld [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72CZSuHVXXm4 for u...@domain.tld; Wed, 13 Jul 2011 07:13:41 -0700 (PDT) Received: from ucmx01.uzuncase.com (66-193-162-90.static.twtelecom.net [66.193.162.90]) by host.domain.tld (Postfix) with ESMTP id AF131958C7 for u...@domain.tld; Wed, 13 Jul 2011 07:13:41 -0700 (PDT) Received: from ucmail.UZUN_CASE_NT.COM ([192.168.13.6]) by ucmx01.uzuncase.com (8.13.8/8.13.8) with ESMTP id p6DEDcKT009597 for u...@domain.tld; Wed, 13 Jul 2011 10:13:38 -0400 Received: from ucmail.UZUN_CASE_NT.COM ([192.168.13.5] helo=ucmail.UZUN_CASE_NT.COM) by ASSP.nospam; 13 Jul 2011 10:13:38 -0400 From: postmas...@uzuncase.com To: u...@domain.tld Date: Wed, 13 Jul 2011 10:13:48 -0400 MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=9B095B5ADSN=_01CC411EFEA4113201C0ucmail.UZUN_CASE X-DSNContext: 335a7efd - 4523 - 0001 - 80040546 Message-ID: yA67JYZWL000a@ucmail.UZUN_CASE_NT.COM Subject: Delivery Status Notification (Failure) X-Assp-Re-Red: Content-Type: multipart/report I know this is Postfix list but here is my Amavisd-new $sa_tag_level_deflt = -999; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 6.11; # add 'spam detected' headers at that level $sa_kill_level_deflt = 6.31; # triggers spam evasive actions (e.g. blocks mail) $sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sent $sa_crediblefrom_dsn_cutoff_level = 18; # likewise, but for a likely valid From Any suggestions are welcome, thanks in Advance. -Motty
Re: reject mail to undisclosed recipients and with our addresses in From:
On 2011-07-13 17:51:40 (+0200), Geert Mak po...@verysmall.org wrote: On 13.07.2011, at 17:07, Victor Duchovni wrote: On Wed, Jul 13, 2011 at 04:57:02PM +0200, Geert Mak wrote: is it possible to reject/redirect on postfix level (to a spam catcher account we monitor) - - all mail sent to undisclosed recipients Why not focus on spam, rather than weakly correlated factors. It is probably best to deploy a decent spam filter. We have Spamassassin. But I thought that this is a simple enough case to be handled directly on Postfix level before even entering Spamassassin. - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) This would be a mistake. For example, you'd never see your own posts to this list. Oh... I see. This said, you may find that filtering the envelope sender (rather than the From: header) is reasonably effective. The main collateral damage is forward an article newspaper sites, ... which send email with envelope address set to the visitor's alleged address. I see, this seems not an easy one. It isn't that hard to set up actually using restriction stages. 1. Make sure your own outbound traffic is allowed out 2. Everything that reaches this step is coming from outside (inbound) and should not have your domain(s) in their envelope. You can implement these steps with check_sender_access and check_client_access The newspaper sites mentioned above are, in my opinion, doing the wrong thing by spoofing their envelopes. Thank you! Geert
Re: Backscatter Email
On 7/13/2011 12:04 PM, motty.cruz wrote: Hi All, can anyone advise on how to effectively fight backscatter email. Below a typical header of the tons of backscatter email users get a day Start here: http://www.postfix.org/BACKSCATTER_README.html Since you're using amavisd-new, investigate the PenPals and BounceKiller features, which are very effective. More info and followup on the amavisd-users list. -- Noel Jones
Re: Backscatter Email
Le 13/07/2011 19:04, motty.cruz a écrit :
Hi All, can anyone advise on how to effectively fight backscatter email.
Below a typical header of the tons of backscatter email users get a day
Return-Path: MAILER-DAEMON
X-Original-To: u...@domain.tld
Delivered-To: u...@domain.tld
Received: from host.domain.tld (unknown [xxx.xxx.xxx.xx])
by mail.domain.tld (Postfix) with ESMTP id 3A23B8A037;
Wed, 13 Jul 2011 07:13:39 -0700 (PDT)
Received: from host.domain.tld (localhost [127.0.0.1])
by host.domain.tld (Postfix) with ESMTP id ED8D5958D5
for u...@domain.tld; Wed, 13 Jul 2011 07:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at domain.tld
X-Spam-Flag: NO
X-Spam-Score: 4.137
X-Spam-Level:
X-Spam-Status: No, score=4.137 tagged_above=-999 required=6.31
tests=[BAYES_50=1.8, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001,
URIBL_BLACK=1.725, URIBL_PH_SURBL=0.61] autolearn=no
Received: from host.domain.tld ([127.0.0.1])
by host.domain.tld (host.domain.tld [127.0.0.1]) (amavisd-new, port
10024)
with ESMTP id 72CZSuHVXXm4 for u...@domain.tld;
Wed, 13 Jul 2011 07:13:41 -0700 (PDT)
Received: from ucmx01.uzuncase.com (66-193-162-90.static.twtelecom.net
[66.193.162.90])
by host.domain.tld (Postfix) with ESMTP id AF131958C7
for u...@domain.tld; Wed, 13 Jul 2011 07:13:41 -0700 (PDT)
Received: from ucmail.UZUN_CASE_NT.COM ([192.168.13.6])
by ucmx01.uzuncase.com (8.13.8/8.13.8) with ESMTP id p6DEDcKT009597
for u...@domain.tld; Wed, 13 Jul 2011 10:13:38 -0400
Received: from ucmail.UZUN_CASE_NT.COM ([192.168.13.5]
helo=ucmail.UZUN_CASE_NT.COM)
by ASSP.nospam; 13 Jul 2011 10:13:38 -0400
From: postmas...@uzuncase.com
To: u...@domain.tld
Date: Wed, 13 Jul 2011 10:13:48 -0400
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary=9B095B5ADSN=_01CC411EFEA4113201C0ucmail.UZUN_CASE
X-DSNContext: 335a7efd - 4523 - 0001 - 80040546
Message-ID: yA67JYZWL000a@ucmail.UZUN_CASE_NT.COM
Subject: Delivery Status Notification (Failure)
X-Assp-Re-Red: Content-Type: multipart/report
you might start with
/^(\d+\W){4}.*\.twtelecom\.net$/
REJECT generic hostname. please use your ISP or fix your DNS.
you can do a lot of other things, but the body of the backscatter is
probably the first thing to look at. unfortunately, you omitted it...
I know this is Postfix list but here is my Amavisd-new
I confirm. amavisd-new and spamassassin are off topic here. so I'm not
gonna debate why you changed the threshold from 5 to 6.31 on this list.
we can talk about this on the SA users list.
$sa_tag_level_deflt = -999; # add spam info headers if at, or above that
level
that's 3 halves of the devil number:) use
$sa_tag_level_deflt = undef;
$sa_tag2_level_deflt = 6.11; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 6.31; # triggers spam evasive actions (e.g. blocks
mail)
$sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sent
$sa_crediblefrom_dsn_cutoff_level = 18; # likewise, but for a likely valid
From
Any suggestions are welcome, thanks in Advance.
-Motty
Re: reject mail to undisclosed recipients and with our addresses in From:
Le 13/07/2011 18:22, Reindl Harald a écrit : Am 13.07.2011 17:07, schrieb Victor Duchovni: - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) This would be a mistake. For example, you'd never see your own posts to this list you missed that the envelope-from is relevant read OP message again. OP is talking about From:, which in our terminology means the From header, not the envelope sender. and correct form the mailing-list because it must not send with foreign envelopes Sender: owner-postfix-us...@postfix.org not all lists specify a Sender: header, and anyway, this header is problematic... it works ok if only one node adds it. unclear what should happen in a multi-node travel... Return-Path: owner-postfix-us...@postfix.org Return-Path is added at delivery time. it should not appear on the wire.
RE: Backscatter Email
- Цитат от motty.cruz (motty.c...@gmail.com), на 13.07.2011 в 20:04 - Hi All, can anyone advise on how to effectively fight backscatter email. ... Any suggestions are welcome, thanks in Advance. -Motty I have written a TCP table for signing outgoing mails using prvs scheme and a policy in order to check if a bounce mail is signed (valid). It integrates directly in postfix. The sources and a short README could be found here: https://github.com/luben/postfix-utils If you have questions I am here to answer. BTW, there is also a greylisting server with memcached backend at the same place. Best regards -- Luben Karavelov
Re: reject mail to undisclosed recipients and with our addresses in From:
On 7/13/2011 10:51 AM, Geert Mak wrote: On 13.07.2011, at 17:07, Victor Duchovni wrote: On Wed, Jul 13, 2011 at 04:57:02PM +0200, Geert Mak wrote: is it possible to reject/redirect on postfix level (to a spam catcher account we monitor) - - all mail sent to undisclosed recipients You could use header_checks and a PCRE to reject or redirect all such mail addressed to undisclosed recipients, but given how often this is used legitimately, I don't think it wise to filter on this criteria alone. It would be better to have SA bump the score up a bit with a custom rule. Why not focus on spam, rather than weakly correlated factors. It is probably best to deploy a decent spam filter. We have Spamassassin. But its effectiveness relies on how well you tune it to your environment and mail flow. But I thought that this is a simple enough case to be handled directly on Postfix level before even entering Spamassassin. It could very well be. But you need to be looking more at the characteristics of the sending hosts, not the message content. Remember this valuable phrase: Spam is defined by *consent* not *content*. Reject those senders who do not have consent to send mail to your users. Almost all spam sending hosts can be relatively easily rejected with fairly simply countermeasures. It's the spam that comes from primarily ham hosts that can't be blocked via these means, such as phished webmail or gorilla (Gmail, Hotmail, etc) mail servers. That's where a well tuned content filter comes in handy. - all mail sent with our addresses in From: but not originating from us (or mail server is in-house, one server with one IP) This would be a mistake. For example, you'd never see your own posts to this list. Oh... I see. This said, you may find that filtering the envelope sender (rather than the From: header) is reasonably effective. The main collateral damage is forward an article newspaper sites, ... which send email with envelope address set to the visitor's alleged address. I see, this seems not an easy one. Many people use what Viktor mentions here and it can be very effective against forged mail. However, there may be better ways to combat forged mail. In my experience most forged mail is sent from bot infected PCs, some from phished webmail accounts, almost never from snowshoe farms. You can stop such spam easily using many techniques, including the CBL and PBL (included in the Spamhaus Zen dnsbl) and other dnsbls, with greylisting, or with a PCRE file that targets hosts with generic rDNS (mainly residential broadband PCs). Many people use a combination of 2 or all 3. The more you use the greater the load on the server. Using a dnsbl, or many of them, incurs a per message lookup delay of tends to hundreds of milliseconds per message, more if a timeout occurs due to network conditions in reaching the remote dnsbl server. Using greylisting inserts a delivery delay, often less than 5 minutes, potentially up to 30 minutes or more, for legit mail (unless done selectively). Using a PCRE file with a REJECT action incurs no delays of any kind. You can combine the above techniques, such that a match in the PCRE file returns a dnsbl lookup or greylist action instead of an outright rejection. Or, you can PREPEND a header that SA can then use to increase the spam score. A fairly complex Postfix configuration is required when combining these countermeasures. Such a PCRE file that targets hosts with generic rDNS can be found here: http://www.hardwarefreak.com/fqrdns.pcre The default version rejects on most matches, but it does a PREPEND for some rDNS patterns which include many ham hosts, mostly SOHO connections. The default setup works very well. A number of list members use it but I don't have a count. It's very easy to implement with concise instructions at the top of the file. Give it a shot and see if it helps. The resource footprint is tiny. Post a sample (dozen or so) of the IP addresses sending you this mail with undisclosed recipients and that which is forged with your own domain. I'd like to see what categories these hosts fall into to give you the best recommendation for means to combat it, if not already mentioned above. -- Stan
CentOS 6: Good News and Bad News
Yes, I realize that many on this list are not CentOS fans, but the RHEL distro it's based on is the only one officially supported on a big chunk of our hardware (some older Dell boxes) so it's what we use. And because it's free, it's also used by a good number of sysadmins. So the GOOD news is that after installing the recently released CentOS 6, I discovered that Sendmail is no longer the default MTA. The default is Postfix. Yay! Of course, that's old news to anyone running the full blown RHEL6, but I thought it was cool anyway. Congrats, Wietse. :) The BAD news is that while the installed version is newer than 2.3.3 (which was in CentOS 5), it's only 2.6.6. I suppose that's still progress, but I'm working on an updated version of my Installing the latest Postfix on CentOS blog article to walk people through using a spec file to build their own 2.8.4 RPM and upgrade with it. SteveJ
Re: Backscatter Email
On 7/13/2011 3:08 PM, mouss wrote:
Le 13/07/2011 19:04, motty.cruz a écrit :
Received: from ucmx01.uzuncase.com (66-193-162-90.static.twtelecom.net
[66.193.162.90])
you might start with
/^(\d+\W){4}.*\.twtelecom\.net$/
REJECT generic hostname. please use your ISP or fix your DNS.
This wouldn't be wise mouss. It would reject all mail from a legit
site. This is a SOHO IP range in Georgia, USA, occupied by an
engineering firm, Uzune Case. The bounce originated from a mail host
well behind their MX. Uzune Case obviously need better anti spam
measures themselves, but that's a another issue.
Rejecting all of their mail simply based on the generic rDNS of their
outbound MTA is a wrong move, especially since the string clearly
identifies a static range. fqrdns.pcre would have returned a PREPEND on
this rDNS, not a REJECT, and for good reason.
Simply eliminating backscatter altogether as Noel mentioned is a better
course of action.
--
Stan
Re: CentOS 6: Good News and Bad News
Steve Jenkins: Yes, I realize that many on this list are not CentOS fans, but the RHEL distro it's based on is the only one officially supported on a big chunk of our hardware (some older Dell boxes) so it's what we use. And because it's free, it's also used by a good number of sysadmins. So the GOOD news is that after installing the recently released CentOS 6, I discovered that Sendmail is no longer the default MTA. The default is Postfix. Yay! Of course, that's old news to anyone running the full blown RHEL6, but I thought it was cool anyway. Congrats, Wietse. :) The BAD news is that while the installed version is newer than 2.3.3 (which was in CentOS 5), it's only 2.6.6. I suppose that's still progress, but I'm working on an updated version of my Installing the latest Postfix on CentOS blog article to walk people through using a spec file to build their own 2.8.4 RPM and upgrade with it. Good idea. Postfix 2.6 author support will cease in about 1.5 years. Wietse
Re: Backscatter Email
Am 14.07.2011 01:28, schrieb Stan Hoeppner:
On 7/13/2011 3:08 PM, mouss wrote:
Le 13/07/2011 19:04, motty.cruz a écrit :
Received: from ucmx01.uzuncase.com (66-193-162-90.static.twtelecom.net
[66.193.162.90])
you might start with
/^(\d+\W){4}.*\.twtelecom\.net$/
REJECT generic hostname. please use your ISP or fix your DNS.
This wouldn't be wise mouss. It would reject all mail from a legit
site. This is a SOHO IP range in Georgia, USA, occupied by an
engineering firm, Uzune Case.
SOHO or not: ip-addresses in PTR are mostly not real mailservers
or maintained by foolish administrators because someone
with a little knowledge would call the A/PTR mail.twtelecom.net
or smtp.twtelecom.net
Rejecting all of their mail simply based on the generic rDNS of their
outbound MTA is a wrong move
no it is the right move
especially since the string clearly
identifies a static range
what has nothing to do with mailserver or not
we own also a static /24 range and on this range are some
mailservers, but this does not change anything in the fact
that a infected workstation would come out with one of
this IP-Addresses but NOT with a mail-hostname
signature.asc
Description: OpenPGP digital signature
constant relay access denied on VPS
I have a VPS with several virtual domains, first-one.domain1.com second-one.domain2.com and third-one.domain3.com I can send OUT from these domains and other domains receive the emails, but when replying to those very same messages, postfix is refusing to deliver them and sends back the following error messages: Delivery to the following recipient failed permanently: du...@domain1.com du...@whosbeenlooking.com Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.7.1 du...@domain1.com du...@whosbeenlooking.com: Relay access denied (state 14). I am afraid to mess with the main.cf but have reproduced it below using postconf -n, as well as posting the output of hosts and hostname. Looking for a guru to quickly tell me what must be wrong and obvious to him/her but not to me. thanks. $ hostname: first-one.domain1.com more /etc/hosts: 127.0.0.1 localhost.localdomain localhost # Auto-generated hostname. Please do not remove this comment. first-one.domain1.com first-one output of postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/var/spool/postfix/plesk/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix debug_peer_level = 2 disable_vrfy_command = yes home_mailbox = Maildir/ html_directory = no inet_interfaces = all inet_protocols = all mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man message_size_limit = 1024 mydestination = localhost.$mydomain, localhost, localhost.localdomain myhostname = first-one.domain1.com mynetworks = 127.0.0.0/8 newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES sample_directory = /usr/share/doc/postfix-2.3.3/samples sender_dependent_default_transport_maps = regexp:/etc/postfix/sdd_transport_maps.regexp sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_send_xforward_command = yes smtp_tls_security_level = may smtp_use_tls = no smtpd_authorized_xforward_hosts = 127.0.0.0/8 [::1]/128 smtpd_client_restrictions = smtpd_proxy_timeout = 3600s smtpd_recipient_restrictions = permit_mynetworks, check_client_access pcre:/var/spool/postfix/plesk/no_relay.re, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sender_restrictions = check_sender_access hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated, check_client_access pcre:/var/spool/postfix/plesk/non_auth.re smtpd_timeout = 3600s smtpd_tls_cert_file = /etc/postfix/postfix_default.pem smtpd_tls_key_file = $smtpd_tls_cert_file smtpd_tls_security_level = may smtpd_use_tls = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = $virtual_maps, hash:/var/spool/postfix/plesk/virtual virtual_gid_maps = static:31 virtual_mailbox_base = /var/qmail/mailnames virtual_mailbox_domains = $virtual_mailbox_maps, hash:/var/spool/postfix/plesk/virtual_domains virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox virtual_transport = plesk_virtual virtual_uid_maps = static:110
Re: constant relay access denied on VPS
Sent from my BlackBerry device on the Rogers Wireless Network
Re: constant relay access denied on VPS
This might seem obvious, but do you have your actual domain in mydestination in your main.cf file? AK Sent from my BlackBerry device on the Rogers Wireless Network
Re: constant relay access denied on VPS
Well that helped, sort of... I added domain1.com to the mydestinations in main.cf and now I'm getting a different error message: User unknown in local recipient table (state 14). At least it's a different error message than before which was relay-access denied. Should I regenerate the recipient table and if so, how is that done (if that's the problem). Thanks Delivery to the following recipient failed permanently: du...@domain1.com du...@whosbeenlooking.com Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 5.1.1 du...@domain1.com du...@whosbeenlooking.com: Recipient address rejected: User unknown in local recipient table (state 14). On Wed, Jul 13, 2011 at 8:42 PM, aly.khi...@gmail.com wrote: This might seem obvious, but do you have your actual domain in mydestination in your main.cf file? AK Sent from my BlackBerry device on the Rogers Wireless Network
Re: constant relay access denied on VPS
Jeffrey, Does the user dukey actually exist in your recipient table? As you are using a VPS with plesk it looks like the mailboxes are probably made from the control panel in plesk virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox Check in your control panel. btw this means now your mail server is accepting mail for your domain, but its being rejected because that user dukey isn't found. AK Sent from my BlackBerry device on the Rogers Wireless Network
Re: constant relay access denied on VPS
On 7/13/2011 7:37 PM, jeffrey starin wrote: I have a VPS with several virtual domains, first-one.domain1.com http://first-one.domain1.com second-one.domain2.com http://second-one.domain2.com and third-one.domain3.com http://third-one.domain3.com Please send in plain text next time so we don't have to wade through the html markup. I can send OUT from these domains and other domains receive the emails, but when replying to those very same messages, postfix is refusing to deliver them and sends back the following error messages: Delivery to the following recipient failed permanently: du...@domain1.com mailto:du...@whosbeenlooking.com Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 554 554 5.7.1 du...@domain1.com mailto:du...@whosbeenlooking.com: Relay access denied (state 14). We would strongly prefer the postfix logs, which are generally more informative. Anyway, this basically says that postfix doesn't know that domain. Since it looks as if you're using plesk, make sure your domains are listed wherever they should be in your plesk control panel. Postfix docs are here: http://www.postfix.org/BASIC_CONFIGURATION_README.html http://www.postfix.org/STANDARD_CONFIGURATION_README.html http://www.postfix.org/VIRTUAL_README.html http://www.postfix.org/documentation.html If you need more help, please see: http://www.postfix.org/DEBUG_README.html#mail -- Noel Jones
Re: constant relay access denied on VPS
dukey exists and I can login to domain1.com as dukey and check emails using horde. I can send email FROM dukey to email addresses in other domains, and they are received, but as stated in my first email, no one can respond to those emails because they are receiving the following error message back: Recipient address rejected: User unknown in local recipient table (state 14). On Wed, Jul 13, 2011 at 9:18 PM, aly.khi...@gmail.com wrote: Jeffrey, Does the user dukey actually exist in your recipient table? As you are using a VPS with plesk it looks like the mailboxes are probably made from the control panel in plesk virtual_mailbox_maps = hash:/var/spool/postfix/plesk/vmailbox Check in your control panel. btw this means now your mail server is accepting mail for your domain, but its being rejected because that user dukey isn't found. AK Sent from my BlackBerry device on the Rogers Wireless Network
Re: constant relay access denied on VPS
Am 14.07.2011 03:49, schrieb jeffrey starin: dukey exists and I can login to domain1.com as dukey and check emails using horde this means NOT that it exists for postfix because POP3/IMAP/Webmail (Receive) has nothing to do with postfix I can send email FROM dukey to email addresses in other domains which means nothing as long there are no restrictions configured (smtpd_sender_restrictions) and they are received only if the destination makes no sender verify but as stated in my first email, no one can respond to those emails because they are receiving the following error message back: Recipient address rejected: User unknown in local recipient table (state 14) look back at your first steps on this topic at the begin your postfix did even not know your domains now it knows your domains but no users no idea how PLESK configures local_recipient_maps and what exactly you can touch on your config files without confuse PLESK (that is why i use never such generic GUIs) but my conclusion is that this server is configured with too few knowledge of what doing which is a dangerous game as long speaking froma public mailserver these days signature.asc Description: OpenPGP digital signature
Re: constant relay access denied on VPS
Considering that tables are hashed in postfix, it would be helpful if there was a utility or a method to un-hash the tables and actually see what's in there. Is there a method to un-hash postfix tables and see what is inside them? Thanks. On Wed, Jul 13, 2011 at 9:58 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 14.07.2011 03:49, schrieb jeffrey starin: dukey exists and I can login to domain1.com as dukey and check emails using horde this means NOT that it exists for postfix because POP3/IMAP/Webmail (Receive) has nothing to do with postfix I can send email FROM dukey to email addresses in other domains which means nothing as long there are no restrictions configured (smtpd_sender_restrictions) and they are received only if the destination makes no sender verify but as stated in my first email, no one can respond to those emails because they are receiving the following error message back: Recipient address rejected: User unknown in local recipient table (state 14) look back at your first steps on this topic at the begin your postfix did even not know your domains now it knows your domains but no users no idea how PLESK configures local_recipient_maps and what exactly you can touch on your config files without confuse PLESK (that is why i use never such generic GUIs) but my conclusion is that this server is configured with too few knowledge of what doing which is a dangerous game as long speaking froma public mailserver these days
Re: constant relay access denied on VPS
On Wed, Jul 13, 2011 at 10:01:56PM -0400, jeffrey starin wrote: Considering that tables are hashed in postfix, it would be helpful if there was a utility or a method to un-hash the tables and actually see what's in there. Is there a method to un-hash postfix tables and see what is inside them? postmap -s works with a number of table types. -- Viktor.
Re: constant relay access denied on VPS
The mystery deepens. When I run postmap -s virtual I do don't see dukey but do see users I never created. So, how does one recreate the necessary tables? that is, make new hash maps. Thanks you. On Wed, Jul 13, 2011 at 10:03 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Jul 13, 2011 at 10:01:56PM -0400, jeffrey starin wrote: Considering that tables are hashed in postfix, it would be helpful if there was a utility or a method to un-hash the tables and actually see what's in there. Is there a method to un-hash postfix tables and see what is inside them? postmap -s works with a number of table types. -- Viktor.
Re: constant relay access denied on VPS
Am 14.07.2011 04:12, schrieb jeffrey starin: The mystery deepens. When I run postmap -s virtual I do don't see dukey but do see users I never created. So, how does one recreate the necessary tables? that is, make new hash maps. since you are using some plesk system i would recommend using a plesk mailing-list and if there are really users which noone knows from where they are think about is this machine probably hacked signature.asc Description: OpenPGP digital signature
Re: constant relay access denied on VPS
Thank you for your help. There is just too much wrong with this installation. I've decided that I will just nuke the whole installation and start over. Thanks for everyone's help along the way. On Wed, Jul 13, 2011 at 10:03 PM, Victor Duchovni victor.ducho...@morganstanley.com wrote: On Wed, Jul 13, 2011 at 10:01:56PM -0400, jeffrey starin wrote: Considering that tables are hashed in postfix, it would be helpful if there was a utility or a method to un-hash the tables and actually see what's in there. Is there a method to un-hash postfix tables and see what is inside them? postmap -s works with a number of table types. -- Viktor.
Re: Backscatter Email
On 7/13/2011 6:47 PM, Reindl Harald wrote: SOHO or not: ip-addresses in PTR are mostly not real mailservers The operative word here is mostly. For instance, my outbound: $ dig mx hardwarefreak.com hardwarefreak.com. IN MX 10 greer.hardwarefreak.com. greer.hardwarefreak.com. IN A 65.41.216.221 $ host 65.41.216.221 221.216.41.65.in-addr.arpa - mo-65-41-216-221.sta.embarqhsd.net. $ dig TXT hardwarefreak.com hardwarefreak.com. IN TXT v=spf1 ip4:65.41.216.221 -all Am I a foolish administrator simply due to having generic rDNS? Am I a spammer? Has spam ever emitted from this IP address? Do I have control over my rDNS string? The answer to all 4 is NO. Yet you're recommending to all on this list to summarily block email from my outbound. Rejecting all of their mail simply based on the generic rDNS of their outbound MTA is a wrong move no it is the right move Most of the world disagrees with you in this regard Reindl. Many on this list probably do as well. especially since the string clearly identifies a static range what has nothing to do with mailserver or not we own also a static /24 range and on this range are some mailservers, but this does not change anything in the fact that a infected workstation would come out with one of this IP-Addresses but NOT with a mail-hostname If you have read my posts you've seen that I'm obviously a big proponent of blocking clients based on dynamic/generic rDNS. But there is a right and wrong way of doing it. Simply blocking it all is the wrong way. Some intelligence gathering must be done to identify primarily ham sending static IP hosts with generic rDNS strings and treating those differently than primarily spam sending clients with dynamic/generic rDNS and dynamic/static IPs. Some such research went into fqrdns.pcre. Again, you need to understand Reindl that not all providers offer custom rDNS to their customers, and not everyone has multiple choice of service. My provider, CenturyLink has a local monopoly. They do not offer custom rDNS, period, no matter how nicely one asks. Your position seems to be that any sending host with generic rDNS should be treated as a spam source and blocked. It is your personal choice to do so, but you're doing a disservice to others by recommending that _everyone_ do so. In 2011 this is not generally acceptable practice. -- Stan
