http://permalink.gmane.org/gmane.mail.postfix.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.mail.postfix.user/188316 Bill Cole: If an MTA does does not announce DSN support, then the up-stream MTA is required to send the positive notification. What you would typically get is a notice that your message was given to the receiving party's mail server. Wietse Wietse Venema 2008-10-07T14:58:27 http://permalink.gmane.org/gmane.mail.postfix.user/188315 please do get a relay_recipients map. That way you block all mail at the gate which should not be there. Otherwise you are becoming a source of backscatter. We have a similar setup here. I have writtten a simple batch file which dumps all the e-mail addresses of AD to a file. I copy this file to the postfix gateway, a bit of perl and it is done. It is quite simple actually. the batch file uses adfind.exe (http://www.joeware.net/freetools/tools/adfind/index.htm) and pscp (from putty); you need to create a key to be able to copy the files to the unix host (but this is not the place to ask). I use a unix user at the postfix box with inlogname: exchangeuxdf -===============batch.bat================== < at >echo off d: cd d:\scripts\ldap adfind -sc exchaddresses:smtp > d:\scripts\ldap\virtual.txt pscp -i "d:\scripts\ldap\exchangeuser.ppk" "D:\Scripts\ldap\virtual.txt" exchangeuser< at >unixserver:/home/exchangeuser ============================================= adfind dumps all smtp addresses to the file virtual. Natxo Asenjo 2008-10-07T14:53:54 http://permalink.gmane.org/gmane.mail.postfix.user/188314 I have a weird issue where a sender with a valid reverse DNS entry is getting rejected. main.cf: === smtpd_delay_reject = yes smtpd_client_restrictions = ... reject_unknown_reverse_client_hostname Oct 4 19:04:21 postfix/smtpd[231]: connect from unknown[64.68.XXX.XXX] Oct 4 19:04:21 postfix/smtpd[231]: NOQUEUE: reject: RCPT from unknown[64.68.XXX.XXX]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [64.68.XXX.XXX]; from=<Y< at >Y.COM> to=<X< at >X.COM> proto=ESMTP helo=<Y.COM> Oct 4 19:04:21 smtp2-1 postfix/smtpd[231]: disconnect from unknown[64.68.XXX.XXX] # host 64.68.XXX.XXX XXX.XXX.68.64.in-addr.arpa domain name pointer BRYANLEX_lan_64.68.XXX.XXX.Z.TLD I've verified reverse DNS at www.dnswatch.info as well as all nameservers configured on the postfix system. The only possibility I see are the underscores. Other than that, the mail should have been let through. - Darek Darek M. 2008-10-07T14:49:46 http://permalink.gmane.org/gmane.mail.postfix.user/188313 Correct. See https://bugzilla.mozilla.org/show_bug.cgi?id=93085 The bottom line is that TBird 3 will have DSN support. The current "Shredder" and "Eudora 8" variants using 3.0a1 support it. He may get a little help from using the "Return Receipt" feature. That's done with headers and MUA's, so it is a bit less predictable than DSN's done at the SMTP level. On the other hand, DSN depends on all MTA's in the path supporting an extension to SMTP that some perceive as a threat to privacy and/or security. Bill Cole 2008-10-07T14:38:54 http://permalink.gmane.org/gmane.mail.postfix.user/188312 You have "smtpd_delay_reject = no" and are rejecting at CONNECT time. Clearly SASL login has not yet been performed at that point, and so "permit_sasl_authenticated" is a NOP. Victor Duchovni 2008-10-07T14:14:37 http://permalink.gmane.org/gmane.mail.postfix.user/188311 This server is only the secondary mail server for incoming mail, so it won't be bouncing anything just passing it onto the primary server which does perform valid recipient checks. I don't see any point doing it here too as it just means more hits against the AD servers for no greater effect, unless I needed to lessen the load on the primary MX server which I don't. That this wasn't evident might suggest I've configured it incorrectly to act as a secondary MX server. Paul Cocker Systems Infrastructure Support Network Administrator and Security Specialist -----Original Message----- From: owner-postfix-users< at >postfix.org [mailto:owner-postfix-users< at >postfix.org] On Behalf Of Brian Evans - Postfix List Sent: 06 October 2008 15:46 To: postfix-users< at >postfix.org Subject: Re: My first config - unable to telnet to port 25, virtual.db missing Paul Cocker wrote: previously. firewall/gateway' [...] No relay_recipient_maps? You seem to be heading to be a (Back|Out)scatter source. Highly suggest you have a static Paul Cocker 2008-10-07T14:06:50 http://permalink.gmane.org/gmane.mail.postfix.user/188310 <sigh> I'm really getting tired of getting hit in the head by cluesticks... Thanks Ralf... Charles Marcus 2008-10-07T13:31:52 http://permalink.gmane.org/gmane.mail.postfix.user/188309 * Charles Marcus <CMarcus< at >Media-Brokers.com>: Please read the docs carefully: To enable this feature, specify a non-zero time value (an integral value plus an optional one-letter suffix that specifies the time unit). Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks). The default time unit is h (hours). Meaning: It's disabled. Ralf Hildebrandt 2008-10-07T13:26:13 http://permalink.gmane.org/gmane.mail.postfix.user/188308 Hi, What is probably a *very* obvious question... Does the default: delay_warning_time = 0h really mean that the sender would get the warning immediately if the message wasn't able to be delivered immediately? Charles Marcus 2008-10-07T13:21:49 http://permalink.gmane.org/gmane.mail.postfix.user/188307 The client_access is empty for now. I only get the hostname not found errors, and when I comment out that restriction, then I can connect (and authenticate). postfix/smtpd[23810]: warning: 78.131.56.68: hostname 78-131-56-68.static.hdsnet.hu verification failed: no address associated with name postfix/smtpd[23810]: connect from unknown[78.131.56.68] postfix/smtpd[23810]: NOQUEUE: reject: CONNECT from unknown[78.131.56.68]: 450 4.7.1 Client host rejected: cannot find your hostname, [78.131.56.68]; proto=SMTP postfix/smtpd[23810]: disconnect from unknown[78.131.56.68] postfix/smtpd[23810]: warning: 78.131.56.68: hostname 78-131-56-68.static.hdsnet.hu verification failed: no address associated with name postfix/smtpd[23810]: connect from unknown[78.131.56.68] postfix/smtpd[23810]: NOQUEUE: reject: CONNECT from unknown[78.131.56.68]: 450 4.7.1 Client host rejected: cannot find your hostname, [78.131.56.68]; proto=SMTP postfix/smtpd[23810]: disconnect from unknown[78.131.56.68] postconf -n: alias_da LÉVAI Dániel 2008-10-07T13:13:20 http://permalink.gmane.org/gmane.mail.postfix.user/188306 If you do not have anything in place, I would recommend looking at the version 2 policyd that is more database backend agnostic. It is written in perl and uses DBD/DBI to connect to the backends. That way you can avoid being locked in to a particular database backend be it MySQL, PostgreSQL, Oracle, ... Ken Kenneth Marshall 2008-10-07T13:04:11 http://permalink.gmane.org/gmane.mail.postfix.user/188305 Ok... more confusion... 1. 'smtp.example.com' is not a 'domain', it is a host name. 2. My system has been setup forever with the following: mydomain = example.com mydestination = $myhostname, localhost.$mydomain, localhost myhostname = smtp.example.com (as per previously supplied postconf -n outpput) but, example.com (the domain, not the hostname) is also listed in virtual_mailbox_domains via the mysql lookup... Is this OK/normal? I'm thinking yes, because: 'smtp.example.com' != 'example.com' and the host/system has to have one (and only one?) FQDN? Thanks, and I appreciate your patience in helping me to understand the ramifications of adding virtual domains to my production system. Charles Marcus 2008-10-07T13:00:09 http://permalink.gmane.org/gmane.mail.postfix.user/188304 try (Cami's) policyd. it's written in C as a single threaded daemon. it uses mysql (myisam unfortunately!). Cami is no more working on it, but it's stable enough (and Cami used it in an ISP environment). it has other features (rate limiting, blacklist, whitelist, ...) check http://www.policyd.org/ and look at the "Old policyd V1". mouss 2008-10-07T12:58:52 http://permalink.gmane.org/gmane.mail.postfix.user/188303 there is something else! - make sure reject_unknown_client_hostname is really called. Logs are needed. - check whether it is not caused by client_access - check other restrictions. post the output of 'postconf -n' and relevant logs (showing the rejection). mouss 2008-10-07T12:53:40 http://permalink.gmane.org/gmane.mail.postfix.user/188302 Hi! I'm using postfix-2.5.4. I have this in my main.cf: smtpd_client_restrictions = check_client_access hash:/etc/postfix/client_access, permit_sasl_authenticated, reject_unknown_client_hostname It seems that the reject_unknown_client_hostname is applied always before the other rules, and I can not rely on the permit_sasl_authenticated rule to allow my connection always. Is this because of my "smtpd_delay_reject = no" setting, or is there something else? Thanks! LÉVAI Dániel 2008-10-07T12:42:01 http://permalink.gmane.org/gmane.mail.postfix.user/188301 We are using sqlgrey with a PostgreSQL backend for 6 MTA's and it works well, although the effectiveness of greylisting is declining. Ken Kenneth Marshall 2008-10-07T12:33:53 http://permalink.gmane.org/gmane.mail.postfix.user/188300 Yes it is.. It's pretty much a full featured spam fighting system that you can configure to your liking... But if all you want is grey listing, you can turn all the other checks off. It works real well, very active community and developer. On Oct 7, 2008, at 8:15 AM, Tom Allison wrote: -- Jason Pruim Raoset Inc. Technology Manager MQC Specialist 11287 James St Holland, MI 49424 www.raoset.com japruim< at >raoset.com Jason Pruim 2008-10-07T12:30:00 http://permalink.gmane.org/gmane.mail.postfix.user/188299 you only have the "current" recipient. if mail has multiple recipients, then the policy server is called for each recipient if the check is done at RCPT stage (so this doesn't apply to data stage, when you don't get the recipient(s)). not clear what you mean. defer causes the mail to stay on the "previous" MTA, if this is really an MTA. In case of ratware, the behaviour is unpredictable (ratware can retry or not). do you mean you want to defer the mail indéfinitely. you can use "defer", but be careful here. you'll have to be very selective because a false positive that is detected 5 days later is worst than one that is detected shortly. so "reject" is generally the way to go. don't think too much about zombies. defer won't help (they don't have to follow the smtp protocol!). and for real MTAs, it is unfriendly to delay mail too long. mouss 2008-10-07T12:29:07 http://permalink.gmane.org/gmane.mail.postfix.user/188298 yes. Ok passes the mail. no more checks in the same smtpd_mumble_restrictions. restriction classes are only a way to group multiple checks. mouss 2008-10-07T12:23:11 http://permalink.gmane.org/gmane.mail.postfix.user/188297 Please don't top post. put your replies after the text you reply to. google if this is not clear. you can have a periodic task to dump the users list. the list of valid users doesn't change often. if you are concerned about newly created users, you could work around this (tempfail at first try. similar to greylisting) but you'll need a log parser or a policy service to "update" the config. probably not worth the pain. alternatively, you can consider ldap replication. mouss 2008-10-07T12:20:10 http://permalink.gmane.org/gmane.mail.postfix.user/188296 Charles Marcus: If you list smtp.example.com as a virtual domain, then do not list it in mydestination. Wietse Wietse Venema 2008-10-07T12:19:25 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.postfix.user