[TAG] A couple of questions regarding Mail policy
Jay R. Ashworth
jra at baylink.com
Wed Jun 23 00:28:25 MSD 2004
On Tue, Jun 22, 2004 at 01:18:52PM -0700, Rick Moen wrote:
> Quoting Kapil Hari Paranjape (kapil at imsc.res.in):
> > We have two mail exchangers outside our firewall. These forward mail to
> > the LAN through the firewall. They also accept mail from the LAN to
> > forward to the big bad world out there. They do not do *any* local
> > delivery.
> > 1. AFAIK it is not necessary to have an actual machine corresponding to
> > the domain the mail originates from. In other words there does not
> > *need* to be an address (A) record for imsc.res.in in order for the e-mail
> > address kapil at imsc.res.in to send and receive mail. It is enough that
> > there be mail exchanger (MX) records. Is this correct?
> Quoting RFC2181:
> 10.3. MX and NS records
> The domain name used as the value of a NS resource record, or part of
> the value of a MX resource record must not be an alias. Not only is
> the specification clear on this point, but using an alias in either
> of these positions neither works as well as might be hoped, nor well
> fulfills the ambition that may have led to this approach. This
> domain name must have as its value one or more address records.
> Currently those will be A records, however in the future other record
> types giving addressing information may be acceptable. It can also
> have other RRs, but never a CNAME RR.
> Searching for either NS or MX records causes "additional section
> processing" in which address records associated with the value of the
> record sought are appended to the answer. This helps avoid needless
> extra queries that are easily anticipated when the first was made.
> Additional section processing does not include CNAME records, let
> alone the address records that may be associated with the canonical
> name derived from the alias. Thus, if an alias is used as the value
> of an NS or MX record, no address will be returned with the NS or MX
> value. This can cause extra queries, and extra network burden, on
> every query. It is trivial for the DNS administrator to avoid this
> by resolving the alias and placing the canonical name directly in the
> affected record just once when it is updated or installed. In some
> particular hard cases the lack of the additional section address
> records in the results of a NS lookup can cause the request to fail.
> So, yes, every MX must have a valid "A" reference record. (Note that
> this doesn't mean there must be, in your words, "an actual machine".)
This implies that, in
baylink.com. IN MX 10 mx2.jachomes.com.
*mx2.jachomes.com* must be an A record.
I assumed that Kapil was inquiring whether *baylink.com* must be an A
record as well, and that was the question I thought I was answering.
On reflection, I misremembered. The situation *I* banged into was
whether machines must have MX records *in addition* to their A records
in order to be valid targets for mail; *this* is the situation over
which there is apparently controversy. (Someone told me that if the
machine has no MX record, just having an A record isn't enough to
guarantee that all mail will get to it. I forget who; it's been 3 or 4
> > 2. We have a number of users who insist on their need to keep ".forward"
> > files. Now, it is possible (likely) that a spammer sends them mail which
> > then gets forwarded to a host that tags it as spam. Any *reasonable*
> > spam filtering and tagging mechanism should not then tag *our* host as a
> > source of spam or a relay for spam. But could this happen? Is it likely
> > to happen given the policy of various RBL's and the like?
> No. (This doesn't preclude the possibility of someone implementing
> irrational policies at an RBL. Speaking generally, that's happened
> before. Not only can any featherless biped establish one, but the
> danger of perspective loss seems ever-present in this topic.)
> Existence of static .forward files from one host to another doesn't make
> your host a "spam host", by any rational measure.
Clearly. He was wondering, I think, how many irrational anti-spammers
were out there, clearly a non-empty set.
> > 3. Given the above configuration what is a feasible mechanism to
> > implement rcpt-time verification of the recipient? Is this possible
> > without upgrading to exim4?
> Would you mind re-posting this question, making the nature of what
> you're trying to accomplish more specific? I'm unclear on what you're
I feel better that I didn't get it either. ;-)
Jay R. Ashworth jra at baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
2004 Stanley Cup Champion Tampa Bay Lightning
More information about the TAG