Am 14.02.2011 15:20, schrieb Daniel Bromberg: > On 2/14/2011 8:51 AM, Georg Schönweger wrote: >> [SNIP] >>>> [REPOSTED FROM PERSONAL REPLY] >>>> Hello Daniel, >>>> >>>> thank you for this clear explanation! How can i figure out if the >>>> receving mail server is listet as current MX for the recipient mail >>>> address? It's not a big problem for us if the recipients mail >>>> server is >>>> misconfigured, it's just 1 customer on our websites :) I only want to >>>> know if it is our fault or not.. >>>> >>>> Anyway, i think removing the relayhost would be a great thing because >>>> the system would be easier to handle and we don't depend anymore on >>>> the >>>> external smtp server. BUT i'm afraid that we get then higher >>>> spam-rankings like in the past.. Our local server has now a valid RDNS >>>> entry. Is there anything else i have to take care about? >>>> >>>> - Georg >>>> >>> Please keep all replies to the list so people know the status of the >>> thread, and so it can be closed as soon as possible. Also as I learned >>> at first, the convention is to bottom-post. >>> >>> [Aside: As far as spam rankings: rDNS is but one minor test. I lacked >>> an rDNS on my server for awhile and had only one (rather minor) >>> receiving MX that complained compared to thousands of successes. "IP >>> Reputation" is all the rage. There are a number of utility sites out >>> there that will take the IP of any Mail Exchanger, (actually any IP at >>> all, which can be used to evaluate potential), and report on its >>> blacklist status and some even try to rank its general >>> trustworthiness. Here's a random one that looks legit from an obvious >>> Google keyword search: http://www.mxtoolbox.com/blacklists.aspx >>> Veterans of this mailing list may have other favorites to recommend. >>> The main thing is to have no red flags when querying spamhaus.org: >>> http://www.spamhaus.org/query/bl?ip=x.y.z.w] >>> >>> But back to the main point: finding a current MX is a standard DNS >>> query. If you're admin'ing a mail server, facility with a DNS query >>> like dig or nslookup is essential. For example (note, I picked this to >>> show large sites have many exchangers, but only one is required) >>> >>> unix% dig yahoo.com MX >>> [SNIP] >>> >>> -Daniel >> thx for your help. i can't check the DNS query on our relayhost smtp >> server. On our local Server the MX is current. My conclusion is that a) >> our external relayhost smtp has wrong MX entry or b) recipient >> mailserver is misconfigured. I will switch off now the relayhost since >> our ip isn't listet on any blacklist i checked so far.. >> Other question: I have a local postfix server with a dynamich IP which >> sometimes is blacklisted. Does it help in this case to use a relayhost >> which isn't blacklistet? Because the final-recipient's mailserver could >> see/check that the original mailserver is blacklistet. >> >> - Georg > > I think you're misunderstanding how a blacklist is used. The implied > contract is that a random dynamic IP (such as your local postfix > server) has the responsibility to get the message to a highly-regarded > sending mail exchanger (I'll call it the HRSMX). This is usually only > possible via authentication (and encryption), which HRSMX permits only > because a real-life contract exists between the user of that dynamic > IP and the maintainer of HRSMX. Then, HRSMX sends the message to the > MX record of the recipient, trusting the DNS MX record to be correct. > Then my main point: the receiving server ONLY needs to trust the most > recent hop: the HRSMX. Using a blacklist to verify further back up the > chain makes no sense: of course we won't accept mail directly from the > dynamic IP! HRSMX is highly regarded because it is selective and > properly configured in the first place. (On the receiving end, one > COULD write a header-checks filter that examined the length and nature > of earlier hops in the chain, hoping to find an intermediate IP that > was a known source of voluminous spam or from IPs known to belong to > organized crime, but I'm 99% sure that is an exercise in futility and > heavy computational expense.) > > It sounds like you have two servers running that you control: a local > application-specific one on a dynamic IP, and a dedicated server on a > fixed IP which as you say, checks out OK on the blacklists (and to > some approximation, is highly regarded). Why not just use your > dedicated server in all cases? For MUA's it's just an outbound SMTP > setting, and for random local mini-servers like the one on your > dynamic IP, it's just the outbound relay. > > -Daniel >
ok perfect, now it is clear. i learned a lot today :) You are right i have 3 servers, 2 are located in a server farm with static IP's (the hopefully highly regarded ones). Then we have here in our office another one which works as an email getaway (mails are fetched with gemtail and send via relayhost=[our-isp]). Great idea, why not just use one MAIN Mailserver as last hop (one of the dedicated servers) and all other servers (the local one and the other dedicated one send there mails via the relayhost=[MAIN-mailserver]) - Georg
