Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 3 Apr 2001 06:07:37 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        aa8vb@nc.rr.com (Randall Hopper)
Cc:        tlambert@primenet.com (Terry Lambert), chat@FreeBSD.ORG
Subject:   Re: Test
Message-ID:  <200104030607.XAA08860@usr05.primenet.com>
In-Reply-To: <20010402195328.B1874@nc.rr.com> from "Randall Hopper" at Apr 02, 2001 07:53:28 PM

next in thread | previous in thread | raw e-mail | index | archive | help
>  |What's silly about requiring that it be possible to contact
>  |your postmaster address before a machine is willing to take
>  |responsibility for email delivery which might fail?
> 
> I realize it must be a common spammer pattern to make use of ISP that
> doesn't list all their IPs in DNS (maybe they're the cheapest -- I don't
> know).  But for legitimate FreeBSD users sending mail from such IPs, or
> connecting from inside a masquaraded firewall where the internal DNS
> hostname sendmail wants to put in the EHLO is not known to the outside
> world, this adds a few tripwires to getting mail on the FreeBSD lists.
> 
> Aside from the spammer no-DNS pattern, requiring FreeBSD users to only use
> IPs with names in DNS is a bit silly.  It's like requiring everyone to have
> a listed phone number in the local white pages.  
> 
> It's not that big a deal to me anymore since I have a workaround.  Using
> sendmail's mailertable, I now route mail through my ISP's SMTP server only
> for destinations at FreeBSD.org.  No other mailing list cares.

How do you expect to get non-delivery notifications, if the
machine to whise postmaster they would be sent is unreachable?
If the mail is going multiple hops, you've just created an
undeliverable mail loop, which will bounce 16 times between
the servers between you and your target, and then after
consuming their resources in an unintentional denial of service
attack by you, dump the message in the bit bucket.

---

The canonical reason for requiring a reverse address is that there
are two authorities: the forward address, and the reverse address.

Because these are delegated from different authorities, doing a
getpeername(), gethostbyaddr(), gethostbyname() will act as a
crosscheck.

This lets you know that the machine who is contacting you has not
spoofed their reverse DNS address to claim to be someone they are
not (I can put anything in a reverse record I want, if I have the
IP address delegation).  By redoing the forward, I verify that
the machine I get is the machine configured by the domain
delegation, as well as by the reverse record.  It verifies for
me that you have rights to both the DNS on the IP delegation for
the in-addr.arpa domain, and for the domain of which the machine
is a member.

---

The common workaround to your situation is that you are required to
relay your email through a mail server which will relay for you
based on your IP address, and which itself doesn't have the
problem -- in other words, your ISP's mail servers.  If they pass
the test, then if you send SPAM, those of us who receive it can
pressure your ISP to terminate your account.

Another common approach, if your gateway machine running the NAT
has a valid reverse address, your most correct course of action is
to configure sendmail to claim to be that machine in its "EHLO"
and address rewriting rules for "mail from:" addresses.  See the
"MASQUERADE_DOMAIN" and "MASQUERADE_ENTIRE_DOMAIN" M4 macros.

Finally, you can always have the systems to whom you send email
set up accounts for your mail server, and permit your relay if
your mail server authticates to their mail server using the "AUTH"
SMTP extension.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200104030607.XAA08860>