On January 17, 2010 12:37:46 PM -0800 "Daniel V. Reinhardt"
wrote:
A proper ISP and Host would have the proper PTR Records set up thus
validating the said sender as being part of a reputable ISP or Host.
I am a "proper" host with a "proper" ISP. Yet I do not have a PTR record
for this particu
On January 17, 2010 3:16:54 PM -0600 Stan Hoeppner
wrote:
Have you been in prison or incapacitated for the last few years Frank?
You seem to be out of touch with many established standards/norms.
Indeed I have. One of those. :)
Also I question "established" norms because times change and oft
On 18-Jan-2010, at 10:28, Stan Hoeppner wrote:
> LuKreme put forth on 1/18/2010 12:46 AM:
>> On Jan 17, 2010, at 17:27, Stan Hoeppner wrote:
>>> Then I'd surmise your experience is very limited.
>>
>> I have only been running a mailserver for 17 years or so.
>
> Do you use either of these rest
LuKreme put forth on 1/18/2010 12:46 AM:
> On Jan 17, 2010, at 17:27, Stan Hoeppner wrote:
>> Then I'd surmise your experience is very limited.
>
> I have only been running a mailserver for 17 years or so.
Do you use either of these restrictions?
reject_unknown_client_hostname
reject_unknown_re
LuKreme wrote:
On Jan 17, 2010, at 17:27, Stan Hoeppner wrote:
Then I'd surmise your experience is very limited.
I have only been running a mailserver for 17 years or so.
Almost the same...
>> Join spam-l and ask this
>> naked PTR question. You will be clued.
What is their authority ? Wh
On Jan 17, 2010, at 17:27, Stan Hoeppner wrote:
Then I'd surmise your experience is very limited.
I have only been running a mailserver for 17 years or so.
LuKreme put forth on 1/17/2010 5:55 PM:
> On Jan 17, 2010, at 13:37, "Daniel V. Reinhardt"
> wrote:
>> So rejecting email email by PTR Records is a spam prevention thing.
>
> Can you back this up at all? It's certainly not true in my experience
> and hasn't been true in a long time.
Then I'd sur
On Jan 17, 2010, at 13:37, "Daniel V. Reinhardt"
wrote:
So rejecting email email by PTR Records is a spam prevention thing.
Can you back this up at all? It's certainly not true in my experience
and hasn't been true in a long time.
On Jan 17, 2010, at 13:26, Frank Cusack wrote:
What is the reason for rejecting mail based on PTR records *at all*?
Erm.… some people seem to think PTR records are required.
Daniel V. Reinhardt wrote:
JM,
There are various online tutorials that describe how to setup a proper name
server, and how to administer one. If they are unable to teach themselves,
then they should get rejected till they become better educated in the practices
of Information Technology and
- Original Message
> From: Jose-Marcio Martins da Cruz
> To: Stan Hoeppner
> Cc: postfix-users@postfix.org
> Sent: Sun, January 17, 2010 9:36:59 PM
> Subject: Re: How to not reject valid MTAs for inconsistent forward/reverse
> DNS.
>
> Stan Hoeppner wrot
Stan Hoeppner wrote:
Rejecting mail due to lack of a PTR is an anti bot spam tactic. It is as
prevalent today as it was 5 years ago, but probably less effective. Many ISPs
went PTR crazy, assigning them to all their dynamic consumer IP ranges. DULs
and generic PTR regexes are now more effecti
Frank Cusack put forth on 1/17/2010 2:47 PM:
> On January 17, 2010 12:37:46 PM -0800 "Daniel V. Reinhardt"
> wrote:
>> A proper ISP and Host would have the proper PTR Records set up thus
>> validating the said sender as being part of a reputable ISP or Host.
>> Most of the spammers I have come acr
On January 17, 2010 12:37:46 PM -0800 "Daniel V. Reinhardt"
wrote:
A proper ISP and Host would have the proper PTR Records set up thus
validating the said sender as being part of a reputable ISP or Host.
Most of the spammers I have come across have improper DNS Records set up
meaning no name loo
- Original Message
> From: Frank Cusack
> To: postfix-users@postfix.org
> Sent: Sun, January 17, 2010 8:26:15 PM
> Subject: Re: How to not reject valid MTAs for inconsistent forward/reverse
> DNS.
>
> On January 12, 2010 1:33:46 PM -0500 Victor Duchovni
&
On January 12, 2010 1:33:46 PM -0500 Victor Duchovni
wrote:
Don't use "reject_unknown_client_hostname" indiscriminantly.
Ironically, enough time has passed that I now received a bounce from
Stan, due to my smtp host not having a PTR record. (It was a 450 and
finally my smtp server gave up.)
On January 16, 2010 9:39:26 AM -0500 Wietse Venema
wrote:
Frank Cusack:
until a name lookup has been done. But if that name lookup takes a
"very long" time, along with the connect postfix should log how long
ago the actual connect was.
The SMTP server can find out long the name/address looku
Frank Cusack:
> until a name lookup has been done. But if that name lookup takes a
> "very long" time, along with the connect postfix should log how long
> ago the actual connect was.
The SMTP server can find out long the name/address lookup took.
It does not juggle TCP packets.
The sysadmin sho
Solved ...
On January 13, 2010 1:06:10 PM -0500 Wietse Venema
wrote:
Well, if you can provide unmodified evidence, then people
can look into this.
Yeah unfortunately as I said, I couldn't do that. And anyway I wasn't
looking for folks to fix my problem so much as have the discussion so
I co
Frank Cusack:
> > Perhaps surprisingly, Postfix does not send or receive network
> > packets. Instead, packets are handled by the TCP/IP implementation
> > in the operating system kernel.
> >
> > If anything decides "prematurely" that the connection is dead, it
> > is your operating system kernel
On Wed, Jan 13, 2010 at 12:54:38PM -0500, Frank Cusack wrote:
>> If anything decides "prematurely" that the connection is dead, it
>> is your operating system kernel not Postfix.
>
> Unless of course postfix has a bug (heaven forbid).
I would like to suggest to the rest of the community on this l
On January 13, 2010 12:27:02 PM -0500 Wietse Venema
wrote:
Frank Cusack:
Contrary to what I said earlier, tcpdump is in fact interesting. I see
a 3 way handshake, and that's it. 10 minutes later, a reset. However
postfix logs a disconnect immediately. I do notice that their mss is
only 1260
Frank Cusack:
> On January 13, 2010 8:16:36 AM -0600 Stan Hoeppner
> wrote:
> > Frank Cusack put forth on 1/12/2010 9:46 PM:
> >
> >> I think it all ended well though? Except my problem still exists. :\
> >
> > We know things break when that hosts sends mail to you. What happens
> > when you se
On January 13, 2010 8:16:36 AM -0600 Stan Hoeppner
wrote:
Frank Cusack put forth on 1/12/2010 9:46 PM:
I think it all ended well though? Except my problem still exists. :\
We know things break when that hosts sends mail to you. What happens
when you send mail to that host? Do you see the
Frank Cusack put forth on 1/12/2010 9:46 PM:
> I think it all ended well though? Except my problem still exists. :\
We know things break when that hosts sends mail to you. What happens when you
send mail to that host? Do you see the same disconnect problem or similar?
What were the results of
On January 12, 2010 5:59:58 PM -0500 Victor Duchovni
wrote:
You latched onto a red-herring, it is far wiser to report accurate
symptoms than to speculate about theoretical causes of unreported
behaviour.
Sure, and that's the reason I started 2 threads.
I thought my first one was totally legit
On Tue, Jan 12, 2010 at 03:47:57PM -0500, Frank Cusack wrote:
>> Don't use "reject_unknown_client_hostname" indiscriminantly. Do so only
>> for CIDR blocks in which you find a small number of legitimate MTAs in a
>> larger pool of spam sending hosts without valid PTR records.
>
> In my case, I don
On January 12, 2010 1:33:46 PM -0500 Victor Duchovni
wrote:
On Tue, Jan 12, 2010 at 01:12:52PM -0500, Frank Cusack wrote:
I can't accept mail from hosts with multiple PTR records without manually
whitelisting them. Additionally, I can't even tell that I'm experiencing
a failure until it is re
28 matches
Mail list logo
