Jeff wrote on 12/09/2006 04:57:51 PM:
So, when my server sends e-mail, it uses saber.nabs.net as its
EHLO, and the connection comes from 71.246.216.107. host
saber.nabs.net returns 71.246.216.107, which is the same IP that the
connection comes from. So far, so good.
But, host
On 7 Dec 2006 at 9:58, Jan-Pieter Cornet wrote:
On Wed, Dec 06, 2006 at 11:32:57AM -0800, John Rudd wrote:
Botnet looks to verify that:
c) the hostname doesn't contain 2 or more octets of its IP address in
hex or decimal form
d) the hostname doesn't contain certain client like
Jeff Rife wrote:
So, I vote for any change to the Botnet code that ends up with my type
of situation (which is pretty much what Jan-Pieter was also describing)
not getting rejected.
Do you have a valid SPF record for your domain? One that says that host
is the right one?
I'm thinking
On 9 Dec 2006 at 15:16, John Rudd wrote:
So, I vote for any change to the Botnet code that ends up with my type
of situation (which is pretty much what Jan-Pieter was also describing)
not getting rejected.
Do you have a valid SPF record for your domain? One that says that host
is
On Wed, Dec 06, 2006 at 11:32:57AM -0800, John Rudd wrote:
Botnet looks to verify that:
a) the relay has a PTR record at all
b) optional: the hostname in the PTR record resolves, and resolves back
to the IP address that you're talking to
c) the hostname doesn't contain 2 or more octets of
Jan-Pieter Cornet wrote:
On Wed, Dec 06, 2006 at 11:32:57AM -0800, John Rudd wrote:
If either the HELO or
the envelope sender domain points back at the sending IP, it is
also allowed. Unless, of course, either of those are generic rDNS
or [] bracketed IP constructs.
If you can make the
On Thu, Dec 07, 2006 at 03:16:53AM -0800, John Rudd wrote:
If either the HELO or
the envelope sender domain points back at the sending IP, it is
also allowed. Unless, of course, either of those are generic rDNS
or [] bracketed IP constructs.
If you can make the second part work (sender's
On Tue, Dec 05, 2006 at 02:51:22PM -0600, Michael Sims wrote:
Mike Lambert wrote:
Michael Sims wrote:
Ah. So you're saying that sendmail doesn't provide the PTR record
to the milter unless it has verified that forward and reverse match?
That certainly seems to be what I'm seeing here.
John Rudd wrote:
Michael Sims wrote:
No biggie, my Net::DNS solution is working fine so I'll stick with
that for now.
What exactly is it that you're trying to do?
Get the PTR for the connecting relay, even if the forward and reverse lookups
don't match. Apparently $RelayHostname only
Jan-Pieter Cornet wrote:
On Tue, Dec 05, 2006 at 02:51:22PM -0600, Michael Sims wrote:
Mike Lambert wrote:
Michael Sims wrote:
Ah. So you're saying that sendmail doesn't provide the PTR record
to the milter unless it has verified that forward and reverse
match? That certainly seems to be
Michael Sims wrote:
John Rudd wrote:
Michael Sims wrote:
No biggie, my Net::DNS solution is working fine so I'll stick with
that for now.
What exactly is it that you're trying to do?
Get the PTR for the connecting relay, even if the forward and reverse lookups
don't match. Apparently
John Rudd wrote:
Michael Sims wrote:
John Rudd wrote:
What exactly is it that you're trying to do?
Get the PTR for the connecting relay, even if the forward and
reverse lookups don't match. Apparently $RelayHostname only
contains the PTR if they do match. Currently I'm checking for this
Mike Lambert wrote:
Michael Sims wrote:
Ah. So you're saying that sendmail doesn't provide the PTR record
to the milter unless it has verified that forward and reverse match?
That certainly seems to be what I'm seeing here.
This feature may help (it works for access.db lookups):
Michael Sims wrote:
No biggie, my Net::DNS solution is working fine so I'll stick with that for now.
What exactly is it that you're trying to do?
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL
14 matches
Mail list logo
