Re: Reverse DNS requirement
LuKreme wrote: > On Aug 4, 2009, at 3:42, Thomas Gelf wrote: > >> the person who did not correctly set up the network is to be blamed, >> if you have equipment acting as MTA it should be configured the right >> way, otherwise use a relay server > > SHOULD be blamed? Yes. But the blame will fall on the mail admin. > > "The mail was sent, YOU caused the server to reject it." "And I have pretty good reasons for doing so. The sender does not respect written standards, established long time ago - and he is also not able to write mail to AOL, Gmail, GMX, Hotmail... So why the hell shall I accept his crap???" If you'll do so - please go on, I don't care. I'll continue to reject millions of mails a day - and I can still sleep very well...
Re: Reverse DNS requirement
On Wed, 2009-08-05 at 09:44 +0200, Robert Schetterer wrote: > LuKreme schrieb: > > On Aug 4, 2009, at 3:42, Thomas Gelf wrote: > > > >> the person who did not correctly set up the network is to be blamed, > >> if you have equipment acting as MTA it should be configured the right > >> way, otherwise use a relay server > > > > SHOULD be blamed? Yes. But the blame will fall on the mail admin. > > > > "The mail was sent, YOU caused the server to reject it." > > > > this is the postfix mail list, > the option make_world_a_better_place wasnt implemented yet *g It is in my version! You must have old version: postconf -n header_checks = regexp:/etc/postfix/header_checks mail_name = cupoftea make_world_a_better_place = regex:/destroy/M$/exchange -- --- C Werclick .Lot Technical incompetent Loyal Order Of The Teapot. This e-mail and its attachments is intended only to be used as an e-mail and an attachment. Any use of it for other purposes other than as an e-mail and an attachment will not be covered by any warranty that may or may not form part of this e-mail and attachment.
Re: Reverse DNS requirement
LuKreme schrieb: > On Aug 4, 2009, at 3:42, Thomas Gelf wrote: > >> the person who did not correctly set up the network is to be blamed, >> if you have equipment acting as MTA it should be configured the right >> way, otherwise use a relay server > > SHOULD be blamed? Yes. But the blame will fall on the mail admin. > > "The mail was sent, YOU caused the server to reject it." > this is the postfix mail list, the option make_world_a_better_place wasnt implemented yet *g -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Reverse DNS requirement
On Aug 4, 2009, at 3:42, Thomas Gelf wrote: the person who did not correctly set up the network is to be blamed, if you have equipment acting as MTA it should be configured the right way, otherwise use a relay server SHOULD be blamed? Yes. But the blame will fall on the mail admin. "The mail was sent, YOU caused the server to reject it."
Re: Reverse DNS requirement
Thomas Gelf schrieb: > brian moore wrote: >> There is always the "AOL Rule". > > Yeah, we are sometimes also using AOL as an example, even if where I > live nearly nobody is using it... > >> (Hotmail and Gmail have similar rules, I just don't know where they >> spell them out.) > > Hotmail: http://postmaster.msn.com/Guidelines.aspx > Gmail: no idea, found nothing but a dummy-user-faq > > gmx also needs reverse dns http://faq.gmx.de/messages/email/optionen/antispam/1.html -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Reverse DNS requirement
brian moore wrote: > There is always the "AOL Rule". Yeah, we are sometimes also using AOL as an example, even if where I live nearly nobody is using it... > (Hotmail and Gmail have similar rules, I just don't know where they > spell them out.) Hotmail: http://postmaster.msn.com/Guidelines.aspx Gmail: no idea, found nothing but a dummy-user-faq
Re: Reverse DNS requirement
On Tue, 04 Aug 2009 11:42:03 +0200 Thomas Gelf wrote: > e) we are a really small ISP, but the largest one in our region. Two >years ago we decided to be less permissive - and we had to dedicate >ressources to teach people what they are doing wrong. The result > has been, that other providers in our region are now doing the very > same thing, and if someone complains they take us as a reference > "They are also doing so, many ISPs do so - fix your system, don't > blame us". It's all just a matter of time - and as more and more very > large Mail providers are enforcing correct behaviour it is becoming > much easier to set up such restrictions. There is always the "AOL Rule". I find it useful to ask, "are you having delivery problems to AOL, too?" They always reply, "oh, yeah, is that related?" In most cases they fix it. In the few they don't, well, they still can't mail AOL either, they just don't understand how to fix their problems. [quote] AOL's mail servers will reject connections from any IP address that does not have reverse DNS (a PTR record). All e-mail servers connecting to AOL's mail servers must have valid and meaningful (not dynamic-looking) reverse DNS records. For example: * Meaningful RDNS: mail.domain.com * Generic RDNS: 1.2.3.4.domain.isp.com [/quote] http://postmaster.info.aol.com/guidelines/standards.html I don't think it's a sin to reject mail lacking reverse DNS: the "900 pound gorrilla" of AOL does. (Not that I agree, by any means, with all their policies.. but "wow, and you can't send mail to the one of the largest providers in the world either... looks like YOU have a problem" helps justify being more strict. (Hotmail and Gmail have similar rules, I just don't know where they spell them out.)
Re: Reverse DNS requirement
LuKreme wrote: > No, you're still not understanding. > > Say you have a ... oh, I dunno, a DHCP server/router that your entire > office network plugs into. And say it has a feature, as so many do, to > send alerts via email if say the uplink goes down. Now, that email > configuration is very primitive, has almost not options, and also > doesn’t likely have rDNS configured correctly on it. > > When the uplink goes down and the emails get rejected, there's no one to > know. The human is involved, you just don't get the alert you are > expecting when you expect it. > > Who gets blamed when it's discovered all those emails where never > delivered? The person in charge of the mailserver. a) on your internal network you may violate as many RFCs as you want (if doing so makes you feel better) b) do not expect to see mail from a missconfigured server in your G/Hot/ Whatever-Mailbox c) how do you send mails if your uplink is down? d) the person who did not correctly set up the network is to be blamed, if you have equipment acting as MTA it should be configured the right way, otherwise use a relay server e) we are a really small ISP, but the largest one in our region. Two years ago we decided to be less permissive - and we had to dedicate ressources to teach people what they are doing wrong. The result has been, that other providers in our region are now doing the very same thing, and if someone complains they take us as a reference "They are also doing so, many ISPs do so - fix your system, don't blame us". It's all just a matter of time - and as more and more very large Mail providers are enforcing correct behaviour it is becoming much easier to set up such restrictions. The times where everyone could blindly send out mail from missconfigured hosts are over. Climate has become rough, you're left with the option to either take care of your MTAs, to use a correctly configured relay or to live with the fact that your mails will not be able to reach more and more people. As we have read before, rejecting mail from human senders is fine, as they will receive the bounce - and hopefully take care to find someone able to fix the problem. Much worse are automated mails from missconfigured systems, with no one taking care of bounces / rejects. You'll met public entities, booking confirmations from cheap airlines running lots of mailservers etc. That's nasty, your users will complain - and you should be prepared to (temporarily) add some IP to your whitelist and to immediately give them a competent answer: the opposite site is behaving wrong, you are just enforcing MTAs to respect a small subset of current standards. Regards, Thomas Gelf
Re: Reverse DNS requirement
On 3-Aug-2009, at 15:57, Robert Schetterer wrote: yes i know many mailling services from big companies who missed the reverse dns, but its their problem, after all if they cant get out their mail it should finally bounce to someone responsable No, you're still not understanding. Say you have a ... oh, I dunno, a DHCP server/router that your entire office network plugs into. And say it has a feature, as so many do, to send alerts via email if say the uplink goes down. Now, that email configuration is very primitive, has almost not options, and also doesn’t likely have rDNS configured correctly on it. When the uplink goes down and the emails get rejected, there's no one to know. The human is involved, you just don't get the alert you are expecting when you expect it. Who gets blamed when it's discovered all those emails where never delivered? The person in charge of the mailserver. -- With excitement like this, who is needing enemas?
Re: Reverse DNS requirement
Jorey Bump schrieb: > Robert Schetterer wrote, at 08/03/2009 03:40 PM: > >> lost mail to where ? gone universe *g? >> the mail got rejected at last with a debug code >> so the sender may take his brain to fix its problem >> or try to reach you by phone , valid mailservers etc >> if the sender cant fix it you can simply whitelist >> them by ip or else for reject_unknown_reverse_client_hostname >> mail must always be supported >> using reject_unknown_reverse_client_hostname is relativly save these >> spam days ,shows every day work here, the few problems a year are easy >> to fix, make sure that you have very good dns resolves ( i.e use local >> dns cache too) >> i changed the reject code to 550, to let senders know at once about the >> the problem, for fighting bots it very effective ,and dont break your head >> about crying users behind if the senders cant show bounces and call it >> lost mail *g > > In this particular case, human senders are rarely the issue. As you > suggest, they will often find ways to communicate to the recipient that > there is a problem. Unfortunately, a substantial portion of the messages > rejected by reject_unknown_(reverse_)client_hostname are sent by > automated processes using misconfigured software or machines that bypass > the more sensibly configured relays for a domain. yes i know many mailling services from big companies who missed the reverse dns, but its their problem, after all if they cant get out their mail it should finally bounce to someone responsable ,and then they should react, mail must be supported ever, looking logs is daily work, there are scripts which help, if i find something i mean to whitelist i can do ever, or if someone from my reciepts tells me to look at, i see no problem with thousends of mail boxes here, nobody can create the ultimate solution which fixes all thinkable problems, ever admin has to decide whats fits best to his needs , here nearly no mails which was rejected by unknown reverse was needed or asked for and mostly i know the senders very well *g but why should i support others problems not asked by my reciepts Nobody will attempt to > contact the recipient, who will often determine there is a problem when > it is too late. Maintaining whitelists isn't an attractive option when > there is already too much guesswork involved. > -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Reverse DNS requirement
Robert Schetterer wrote, at 08/03/2009 03:40 PM: > lost mail to where ? gone universe *g? > the mail got rejected at last with a debug code > so the sender may take his brain to fix its problem > or try to reach you by phone , valid mailservers etc > if the sender cant fix it you can simply whitelist > them by ip or else for reject_unknown_reverse_client_hostname > mail must always be supported > using reject_unknown_reverse_client_hostname is relativly save these > spam days ,shows every day work here, the few problems a year are easy > to fix, make sure that you have very good dns resolves ( i.e use local > dns cache too) > i changed the reject code to 550, to let senders know at once about the > the problem, for fighting bots it very effective ,and dont break your head > about crying users behind if the senders cant show bounces and call it > lost mail *g In this particular case, human senders are rarely the issue. As you suggest, they will often find ways to communicate to the recipient that there is a problem. Unfortunately, a substantial portion of the messages rejected by reject_unknown_(reverse_)client_hostname are sent by automated processes using misconfigured software or machines that bypass the more sensibly configured relays for a domain. Nobody will attempt to contact the recipient, who will often determine there is a problem when it is too late. Maintaining whitelists isn't an attractive option when there is already too much guesswork involved.
Re: Reverse DNS requirement
Jorey Bump schrieb: > Mikael Bak wrote, at 08/03/2009 10:38 AM: > >> I'm currently blocking all attepmts to connect from hosts not having a >> valid reverse DNS name with "reject_unknown_reverse_client_hostname". >> >> This is very effective for dealing with spam. This is not our only >> protection though :-) >> >> Although from time to time we get feedback from users about lost email. lost mail to where ? gone universe *g? the mail got rejected at last with a debug code so the sender may take his brain to fix its problem or try to reach you by phone , valid mailservers etc if the sender cant fix it you can simply whitelist them by ip or else for reject_unknown_reverse_client_hostname mail must always be supported using reject_unknown_reverse_client_hostname is relativly save these spam days ,shows every day work here, the few problems a year are easy to fix, make sure that you have very good dns resolves ( i.e use local dns cache too) i changed the reject code to 550, to let senders know at once about the the problem, for fighting bots it very effective ,and dont break your head about crying users behind if the senders cant show bounces and call it lost mail *g >> When checking our logs it turns out that most of the time the email is >> lost because the sending part fails the reverse DNS lookup. >> >> So now I'm a bit puzzled. Are we being too restrictive? Do you guys find >> it OK to reject hosts that fail reverse DNS checks? Do you guys find it >> common that legit mail servers does not have a reverse DNS name? What do >> you tell your users? > > Although both reject_unknown_client_hostname and the more permissive > reject_unknown_reverse_client_hostname are currently very effective at > blocking spam, there are too many misconfigured mail servers out there > for us to use either for outright blocking. Such tests are still very > useful in a scoring system. > >> I occationally try to send an email to the mail administrator of such a >> sending server. Once they replied and they accepted my complaints and >> fixed the problem, and they were happy I told them about it. But this >> was the only time anyone ever answered such a request from me, so >> perhaps it's not worth the effort. > > I've discovered the same. > >> Nevermind. To make it short: Is it ok to reject such sending servers or >> not? :-) > > I don't, because it would block important messages. You'd be surprised > at how many emergency alert systems fail this test, let alone banks, > schools, governments and other key institutions. > > > -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: Reverse DNS requirement
When I was still managing an email system and got a complaint like that. I'd actually contact the postmaster for the mail system with the errors and let them know it's failing. Typically they'd just fix it right up. Only once did I have someone argue with me over a misconfigured mail server but I sent them the snippets from the 3 RFC's they were breaking before they gave in. Make sure of 2 things before taking that tactic though. 1> That you are polite. 2> That you are right. :-D -Bryan On Mon, Aug 3, 2009 at 7:38 AM, Mikael Bak wrote: > Hi list, > > Maybe a little OT, but I thought maybe you guys know how to deal with this. > > I'm currently blocking all attepmts to connect from hosts not having a > valid reverse DNS name with "reject_unknown_reverse_client_hostname". > > This is very effective for dealing with spam. This is not our only > protection though :-) > > Although from time to time we get feedback from users about lost email. > When checking our logs it turns out that most of the time the email is > lost because the sending part fails the reverse DNS lookup. > > So now I'm a bit puzzled. Are we being too restrictive? Do you guys find > it OK to reject hosts that fail reverse DNS checks? Do you guys find it > common that legit mail servers does not have a reverse DNS name? What do > you tell your users? > > I occationally try to send an email to the mail administrator of such a > sending server. Once they replied and they accepted my complaints and > fixed the problem, and they were happy I told them about it. But this > was the only time anyone ever answered such a request from me, so > perhaps it's not worth the effort. > > Nevermind. To make it short: Is it ok to reject such sending servers or > not? :-) > > TIA, > Mikael >
Re: Reverse DNS requirement
Mikael Bak wrote:
> I'm currently blocking all attepmts to connect from hosts not having a
> valid reverse DNS name with "reject_unknown_reverse_client_hostname".
> ...
> Nevermind. To make it short: Is it ok to reject such sending servers or
> not? :-)
In my believes using reject_unknown_reverse_client_hostname is fine, I
wouldn't use reject_unknown_client_hostname. The latter would reject
many many SOHO-setups, but the former is a restriction we are enforcing
since more than a year right now (with peaks of slightly more than 6
million delivery attempts a day - so not that large, but large enough
to encounter all sorts of trouble you could run into when enabling such
a setting ;-)).
You will for sure have a few people complaining, but as I can tell from
my experience they'll satisfied if you can explain them, why you are
doing so - and why you are also helping their business partners if you
are doing so. It is far, far better to reject a mail than to put it
into quarantine (as you reached the required spam score as of your
missing PTR).
Quarantine folders are seldom checked, mail there is always on risk
to be completely lost. Rejected mail usually is able to inform at
least the sender - and he will for sure call someone to ask for
clarification (the recipient, his admin, his ISP...).
You should prepare a mail template explaining WHY you are doing so (you
are helping them - a very good argument is stating that their mails
will be lost in large ISP's quarantine, if they don't fix their setup).
Also explaing WHAT their business partner should fix this ("tell his
server admin he should tell your ISP to configure a Reverse-DNS entry
for their IP or use a correctly configured mail relay").
Be prepared to meet missconfigured hosts, and be prepared to add
exceptions to your config (Hash file, DB, whatever). Many public
entities are running badly configured systems - they'll NOT fix them
and your customers will insist on receiving their mail. Therefore you
will need a "whitelist"-feature.
Best regards,
Thomas Gelf
Re: Reverse DNS requirement
Mikael Bak wrote, at 08/03/2009 10:38 AM: > I'm currently blocking all attepmts to connect from hosts not having a > valid reverse DNS name with "reject_unknown_reverse_client_hostname". > > This is very effective for dealing with spam. This is not our only > protection though :-) > > Although from time to time we get feedback from users about lost email. > When checking our logs it turns out that most of the time the email is > lost because the sending part fails the reverse DNS lookup. > > So now I'm a bit puzzled. Are we being too restrictive? Do you guys find > it OK to reject hosts that fail reverse DNS checks? Do you guys find it > common that legit mail servers does not have a reverse DNS name? What do > you tell your users? Although both reject_unknown_client_hostname and the more permissive reject_unknown_reverse_client_hostname are currently very effective at blocking spam, there are too many misconfigured mail servers out there for us to use either for outright blocking. Such tests are still very useful in a scoring system. > I occationally try to send an email to the mail administrator of such a > sending server. Once they replied and they accepted my complaints and > fixed the problem, and they were happy I told them about it. But this > was the only time anyone ever answered such a request from me, so > perhaps it's not worth the effort. I've discovered the same. > Nevermind. To make it short: Is it ok to reject such sending servers or > not? :-) I don't, because it would block important messages. You'd be surprised at how many emergency alert systems fail this test, let alone banks, schools, governments and other key institutions.
