Apologies to the list; this will be the final posting you see on this
topic. Greg: the system is valid, verifiable, and has an A record. If
that's not good enough for you, sign off now.
-----Forwarded message from Mail Delivery Subsystem <MAILER-DAEMON>-----
> get a real mailer.
Oh oh! Trouble down there in Florida making you cranky Jay?
Nope.
People who don't read the RFC's. 
Thanks for your voicemail message -- sorry I couldn't answer directly as
I've been keeping the line open to a customer who's brand new T1 is down
and out and there's lots of finger pointing going on....
I'm hip.
FYI here's the log entry may mailer records when this sort of thing
happens (this example from your most recent attempt):
Yeah, this time, as noted, I got the reply myself.
07/21/1997 17:37:16: remote MAIL FROM: '<jra@scfn.thpl.lib.fl.us>SIZE=3395' target 'scfn.thpl.lib.fl.us' is not a valid domain (no MX record); by jra@scfn.thpl.lib.fl.us [204.198.80.3].
The '<jra@scfn.thpl.lib.fl.us>SIZE=3395' is exactly what was sent by
"your" mailer as the parameter for the "MAIL FROM" SMTP command, and the
reason for the rejection is because the target 'scfn.thpl.lib.fl.us'
doesn't have an MX. ("jra@scfn.thpl.lib.fl.us [204.198.80.3]" is the
results of the PTR lookup and an IDENT query.)And nope, I'm not going to change this -- I'm doing it on purpose!
(and I know full well what I am doing in this case since I wrote the
code to do it this way and the requirements I set out to fulfill have
been met!
Except that you forgot that an MX record isn't necessary. An A record
works nicely... and there _IS_ one of those.
Yes this is draconian, but it helps immensely at rejecting spam and it
rarely rejects any legitimate mail (except from sticks-in-the-mud like
the folks at PSU.EDU who don't seem to have ever heard of MX records and
folks such as yourself who haven't yet run across this). I receive
hundreds of messages per day, and others using similar mail
authorisation rules receive thousands or even tens of thousands of
messages per day. This form of authorisation is spreading to more and
more mailers too -- I understand that even sendmail can do it, and from
what I've heard aol.com has enabled such rules and Brad Knowles himself
advocates enforcing such checks. To quote a tiny portion of private
e-mail that he sent to me just before he decided to cut off all
discussion with me (I'm now privileged to be in his >/dev/null list! ;-):
Don't misunderstand me; I salute your intent. Just do it _correctly_.
And note that you shouldn't validate the sender address until you have a
recipient address. Mail addressed solely to "postmaster" has to be
deliverable anyway, or you violate RFC 822.
He wasn't talking explicitly about requiring a valid MX for the sender
address, but I think you'll see the direction he seemed to be going in.
Certainly; he was talking about verifying the existence of the sender.
MX records are optional, and therefore inspire false negatives of this
sort.
> > Your DNS is rather sparse of MX records. You might want to add at least
> > the following as well:
> >
> > thpl.LIB.fl.us. MX 1 scfn.thpl.lib.fl.us.
> > scfn.thpl.LIB.fl.us. MX 1 scfn.thpl.lib.fl.us.
> >
> > Either that or use a return address of <jra@ns1.thpl.lib.fl.us>
> > (i.e. the "MAIL FROM:" address given in the SMTP envelope).
>
> The return address you should have had was "jra@baylink.com".
> baylink.com MX's to scfn.thpl.lib.fl.us, which is an A record.Yes, that would have worked A-OK, but perhaps you're thinking of the
RFC-822 "Reply-To" address whereas I'm talking about the SMTP envelope
sender address.
If you got an envelope address of ns1, then we have a mail routing
problem on outbounds of which I wasn't aware.
Hopefully we can get this sorted out amicably -- I can't bend on my rule
to require an MX for sender addresses, but I may think about adding an
exception list to allow friends to break the rules (until they see clear
to fixing their DNS! ;-).
Unless you can come up with a valid explanation why simply an A record
isn't enough, I think you'll have to bend your rule to avoid violating
the RFCs.
Cheers,
-- jra