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>----- On Mon, Jul 21, 1997 at 07:06:58PM -0400, Greg A. Woods wrote:

...

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 -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592 --JAA28200.869579680/scfn.thpl.lib.fl.us-- -----End of forwarded message----- -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592