Re: Multiple Mail domains for reverse ptr records? I'm confused
At Fri, 27 Nov 2009 13:18:15 -0500 (EST), wie...@porcupine.org (Wietse Venema) wrote: Subject: Re: Multiple Mail domains for reverse ptr records? I'm confused > > Wietse Venema: > > Greg A. Woods: > > > There _should_ be one PTR for every _valid_ hostname using a given IP > > > address. > > > > Statements such as above remind me of silly knights fighting windmills. > > > > There is a difference between "right" and "useful", and it even > > depends on where they are used - server or client side. Indeed -- I do not disagree. However I tried to emphasise the important words above in what you quoted. Also, don't forget the human use of the DNS either. I.e. it is _always_ useful from _some_ perspective to have a valid PTR for every valid hostname which may be considered to be legitimately pointing to a given address. Other hostnames which point to an address but which are not pointed to by a corresponding PTR _may_ be useful in some context, however neither man nor machine will be able to identify their validity from afar. Only the legitimate "owner" of the IP address will be able to claim anything about the validity of the hostnames which may be pointing to that address, and by definition without using PTRs that cannot be done in the context of the DNS. > > Multiple server A records are useful. More in the case of HTTP, > > less in the case of SMTP which uses indirection via MX records. > > (For a discussion about domain-in-a-box applications, see some > > actual measurements that I did earlier this year). > > > > One PTR per A record is not useful. The server end will not know > > what client name to use. > > That is, one PTR per A record, in the case of multiple A records > for the same IP address. Well it all depends on how the client/server protocol interaction works, doesn't it? As you suggest, for SMTP the client tells the server which hostname it should care about, so the server need not wonder which client name is being used. > > On the other hand, it is right when every PTR record has a matching > > A record that resolves to (among others) the PTR record's address. Indeed. Orthogonality goes both ways! :-) -- Greg A. Woods +1 416 218-0098VE3TCP RoboHack Planix, Inc. Secrets of the Weird pgp6r4YhW7E3m.pgp Description: PGP signature
Re: Multiple Mail domains for reverse ptr records? I'm confused
At Sat, 28 Nov 2009 00:16:58 +0100, mouss wrote: Subject: Re: Multiple Mail domains for reverse ptr records? I'm confused > > Greg A. Woods a écrit : > > At Wed, 25 Nov 2009 21:51:15 +0100, mouss wrote: > > Subject: Re: Multiple Mail domains for reverse ptr records? I'm confused > > I didn't wrote this. if you can't use a mailer correctly, try an easier > sport. I quoted the "Subject:" header field content of a message you wrote. Please learn to read common-format attributions correctly. :-) > PS. Next time, avoid CC-ing me. Please set the "reply-to:" header field to a value which reflects your expressed wishes. That way most software, including the software I use, will do your bidding. > > [snip] > > A hostname cannot be verified, either manually or by machine, as "valid" > > in the DNS unless a corresponding PTR points back at it. > > when you'll find the PTR that points back to www.ietf.org, Yes, the ietf.org zone is very lame: $ host -A www.ietf.org *** Hostname www.ietf.org does not belong to address 64.170.98.32 *** Not all addresses for hostname www.ietf.org have a matching hostname. Seems they think their WWW service hostname is most important. Just because the ietf.org domain name is managed on behalf of the organisation which helps coordinate development and publications of Internet standards doesn't mean those who operate it will always do everything possible to meet all best practises. I'm sure you know the story about the cobbler's children who went barefoot. In fact it appears the ietf.org zone is managed by a group that looks decidedly less technical than you might have guessed. They could easily fix the reverse DNS by adding just these few PTRs: 32.98.170.64.in-addr.arpa IN PTR ietf.org. IN PTR ietf72.ietf.org. IN PTR jabber.ietf.org. IN PTR mail.ietf.org. IN PTR rt.ietf.org. IN PTR search.ietf.org. IN PTR trustee.ietf.org. > www.google.com I'm not sure what you're talking about there -- that one is a CNAME. > there is no PTR that resolves to www.netoyen.net and there will never > be. The corresponding IP resolves to imlil.netoyen.net, which in turn > resolves to the IP. That is what IP -> name -> IP double resolution > (sometimes called FcrDNS) means. there is no need for the IP to resolve > to all the names. You are confused. If a _client_ uses a hostname which does not have a PTR corresponding to it, then the client's hostname CANNOT be assumed to be valid. I.e. it all depends on what names are used, and from what perspective. For HTTP the client never does not give its name -- but for SMTP it does. (i.e., indeed there are perspectives of use where the validity of a hostname base on the reverse DNS is less important.) There's also the human "perspective" of the DNS, for what it's worth. If I create a hostname such as: it-is-all-mine.weird.com. IN A91.121.103.130 are _you_ going to then believe that my use of that IP address is valid? Why not? Do you expect anyone else to believe my use of that IP address is valid? Why not? What if I use that hostname as my mailer's client name when sending mail? Are you going to try to argue that there should be some algorithm which tries to identify the invalid nature of my proposed hostname above just because it somehow doesn't "match" the domain name which the PTR for that address does point to? I defy you to even try to create such an algorithm which will work in _every_ case, and which will be simpler than if we all simply agree that the only valid hostnames pointing to an address are those for which the address resolves in the reverse DNS to corresponding PTRs. -- Greg A. Woods +1 416 218-0098VE3TCP RoboHack Planix, Inc. Secrets of the Weird pgp3ZFhhEeW0Q.pgp Description: PGP signature
Re: Postfix Deployment
Wietse Venema put forth on 11/27/2009 5:17 PM: > Stan Hoeppner: >> I'm running my Postfix firewall behind NAT/PAT and the setup didn't >> require any non-default Postfix settings to make it work. I port >> forwarded TCP 25 from my router to my internal Postfix host IP and all >> worked without issue. What settings are you referring to? > > proxy_interfaces=external-ip-address, which is needed to avoid > "mail loops to myself" errors when you provide backup MX service, > and the primary is for some reason not available. Thanks for the heads up Wietse. What is the effect of proxy_interfaces on a NAT'd Postfix box if I'm not running a/as backup MX? (I'm not) Any? Speaking of mail loops, note the first entry below: uribl.com. 43200 IN MX 10 mx. uribl.com. 43200 IN MX 10 mx.uribl.com. uribl.com. 43200 IN MX 100 mx2. uribl.com. 43200 IN MX 100 mx2.uribl.com. uribl.com is the only site I've ever mailed to that has a non-fqdn hostname for an MX record. When I attempt to send mail to **...@uribl.com, I get the following: Nov 27 19:10:00 greer postfix/smtpd[8196]: connect from gffx.hardwarefreak.com[192.168.100.53] Nov 27 19:10:00 greer postfix/smtpd[8196]: 84D913DA123: client=gffx.hardwarefreak.com[192.168.100.53] Nov 27 19:10:00 greer postfix/cleanup[8199]: 84D913DA123: message-id=<4b107868.5060...@hardwarefreak.com> Nov 27 19:10:00 greer postfix/qmgr[8172]: 84D913DA123: from=, size=701, nrcpt=1 (queue active) Nov 27 19:10:00 greer postfix/smtpd[8196]: disconnect from gffx.hardwarefreak.com[192.168.100.53] Nov 27 19:10:01 greer postfix/smtp[8200]: 84D913DA123: to=<**...@uribl.com>, relay=none, delay=1.2, delays=0.1/0.03/1/0, dsn=5.4.6,status=bounced (mail for uribl.com loops back to myself) Nov 27 19:10:01 greer postfix/cleanup[8199]: B18AF3DA124: message-id=<20091128011001.b18af3da...@greer.hardwarefreak.com> Nov 27 19:10:01 greer postfix/qmgr[8172]: B18AF3DA124: from=<>, size=2537, nrcpt=1 (queue active) Nov 27 19:10:01 greer postfix/bounce[8201]: 84D913DA123: sender non-delivery notification: B18AF3DA124 Nov 27 19:10:01 greer postfix/qmgr[8172]: 84D913DA123: removed Nov 27 19:10:01 greer postfix/smtp[8200]: B18AF3DA124: to=, relay=192.168.100.2[192.168.100.2]:25, delay=0.1 1, delays=0.02/0/0.02/0.07, dsn=2.0.0, status=sent (250 OK) Nov 27 19:10:01 greer postfix/qmgr[8172]: B18AF3DA124: removed I added proxy_interfaces = 65.41.216.221 to main.cf and reloaded before sending the above test message. It doesn't seem to affect/fix this particular mail loop issue I have with uribl.com. Any ideas what's causing this, or how to fix it? This is the first and only domain I've ever had this problem with when attempting delivery. -- Stan
value in an alias_maps map to short circuit subsequent maps and deliver locally?
I have two maps, ldap:/etc/postfix/ldap-mailRoutingAddress.cf and ldap:/etc/postfix/ldap-mail.cf alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-mailRoutingAddress.cf, ldap:/etc/postfix/ldap-mail.cf sender_canonical_maps = ldap:/etc/postfix/ldap-mail.cf This way, * For users without an entry in either map, mail is delivered locally and is canonicalized as usern...@$myorigin * For users with an entry in just ldap-mailRoutingAddress.cf, mail is delivered to that address but is still canonicalized as username@ $myorigin * For users with an entry in just ldap-mail.cf, mail is delivered to that address and is canonicalized as that address * For users with an entry in each map, mail is delivered to the address from ldap-mailRoutingAddress.cf and is canonicalized as the address from ldap-mail.cf This is great, except I now have one unusual case where mail must be delivered locally, but must be canonicalized as the address from ldap-mail.cf - but with an address in ldap-mail.cf, mail isn't delivered locally, it's delivered to that address instead : ( Can I put some value in the ldap-mailRoutingAddress.cf map which will cause mail to be delivered locally? thereby stopping the lookup before getting to ldap-mail.cf? Any other suggestions?
Re: CMD tool to check if next SMTP hop can use TLS for messages?
Harakiri: > > 1) Configure the Postfix SMTP client to REQUIRE TLS. > > > > ? ? smtp_tls_security_level=encrypt > > no - as i said, my filer has own rules and can be based on recipient, sender, > or a combination of both - postfix cant do this, or at least not without > different policy servers > > > > > 2) Configure the Postfix SMTP server to reject mail that > > ???cannot be delivered via SMTP-over-TLS. > > > > ? ? smtpd_recipient_restrictions = > > ??? reject_unverified_recipient > > ??? permit_mynetworks > > ??? reject_unauth_destination > > again, doesnt work - as i said i want this policy based in an existing filter > - therefor i asked for a CMD app to check the existing of TLS myself Given this: > I know about all the difficulties with MX lookup etc, the original > goal would be - that i have a policy for external domains - and > that for certain domains a message should only be sent if TLS is > available - if a message to a certain domain is sent which does > not support TLS - it should be blocked - You can configure reject_unverified_recipient to use a message delivery transport that requires TLS, even when normal mail deliveries don't require it: /etc/postfix/main.cf: address_verify_transport_maps = hash:/etc/postfix/verify_transport /etc/postfix/verify_transport: example.com smtp-tls-required: /etc/postfix/master.cf: smtp-tls-required unix - - - - - smtp -o smtp_tls_security_level=encrypt Then, you can invoke reject_unverified_recipient SELECTIVELY for the domains that need TLS. Wietse
Re: CMD tool to check if next SMTP hop can use TLS for messages?
--- On Fri, 11/27/09, Wietse Venema wrote: > From: Wietse Venema > Subject: Re: CMD tool to check if next SMTP hop can use TLS for messages? > To: "Postfix users" > Date: Friday, November 27, 2009, 11:14 AM > Harakiri: > > 1) Configure the Postfix SMTP client to REQUIRE TLS. > > smtp_tls_security_level=encrypt no - as i said, my filer has own rules and can be based on recipient, sender, or a combination of both - postfix cant do this, or at least not without different policy servers > > 2) Configure the Postfix SMTP server to reject mail that > cannot be delivered via SMTP-over-TLS. > > smtpd_recipient_restrictions = > reject_unverified_recipient > permit_mynetworks > reject_unauth_destination again, doesnt work - as i said i want this policy based in an existing filter - therefor i asked for a CMD app to check the existing of TLS myself
Re: Postfix Deployment
Stan Hoeppner: > I'm running my Postfix firewall behind NAT/PAT and the setup didn't > require any non-default Postfix settings to make it work. I port > forwarded TCP 25 from my router to my internal Postfix host IP and all > worked without issue. What settings are you referring to? proxy_interfaces=external-ip-address, which is needed to avoid "mail loops to myself" errors when you provide backup MX service, and the primary is for some reason not available. Wietse
Re: Multiple Mail domains for reverse ptr records? I'm confused
Greg A. Woods a écrit : At Wed, 25 Nov 2009 21:51:15 +0100, mouss wrote: Subject: Re: Multiple Mail domains for reverse ptr records? I'm confused I didn't wrote this. if you can't use a mailer correctly, try an easier sport. A friend of mine recently told me bowling is easy. I'm not sure, but it's worth a try. PS. Next time, avoid CC-ing me. [snip] A hostname cannot be verified, either manually or by machine, as "valid" in the DNS unless a corresponding PTR points back at it. when you'll find the PTR that points back to www.ietf.org, www.google.com, ... etc, I'll accept to talk with you. Until then, give yourself some rest. If you want pointers on DNS, ask friendly and you'll get help. [snip] If you do not control your own reverse DNS zones, and the people who do control your reverse DNS zones are so lame as to not offer you the ability to specify a reasonable number of PTR records for each of the IP addresses you use, then you should _seriously_ consider changing to a provider where you will have the necessary control over your reverse DNS. you are totally confused. there is no PTR that resolves to www.netoyen.net and there will never be. The corresponding IP resolves to imlil.netoyen.net, which in turn resolves to the IP. That is what IP -> name -> IP double resolution (sometimes called FcrDNS) means. there is no need for the IP to resolve to all the names.
Postfix Deployment
/dev/rob0 put forth on 11/27/2009 3:13 PM: > I am equally at a loss, and could turn the question back at you: is > there any reason why I would want to run Postfix behind NAT? Inbound NAT/PAT are often confused, because they're implemented (from an admin's standpoint) in an almost identical way. Depends on your firewall/router and its language and/or config GUI. Very few people actually implement a full inbound NAT these days, almost exclusively using selective PAT instead. Many/most, those using the technology, do implement a full outbound NAT however, selectively closing often abused outbound ports. I should have stated inbound PAT only, omitting NAT from my original statement, since it is what is applicable in this discussion. The major benefit is the same as with other systems: NAT/PAT acts as a natural inbound packet filter/firewall. There's nothing else to configure except to punch PAT holes into it for internal servers. Many admins don't have the time or skill to become real firewall monkeys, pounding out dozens or hundreds of lines of access control rules to accomplish the same thing with live address networks. > Perhaps there are different assumptions about NAT and its place in > our world. For me, it's always ugly, but sometimes a necessity to > work around the scarcity of IP addresses. For you it seems to be > desirable as an end in itself. I find NAT/PAT quite an elegant solution to multiple issues. Today NAT/PAT is more about network edge security setup ease of use than it is about saving IP addresses, esp for small orgs, although the latter is a concern for many sites. You also have to look at portability. If your org doesn't have its own ARIN netblock, and switches from one pipe provider to another, losing one set of IPs and gaining another set, then you have to renumber your entire network, both inside and out. CEOs would readily fire CIOs and managers for creating a cost of this magnitude. Again, any org without a direct ARIN netblock assignment should be using RFC 1918 space internally. Period. If you're a small outfit with just a few colo'd machines to readdress, that's a different story, and much more manageable. Your only real issue here would be TTLs on your dns records. > By all means, if you gain a benefit from having your Postfix behind > NAT, run it behind NAT. Do note that a few more non-default settings > are needed, but indeed as you observed, not a big deal. Also note > that routers vary, and some, like the Cisco PIX, are proxying your > SMTP traffic, not doing NAT. Consult your router documentation and > vendor for support, and then Postfix documentation for workarounds > should they prove necessary. I'm running my Postfix firewall behind NAT/PAT and the setup didn't require any non-default Postfix settings to make it work. I port forwarded TCP 25 from my router to my internal Postfix host IP and all worked without issue. What settings are you referring to? I concur with your router/firewall statement above. NAT/PAT implementations can and do vary, so one should read up on the docs and be ready for possible functionality oddities. For instance, I've seen a few NAT/PAT implementations that mask the real source IP in the packets, replacing it with the internal private interface IP of the router. This obviously wreaks havoc on Postfix smtpd, making client IP checks impossible, and making connection logging useless, amongst other things. So, if you run across a router with such a NAT implementation, toss it and get one that passes source IPs correctly (IIRC this came up not all that long ago, and Wietse's advice was the same--ditch the crappy router). That said, even many of the cheapest consumer broadband routers handle this correctly these days, most have since at least 2004, so I can't imagine you'd run into this today. Anything's possible though. -- Stan
Re: Postfix Deployment
On Fri, Nov 27, 2009 at 03:42:56PM -0500, Roman Gelfand wrote: > On Fri, Nov 27, 2009 at 1:48 PM, Stan Hoeppner wrote: > > Ralf Hildebrandt put forth on 11/27/2009 6:20 AM: > > > >> Then it of course needs a publich IP addresses > > > > Or, at least, a public IP NAT/PAT'd to it by your firewall. It will > > also obviously need PTR, A, and MX records. > > > > Also, this may be helpful: > > > > http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall > > > > I am at a loss here. This article seems to say that it is possible, I > mean in the way it was designed to run, to run postfix in NATed > network. In this case, is there still a reason why I would want to > run postfix on public ip machine? I am equally at a loss, and could turn the question back at you: is there any reason why I would want to run Postfix behind NAT? Perhaps there are different assumptions about NAT and its place in our world. For me, it's always ugly, but sometimes a necessity to work around the scarcity of IP addresses. For you it seems to be desirable as an end in itself. By all means, if you gain a benefit from having your Postfix behind NAT, run it behind NAT. Do note that a few more non-default settings are needed, but indeed as you observed, not a big deal. Also note that routers vary, and some, like the Cisco PIX, are proxying your SMTP traffic, not doing NAT. Consult your router documentation and vendor for support, and then Postfix documentation for workarounds should they prove necessary. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: Postfix Deployment
Well, I see no reason to have a MTA running on a public IP. As stated above in the thread, as long as your server is HELO'ing out as the name associated with the PTR record for its SRC-NAT, then you should be fine. On Fri, Nov 27, 2009 at 3:42 PM, Roman Gelfand wrote: > On Fri, Nov 27, 2009 at 1:48 PM, Stan Hoeppner wrote: >> Ralf Hildebrandt put forth on 11/27/2009 6:20 AM: >> >>> Then it of course needs a publich IP addresses >> >> Or, at least, a public IP NAT/PAT'd to it by your firewall. It will >> also obviously need PTR, A, and MX records. >> >> Also, this may be helpful: >> >> http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall >> > > I am at a loss here. This article seems to say that it is possible, I > mean in the way it was designed to run, to run postfix in NATed > network. In this case, is there still a reason why I would want to > run postfix on public ip machine? > > Thanks again >> -- >> Stan >> > >
Re: Postfix Deployment
On Fri, Nov 27, 2009 at 1:48 PM, Stan Hoeppner wrote: > Ralf Hildebrandt put forth on 11/27/2009 6:20 AM: > >> Then it of course needs a publich IP addresses > > Or, at least, a public IP NAT/PAT'd to it by your firewall. It will > also obviously need PTR, A, and MX records. > > Also, this may be helpful: > > http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall > I am at a loss here. This article seems to say that it is possible, I mean in the way it was designed to run, to run postfix in NATed network. In this case, is there still a reason why I would want to run postfix on public ip machine? Thanks again > -- > Stan >
Re: Configuring Two Postfix mail servers behind HA Proxy load balancer.
Brian Mathis put forth on 11/27/2009 7:49 AM: > I'm sure others can help with the HA setup, but I must say that you > should not be building a server (especially an HA one!) based on any > Fedora distro. Fedora is Redhat's testbed where they use very beta > software and is also mainly targeted for dekstop users. It is > absolutely inappropriate for a server setup. Please look at CentOS > for a server-grade Linux distro that is Redhat-based and suitable for > running a server on. Or better yet, go with Debian Stable or FreeBSD. Both are better server choices than CentOS, IMHO, unless you're an RPM freak. Aptitude and Ports are both better package management systems than the RPM model, especially aptitude, especially WRT dependency resolution. -- Stan
Re: multiple content filter settings
On Fri, Nov 27, 2009 at 12:58 PM, Sharma, Ashish wrote: > Peter, > > I don't know how to do it, please post some sample for doing what you are > suggesting. Read an Amavis document, and instead of pointing it to the postfix reinjection port, send it to your other content filter.
Postfix Deployment
Ralf Hildebrandt put forth on 11/27/2009 6:20 AM: > Then it of course needs a publich IP addresses Or, at least, a public IP NAT/PAT'd to it by your firewall. It will also obviously need PTR, A, and MX records. Also, this may be helpful: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall -- Stan
Re: Multiple Mail domains for reverse ptr records? I'm confused
Wietse Venema: > Greg A. Woods: > > There _should_ be one PTR for every _valid_ hostname using a given IP > > address. > > Statements such as above remind me of silly knights fighting windmills. > > There is a difference between "right" and "useful", and it even > depends on where they are used - server or client side. > > Multiple server A records are useful. More in the case of HTTP, > less in the case of SMTP which uses indirection via MX records. > (For a discussion about domain-in-a-box applications, see some > actual measurements that I did earlier this year). > > One PTR per A record is not useful. The server end will not know > what client name to use. That is, one PTR per A record, in the case of multiple A records for the same IP address. > On the other hand, it is right when every PTR record has a matching > A record that resolves to (among others) the PTR record's address. > > Wietse > >
Re: Multiple Mail domains for reverse ptr records? I'm confused
Greg A. Woods: > There _should_ be one PTR for every _valid_ hostname using a given IP > address. Statements such as above remind me of silly knights fighting windmills. There is a difference between "right" and "useful", and it even depends on where they are used - server or client side. Multiple server A records are useful. More in the case of HTTP, less in the case of SMTP which uses indirection via MX records. (For a discussion about domain-in-a-box applications, see some actual measurements that I did earlier this year). One PTR per A record is not useful. The server end will not know what client name to use. On the other hand, it is right when every PTR record has a matching A record that resolves to (among others) the PTR record's address. Wietse
RE: multiple content filter settings
Peter, I don't know how to do it, please post some sample for doing what you are suggesting. Ashish -Original Message- From: petermbl...@gmail.com [mailto:petermbl...@gmail.com] On Behalf Of Peter Blair Sent: Friday, November 27, 2009 11:23 PM To: Sharma, Ashish Cc: postfix users list Subject: Re: multiple content filter settings On Fri, Nov 27, 2009 at 12:14 PM, Sharma, Ashish wrote: > I have a Postfix mail server that needs to be set for two content filters as > I have two content filters. > > One from AmaVis and another a custom content filter. Can you not have amavis feed to your second content filter, which will in turn feed back to postfix?
Re: multiple content filter settings
On Fri, Nov 27, 2009 at 12:14 PM, Sharma, Ashish wrote: > I have a Postfix mail server that needs to be set for two content filters as > I have two content filters. > > One from AmaVis and another a custom content filter. Can you not have amavis feed to your second content filter, which will in turn feed back to postfix?
Re: Multiple Mail domains for reverse ptr records? I'm confused
At Wed, 25 Nov 2009 21:51:15 +0100, mouss wrote: Subject: Re: Multiple Mail domains for reverse ptr records? I'm confused > > do not confuse this with "multihoming", where you assign multiple IPs to > a single name (that is, you use multiple A for a single name). Why d so many people who should know better keep giving BAD advice like this!?!?!?! Are you really trying to shoot for the lowest common uselessness of reverse DNS? PLEASE let us at least advise people to always at least attempt for the most ideal situation. There _should_ be one PTR for every _valid_ hostname using a given IP address. A hostname cannot be verified, either manually or by machine, as "valid" in the DNS unless a corresponding PTR points back at it. It's that simple. What "valid" means depends on many factors that are not exactly important at this point in the discussion. It is sufficient at this point to know that there exists a mechanism in the DNS as we use it today to specify every known "valid" user of a given IP address. If you do not control your own reverse DNS zones, and the people who do control your reverse DNS zones are so lame as to not offer you the ability to specify a reasonable number of PTR records for each of the IP addresses you use, then you should _seriously_ consider changing to a provider where you will have the necessary control over your reverse DNS. -- Greg A. Woods +1 416 218-0098VE3TCP RoboHack Planix, Inc. Secrets of the Weird pgpbtbTj5A50F.pgp Description: PGP signature
multiple content filter settings
Hello, I have a Postfix mail server that needs to be set for two content filters as I have two content filters. One from AmaVis and another a custom content filter. Please suggest some idea for configuring both on same Postfix. Is it possible too? Thanks in advance. Ashish Sharma
Re: CMD tool to check if next SMTP hop can use TLS for messages?
Harakiri: > I know about all the difficulties with MX lookup etc, the original > goal would be - that i have a policy for external domains - and > that for certain domains a message should only be sent if TLS is > available - if a message to a certain domain is sent which does > not support TLS - it should be blocked - i know i could probably In that case, everything you need already exists. 1) Configure the Postfix SMTP client to REQUIRE TLS. smtp_tls_security_level=encrypt 2) Configure the Postfix SMTP server to reject mail that cannot be delivered via SMTP-over-TLS. smtpd_recipient_restrictions = reject_unverified_recipient permit_mynetworks reject_unauth_destination See also: http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient http://www.postfix.org/ADDRESS_VERIFICATION_README.html#caching Wietse
Re: CMD tool to check if next SMTP hop can use TLS for messages?
On Fri, Nov 27, 2009 at 06:56:16AM -0800, Harakiri wrote: > > What problem are you actually trying to solve? > > I know about all the difficulties with MX lookup etc, the original > goal would be - that i have a policy for external domains - and that > for certain domains a message should only be sent if TLS is > available - if a message to a certain domain is sent which does not > support TLS - it should be blocked This sounds quite similar to http://www.postfix.org/TLS_README.html#client_tls_policy > - i know i could probably do this > with a policy server but i already have a custom 'filter' with an > existing policy system - so thats why i asked if there is a tool > which could query a server for TLS support - There is no Postfix reason why you couldn't run more than one policy service, FWIW. > also i would like to > visualize in my graphical mail log that the message has been sent > using TLS. Check out the #client_logging anchor in the above-linked document. It's left to you, of course, to translate the actual syslog into graphics. -- Offlist mail to this address is discarded unless "/dev/rob0" or "not-spam" is in Subject: header
Re: SSL_accept error from unknown[x.x.x.]: -1
On 11/26/2009 9:43 PM, sosogh wrote: Hi list I am running two postfix on two servers.One acts as smtp tls client, the other one acts as smtpd tls server. I tried to send mails from smtp tls client to smtpd tls server --- IP are: smtp tls client:1.1.1.1 (postfix version 2.3.8 OpenSSL 0.9.8c 05 Sep 2006) smtpd tls server:2.2.2.2 (postfix version 2.5.5 OpenSSL 0.9.8g 19 Oct 2007) configuration are: (1)smtp tls client: In main.cf: default_transport = smtp-tls:[2.2.2.2]:465 The postfix smtp client doesn't support the long deprecated smtps wrappermode. You should abandon wrappermode and configure postfix to use STARTTLS on port 587 or port 25. http://www.postfix.org/TLS_README.html#server_tls If you feel you must use smtps, please see http://www.postfix.org/TLS_README.html#client_smtps -- Noel Jones
Re: CMD tool to check if next SMTP hop can use TLS for messages?
--- On Thu, 11/26/09, Victor Duchovni wrote: > From: Victor Duchovni > Subject: Re: CMD tool to check if next SMTP hop can use TLS for messages? > To: postfix-users@postfix.org > Date: Thursday, November 26, 2009, 3:33 PM > On Thu, Nov 26, 2009 at 05:02:33AM > -0800, Harakiri wrote: > I have an unreleased utility to probe the TLS support of > remote TLS > servers, but it is NOT intended for use during message > delivery or > by content filters. Rather, the purpose is to determine the > available > security options for a tls policy entry for the > destination. > > - Is TLS available at all > - What ciphers > - What certificate issuer(s), subject CN and > altNames. sound interesting - is there a CMD app available? > What problem are you actually trying to solve? I know about all the difficulties with MX lookup etc, the original goal would be - that i have a policy for external domains - and that for certain domains a message should only be sent if TLS is available - if a message to a certain domain is sent which does not support TLS - it should be blocked - i know i could probably do this with a policy server but i already have a custom 'filter' with an existing policy system - so thats why i asked if there is a tool which could query a server for TLS support - also i would like to visualize in my graphical mail log that the message has been sent using TLS. Thanks
Re: AW: postfix - postgrey - lost connection after RSET
Zitat von Eero Volotinen : Braun Björn wrote: My logs (mail.log) Nov 5 10:07:56 grey2 postfix/smtpd[7153]: connect from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: NOQUEUE: reject: RCPT from unknown[ddd.dd.ddd.dd]: 450 4.7.1 : Recipient address rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/aaa.DE.html; from= to= proto=ESMTP helo= Nov 5 10:07:56 grey2 postfix/smtpd[7153]: lost connection after RSET from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: disconnect from unknown[ddd.dd.ddd.dd] Or are these the wrong logs? Well, looks like spammer is connecting from ddd.dd.ddd.dd and after graylisting (45X temporary error) spammer software just drops connection. This depends if "a...@aaa.de" is missing a mail from "b...@bbb.com" and "ddd.dd.ddd.dd" is a valid mailserver for "bbb.com" then the problem is worth to investigate. Regards Andreas
Re: AW: postfix - postgrey - lost connection after RSET
Braun Björn wrote: My logs (mail.log) Nov 5 10:07:56 grey2 postfix/smtpd[7153]: connect from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: NOQUEUE: reject: RCPT from unknown[ddd.dd.ddd.dd]: 450 4.7.1 : Recipient address rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/aaa.DE.html; from= to= proto=ESMTP helo= Nov 5 10:07:56 grey2 postfix/smtpd[7153]: lost connection after RSET from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: disconnect from unknown[ddd.dd.ddd.dd] Or are these the wrong logs? Well, looks like spammer is connecting from ddd.dd.ddd.dd and after graylisting (45X temporary error) spammer software just drops connection. -- Eero
Re: AW: postfix - postgrey - lost connection after RSET
Zitat von Braun Björn : My logs (mail.log) Nov 5 10:07:56 grey2 postfix/smtpd[7153]: connect from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: NOQUEUE: reject: RCPT from unknown[ddd.dd.ddd.dd]: 450 4.7.1 : Recipient address rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/aaa.DE.html; from= to= proto=ESMTP helo= Nov 5 10:07:56 grey2 postfix/smtpd[7153]: lost connection after RSET from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: disconnect from unknown[ddd.dd.ddd.dd] Or are these the wrong logs? If "b...@bbb.com" is the sender in question, no. You should have a look if there are additional attempts for "b...@bbb.com", if not the remote mailserver is not RFC compliant and your only chances are: - Inform the remote postmaster and see if he/she can be triggered to use a working mailserver setup - Exclude (whitelist) the mailserver in question from greylisting - Use restriction_classes with and without greylisting and let your users choose what they prefer Thanks B. PS: Etiquette: Do I usually reply just _ho...@kwsoft.de or the List? To make the discussion searchable in the archives you should always reply to the list. Regards Andreas smime.p7s Description: S/MIME krytographische Unterschrift
AW: postfix - postgrey - lost connection after RSET
My logs (mail.log) Nov 5 10:07:56 grey2 postfix/smtpd[7153]: connect from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: NOQUEUE: reject: RCPT from unknown[ddd.dd.ddd.dd]: 450 4.7.1 : Recipient address rejected: Greylisted, see http://isg.ee.ethz.ch/tools/postgrey/help/aaa.DE.html; from= to= proto=ESMTP helo= Nov 5 10:07:56 grey2 postfix/smtpd[7153]: lost connection after RSET from unknown[ddd.dd.ddd.dd] Nov 5 10:07:56 grey2 postfix/smtpd[7153]: disconnect from unknown[ddd.dd.ddd.dd] Or are these the wrong logs? Thanks B. PS: Etiquette: Do I usually reply just _ho...@kwsoft.de or the List? -Ursprüngliche Nachricht- Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] Im Auftrag von lst_ho...@kwsoft.de Gesendet: Freitag, 27. November 2009 13:17 An: postfix-users@postfix.org Betreff: Re: postfix - postgrey - lost connection after RSET Zitat von Braun Björn : > Hiho, > > I'm using debian 4.0r6 / postfix / postgrey ... > > This works really fine for 99+% of emailsenders > > From time to time I get > > Nov 11 09:01:54 grey2 postfix/smtpd[28926]: lost connection after > RSET from unknown[xxx.xxx.xxx.xxx] This has probably nothing to do with your problem Most of the time these are simply spammers cutting the connection after "RSET". > ... and users complaining about not being able to receive email from > certain senders. Ask the users for the *sender* address and grep your logs for failed delievery attempts from this address. Regards Andreas
Re: Configuring Two Postfix mail servers behind HA Proxy load balancer.
On Fri, Nov 27, 2009 at 2:51 AM, Manoj Burande wrote: > Hello All, > > I am trying to setup a Postfix Mail Server on Fedora10. I am trying > to learn the basic process of setting up and manage a Postfix Mail > Server. Also trying to build a High-Available Postfix Mail Server > set. I have already configured HA Proxy load balancer servers. I just > wanted to place my two postfix mail server behind it. > > Is there ANYBODY help me to accomplish the same. Or please provide me > online stuff to set up mail servers behind load balancer. > > -- > Manoj M. Burande, > Artificial Machines Pvt Ltd, > System Administrator. I'm sure others can help with the HA setup, but I must say that you should not be building a server (especially an HA one!) based on any Fedora distro. Fedora is Redhat's testbed where they use very beta software and is also mainly targeted for dekstop users. It is absolutely inappropriate for a server setup. Please look at CentOS for a server-grade Linux distro that is Redhat-based and suitable for running a server on.
Re: Configuring Two Postfix mail servers behind HA Proxy load balancer.
I've been doing ha-proxy setups with apache and spamassassin for a while and co-maintained some exim (oops, I used the 'e' word ;-) based mail servers also. On Fri, Nov 27, 2009 at 01:21:13PM +0530, Manoj Burande wrote: > I am trying to setup a Postfix Mail Server on Fedora10. I am trying > to learn the basic process of setting up and manage a Postfix Mail > Server. Also trying to build a High-Available Postfix Mail Server > set. I have already configured HA Proxy load balancer servers. I just > wanted to place my two postfix mail server behind it. First of all I'd like to ask you if you took into account that esp. email (smtp) has intrinsic features providing service failover and simple load balancing machanisms. If you have two mailservers and can give them two differnet IP addresses you might want to set just two MX records inside your DNS zone file like this: mydomain.tld IN MX 10 mailserver1.mydomain.tld. mydomain.tld IN MX 10 mailserver2.mydomain.tld. Taking into account that the sending mta will take one or the other host and would give the other one a try if the first one fails, you might already get wat you want. In the case this would not solve your problem let's go into detail. An MTA's work can be divided into several tasks: - reception of an smtp delivery - mail evaluation (filtering, scoring) - mail routing - mail delivery - local - remote Each of this has different requirements concerning system resources and environment. - reception of an smtp delivery nothing special regarding load balancing: listen on port 25/tcp, talk (e)smtp concerning rcpt verification you have to make sure both servers have a copy of the user and alias data. - mail evaluation (filtering, scoring) nothing special either. Just make sure the rule sets are the same on each system. A Bayes filter may require some attention on how you handle the Bayes database: you could just have every system have it's own, relying on statistical effects to hold them in equivalent state, simply replicate one of them to the other system the hard way (cron, rsync) or use a shared storage like spamassassin with mysql. - mail routing also nothing special. Just keep information in sync. - remote mail delivery also nothing special. Just keep information in sync. Maybe you need a source NAT gateway if you can't provide each system with its own publicly visible ip address. Up to here it would be straight forward. But ... - local mail delivery if you plan to put your email onto disk (local mailspool, pop, imap, ...) here, you will face a problem: every host writes on its own disk so the user would have to check on both systems for his mail - bad idea. This could be solved by - a shared storage: NFS Server, NAS, Database (DBMail) - additional dedicated IMAP or POP Server Please keep in mind that for high availability you would have to get the shared storage as well redundant (e.g. Linux w. DRBD, MySQL cluster) as the load balancer itself (e.g. heartbeat). HTH, Chris -- Christian Recktenwald postfix-users-d...@citecs.de
Re: Postfix Deployment
* Roman Gelfand : > On Fri, Nov 27, 2009 at 3:00 AM, Ralf Hildebrandt > wrote: > > * Roman Gelfand : > > > >> Is it preferable that machine running postfix should have publlic > >> address as opposed NATed address? > > > > That depends on what you want to use it for > > >I want to use it to filter spam and to send ham to internal network. Then it of course needs a publich IP addresses > >> It appears that as postfix handing control to various plugins, the > >> source address of the message is 127.0.0.1. Is there a configuration > >> in postfix that would ignore the localhost and show original source ip > >> address? > > > > That depends on which software you using. > > > I would like to use sid-milter and opendkim-milter. I don't know these, I'm using amavisd-new for DKIM... -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: postfix - postgrey - lost connection after RSET
Zitat von Braun Björn : Hiho, I'm using debian 4.0r6 / postfix / postgrey ... This works really fine for 99+% of emailsenders From time to time I get Nov 11 09:01:54 grey2 postfix/smtpd[28926]: lost connection after RSET from unknown[xxx.xxx.xxx.xxx] This has probably nothing to do with your problem Most of the time these are simply spammers cutting the connection after "RSET". ... and users complaining about not being able to receive email from certain senders. Ask the users for the *sender* address and grep your logs for failed delievery attempts from this address. Regards Andreas smime.p7s Description: S/MIME krytographische Unterschrift
Re: Postfix Deployment
On Fri, Nov 27, 2009 at 3:00 AM, Ralf Hildebrandt wrote: > * Roman Gelfand : > >> Is it preferable that machine running postfix should have publlic >> address as opposed NATed address? > > That depends on what you want to use it for > I want to use it to filter spam and to send ham to internal network. >> It appears that as postfix handing control to various plugins, the >> source address of the message is 127.0.0.1. Is there a configuration >> in postfix that would ignore the localhost and show original source ip >> address? > > That depends on which software you using. > I would like to use sid-milter and opendkim-milter. > -- > Ralf Hildebrandt > Geschäftsbereich IT | Abteilung Netzwerk > Charité - Universitätsmedizin Berlin > Campus Benjamin Franklin > Hindenburgdamm 30 | D-12203 Berlin > Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 > ralf.hildebra...@charite.de | http://www.charite.de > >
postfix - postgrey - lost connection after RSET
Hiho, I'm using debian 4.0r6 / postfix / postgrey ... This works really fine for 99+% of emailsenders >From time to time I get Nov 11 09:01:54 grey2 postfix/smtpd[28926]: lost connection after RSET from unknown[xxx.xxx.xxx.xxx] ... and users complaining about not being able to receive email from certain senders. I tried the following: grey2:~# telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 grey2.fade2grey.xxx.de ESMTP Postfix helo localhost 250 grey2.fade2grey.xxx.de mail from: b...@xxx.de 250 2.1.0 Ok rcpt to: b...@xxx.de 250 2.1.5 Ok rset 250 2.0.0 Ok quit 221 2.0.0 Bye Connection closed by foreign host. Can anybody please help me?! Thanks B.
Re: Postfix Deployment
* Roman Gelfand : > Is it preferable that machine running postfix should have publlic > address as opposed NATed address? That depends on what you want to use it for > It appears that as postfix handing control to various plugins, the > source address of the message is 127.0.0.1. Is there a configuration > in postfix that would ignore the localhost and show original source ip > address? That depends on which software you using. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
