ietf-mxcomp
[Top] [All Lists]

Re: Input on identities

2004-04-01 00:03:22

On Thu, Apr 01, 2004 at 01:33:22AM -0500, Yakov Shafranovich wrote:


I am pro 2821 HELO and .arpa, less enthusiastic about MAIL FROM since 
more changes will be needed to support rewriting and against 2822 
From/sender because of higher complexity. Comments below.


A quick comment on MAIL FROM:  My wife just got bitten by a major ISP
that's apprently implemented rDNS checks against MAIL FROM.  She was
sending from her notebook at home, using a domain name she owns, through
an outbound-only MTA on our home network.

The ISP (comcast.net) bounced the message with a 500 (permanent
failure), because the rDNS of the sending IP didn't match the domain
claimed in MAIL FROM.  

It was trivially fixable by reconfiguring her MUA to use the off-site
MX that's advertised for that domain.  I say "trivially", because I was
sitting next to her, and able to interpret the bounce message, determine
the appropriate workaround, instruct her as to what should be changed,
and explain why it bounced in the first place.

As to why her MUA was configured to use our local outbound-only MX
instead of the advertised MX:  The advertised MX, over which we have no
control, has a history of being down or extremely slow in processing
mail, and also has a history of occasionally throwing temporary bounces
due to DNS lookup failures.  Our local MX, being under my complete
control, has no such problems, and near-zero load, so mail's always sent
instantaneously to the recipient.

As to why our local outbound-only MX isn't the advertised MX for the
domain in question:  It's against our ISP's AUP to run servers, and thus
I cannot accept incoming email on that MTA without violating the AUP.

I've often found that the ability to send email from an MX other than
those advertised for a domain can be a boon, as it gets around the
problems mentioned above -- uncontrollable and unpredictable load and
outages.


However, I can clearly see the benefit of a DNS-based authentication
scheme in which I could advertise that particular IP as valid for
sending email from that domain, without having to add an MX RR that
would make it a potential recipient MTA for the domain as well.

The questions in my mind now are:

1)  Will large ISPs such as comcast.net be willing to change to whatever
MARID proposes, given they've already implemented such a system?  

2)  Will in-addr.arpa checks conflict with SPF-esque approaches?  Would
one have precedence over the other?

-- 
Mark C. Langston                                    Sr. Unix SysAdmin
mark(_at_)bitshift(_dot_)org                                       
mark(_at_)seti(_dot_)org
Systems & Network Admin                                SETI Institute
http://bitshift.org                               http://www.seti.org