Re: Reverse DNS requirement

2009-08-05 Thread Robert Schetterer
LuKreme schrieb:
 On Aug 4, 2009, at 3:42, Thomas Gelf tho...@gelf.net 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

2009-08-05 Thread Clunk Werclick
On Wed, 2009-08-05 at 09:44 +0200, Robert Schetterer wrote:
 LuKreme schrieb:
  On Aug 4, 2009, at 3:42, Thomas Gelf tho...@gelf.net 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

2009-08-05 Thread Thomas Gelf
LuKreme wrote:
 On Aug 4, 2009, at 3:42, Thomas Gelf tho...@gelf.net 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

2009-08-04 Thread brian moore
On Tue, 04 Aug 2009 11:42:03 +0200
Thomas Gelf tho...@gelf.net 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

2009-08-04 Thread Thomas Gelf
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

2009-08-04 Thread Robert Schetterer
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

2009-08-04 Thread LuKreme

On Aug 4, 2009, at 3:42, Thomas Gelf tho...@gelf.net 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

2009-08-03 Thread Thomas Gelf
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

2009-08-03 Thread Bryan Irvine
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 Bakmik...@t-online.hu 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

2009-08-03 Thread Jorey Bump
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

2009-08-03 Thread Robert Schetterer
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

2009-08-03 Thread LuKreme

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?