Re: problem dealing w/ ietf.org mail servers
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem dealing w/ ietf.org mail servers



> On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
> [..]
> > However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
> > explicitly configured on the sending server; instead, it is being impli=
> citly
> > configured through ip6 autoconf stuff:
> 
> Which (autoconfig) you should either not be using on servers, or you=20
> should be configuring your software properly to select the correct=20
> outbound address. (I prefer to use the autoconfig one for 'management'=20
> and using a 'service address' for the service).

	And what is someone who doesn't have a permanent box with
	a static address to do that wants to use TLS to verify
	that one is actually talking to the remote party you are
	expecting to?

	A mobile machine can register its current addresses in the
	DNS regardless much more easily than it can register its
	reverse PTR records.

	Use the ISP's servers?  I don't trust the ISP's servers to do
	the right job.  I don't trust that there is not a copy of the
	correspondence being made and being sent somewhere else.  I
	have NO idea if they are setup to use TLS or not outbound

	Lack of PTR should NEVER be the SOLE reason for rejecting
	email.  I have not problem with is being a weighting into
	the decision of whether a piece of email is spam or not.
	Just don't make it map to 100%.

> SMTP shows that it is perfectly usable for these situations as it nicely =
> 
> rejects the message with a proper message automatically telling you on=20
> how to solve it.
> 
> > That is to say, it appears the ietf.org mail server is probably now rej=
> ecting
> > mail from *any* box that is getting a default global ipv6 address, sinc=
> e
> > those aFrom ietf-bounces at ietf.org  Thu Jul  3 14:58:10 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7E74E3A67FA;
	Thu,  3 Jul 2008 14:58:10 -0700 (PDT)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 690BE3A67FA
	for <ietf at core3.amsl.com>; Thu,  3 Jul 2008 14:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level: 
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id GRiLzADWvRH1 for <ietf at core3.amsl.com>;
	Thu,  3 Jul 2008 14:58:08 -0700 (PDT)
Received: from drugs.dv.isc.org (drugs.dv.isc.org
	[IPv6:2001:470:1f00:820:214:22ff:fed9:fbdc])
	by core3.amsl.com (Postfix) with ESMTP id CC86D3A67EF
	for <ietf at ietf.org>; Thu,  3 Jul 2008 14:58:07 -0700 (PDT)
Received: from drugs.dv.isc.org (localhost [127.0.0.1])
	by drugs.dv.isc.org (8.14.2/8.14.2) with ESMTP id m63LvwqL047054;
	Fri, 4 Jul 2008 07:58:00 +1000 (EST)
	(envelope-from marka at drugs.dv.isc.org)
Message-Id: <200807032158.m63LvwqL047054 at drugs.dv.isc.org>
To: Jeroen Massar <jeroen at unfix.org>
From: Mark Andrews <Mark_Andrews at isc.org>
Subject: Re: problem dealing w/ ietf.org mail servers 
In-reply-to: Your message of "Thu, 03 Jul 2008 15:57:53 +0200."
	<486CDAE1.4040905 at spaghetti.zurich.ibm.com> 
Date: Fri, 04 Jul 2008 07:57:58 +1000
Cc: ietf at ietf.org, Dave Crocker <dcrocker at bbiw.net>,
	Richard Shockey <richard at shockey.us>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org


> On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote:
> [..]
> > However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not
> > explicitly configured on the sending server; instead, it is being impli=
> citly
> > configured through ip6 autoconf stuff:
> 
> Which (autoconfig) you should either not be using on servers, or you=20
> should be configuring your software properly to select the correct=20
> outbound address. (I prefer to use the autoconfig one for 'management'=20
> and using a 'service address' for the service).

	And what is someone who doesn't have a permanent box with
	a static address to do that wants to use TLS to verify
	that one is actually talking to the remote party you are
	expecting to?

	A mobile machine can register its current addresses in the
	DNS regardless much more easily than it can register its
	reverse PTR records.

	Use the ISP's servers?  I don't trust the ISP's servers to do
	the right job.  I don't trust that there is not a copy of the
	correspondence being made and being sent somewhere else.  I
	have NO idea if they are setup to use TLS or not outbound

	Lack of PTR should NEVER be the SOLE reason for rejecting
	email.  I have not problem with is being a weighting into
	the decision of whether a piece of email is spam or not.
	Just don't make it map to 100%.

> SMTP shows that it is perfectly usable for these situations as it nicely =
> 
> rejects the message with a proper message automatically telling you on=20
> how to solve it.
> 
> > That is to say, it appears the ietf.org mail server is probably now rej=
> ecting
> > mail from *any* box that is getting a default global ipv6 address, sinc=
> e
> > those addressesddresses will most likely not be in ip6.arpa.  There may be a wh=
> ole
> > lot of boxes in this situation.=20
> 
> Those boxes are not set up correctly thus should not be sending email in =
> 
> the first place.

	A PTR is not a requirement for sending email.  The IETF
	should live by it's own dog food and accept email from sites
	without PTR records.
 
> For that matter you should actually be=20
> firewalling+logging port 25 outbound so you can monitor any host in your =
> network doing illegal SMTP connects. Spam bots don't use IPv6 yet=20
> (afaik), but when they are aware how 'open' everything is and especially =
> that RBL's don't exist yadda yadda, they might just switch over to that.
> Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 =
> 
> yet as that would change that scenario.
> 
> Configure your mailservers correctly, it helps you send out mail, and it =
> 
> helps avoid others receiving crap from you.

	If you want to demand PTR records then you need to make it
	a requirement of address allocations that control of the
	reverse DNS entry passes down to the actual user of the
	addresses. 

	Mark

> Greets,
>   Jeroen
> 
> --
> 
> For postfix folks:
> http://www.postfix.org/IPV6_README.html
> 8<--------------------------------------------------------
> /etc/postfix/main.cf:
>      smtp_bind_address6 =3D 2001:240:587:0:250:56ff:fe89:1
> -------------------------------------------------------->8
> Other SMTP servers have similar mechanisms.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


 will most likely not be in ip6.arpa.  There may be a wh=
> ole
> > lot of boxes in this situation.=20
> 
> Those boxes are not set up correctly thus should not be sending email in =
> 
> the first place.

	A PTR is not a requirement for sending email.  The IETF
	should live by it's own dog food and accept email from sites
	without PTR records.
 
> For that matter you should actually be=20
> firewalling+logging port 25 outbound so you can monitor any host in your =
> network doing illegal SMTP connects. Spam bots don't use IPv6 yet=20
> (afaik), but when they are aware how 'open' everything is and especially =
> that RBL's don't exist yadda yadda, they might just switch over to that.
> Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 =
> 
> yet as that would change that scenario.
> 
> Configure your mailservers correctly, it helps you send out mail, and it =
> 
> helps avoid others receiving crap from you.

	If you want to demand PTR records then you need to make it
	a requirement of address allocations that control of the
	reverse DNS entry passes down to the actual user of the
	addresses. 

	Mark

> Greets,
>   Jeroen
> 
> --
> 
> For postfix folks:
> http://www.postfix.org/IPV6_README.html
> 8<--------------------------------------------------------
> /etc/postfix/main.cf:
>      smtp_bind_address6 =3D 2001:240:587:0:250:56ff:fe89:1
> -------------------------------------------------------->8
> Other SMTP servers have similar mechanisms.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.