ietf-mxcomp
[Top] [All Lists]

Re: Input on identities

2004-04-01 01:49:37


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.


Surely this would have been completely avoidable (forget "trivially
fixable") by making sure that your *outbound MTA* was correctly configured
in the first place.
i.e. said HELO its_real_name_that_has_good_rdns


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.


There seems to be some confusion between your outbound MTA, and your MX
(inbound).


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.


Of course, many systems use different hosts inbound and outbound. 
 

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.


Yes, of course, and this is the chief point of all these proposals, that
there should be a way of determining that a host is in some way authorised
as outbound MTA for a domain. Or to put it another way, that legitimate
mail for a domain will have the property of having passed through specified
MTA. This may have nothing at all to do with what the MX (inbound) for the
domain is.

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?  


Good question. You're a customer, ask them.

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


Implementation detail. Ask implementors.