Quoting John Klos (john@sixgirls.org):
> Hi,
> 
> > > 1) That the IP address of the connecting server is in the list of IPs
> > > returned by DNS A and MX RR of the name given in HELO/EHLO.
> >
> > So if my server says "HELO internal-only-interface-name" like
> > so many dual homed machines do, you don't accept?
> 
> Yes, of course. The RFC is quite clear that the server MUST provide a
> correct name or address literal. And an internal-only-interface-name is
> not a correct name or address literal in the context of an SMTP server
> on the Internet.

It is NOT "quite clear".

http://www.faqs.org/rfcs/rfc2821.html
...
|4.1.1.1  Extended HELLO (EHLO) or HELLO (HELO)
|
|   These commands are used to identify the SMTP client to the SMTP
|   server.  The argument field contains the fully-qualified domain name
|   of the SMTP client if one is available.  In situations in which the
|   SMTP client system does not have a meaningful domain name (e.g., when
|   its address is dynamically allocated and no reverse mapping record is
|   available), the client SHOULD send an address literal (see section
|   4.1.3), optionally followed by information that will help to identify
|   the client system.  The SMTP server identifies itself to the SMTP
|   client in the connection greeting reply and in the response to this
|   command.


The older RFC:
http://www.faqs.org/rfcs/rfc821.html
| 4.1.1.  COMMAND SEMANTICS
|....
|         HELLO (HELO)
|
|            This command is used to identify the sender-SMTP to the
|            receiver-SMTP.  The argument field contains the host name of
|            the sender-SMTP.
|
|            The receiver-SMTP identifies itself to the sender-SMTP in
|            the connection greeting reply, and in the response to this
|            command.
|
|            This command and an OK reply to it confirm that both the
|            sender-SMTP and the receiver-SMTP are in the initial state,
|            that is, there is no transaction in progress and all state
|            tables and buffers are cleared.




> > > 2) That if HELO/EHLO gives an address literal, the address matches that of
> > > the connecting server (Sendmail doesn't do this check!)
> > For good reason.
> 
> I am quite amazed that Sendmail doesn't already do this. I think I'll
> email them.

> > > 3) (optional) Simply reject email from mail servers which try to give an
> > > address literal.
> > eww.
> 
> If a person doesn't have DNS set up, then he / she should not be running
> an SMTP server, I think. Registering a domain and pointing a record at a
> machine is easy no matter what kind of connection the server has. There
> are also tons of free DNS services, both static and dynamic.

If someone does not own the IP address that they are given by a provider...
well, you're views on this matter are nice, but not binding to anyone.

There's a lot of "shoulds" that aren't in the world.
I *should* be able to control my reverse DNS.  I can't at times.


> This is primarily an option I'd like to have because of the explosive
> growth of infected Windows computers which are used to send SPAM. Most
> will not have DNS pointing to them because they were never intended to be
> SMTP servers. While they could use the DNS name given by the upstream ISP,
> I see a lot of email which appears to come from infected computers using
> address literals. I've seen no legitimate email come from a server which
> uses an address literal, and if I did, I'd contact that email server's
> administrator.

or you can evaluate the content.  Me?  I think you've have better hit
rates blocking mail from Windows boxes.  Look in the TCP packet to
see if the "evil" bit is set :)

> > > Now, if someone could help me figure out how to have Sendmail check these,
> > > I'd be very, very appreciative!
> >
> > Examine the mail that's NOT spam and see how many break this behaviour.
> > I did a "DEFER" on all mail without reverse DNS.  Several non-spam messages
> > (key being more than none) failed this test.  DEFER meant that I could
> > log it for a day, remove the test and the mail did not get lost.
> 
> Yes, I've examined all of the mail going through my server (about 8-10
> thousand a day, which I guess I should have mentioned).  Aside from one
> false positive, I have not seen any legitimate email come from machines
> which would fail my simple criteria.

And I can examine MY mail (400k-500k/day - we're a smaller site) and find
MANY false positives.  And there's no joy in telling the CFO that he
didn't get his mail because our client's mailer isn't behaving right.


> > The best way to check for spam is to check the CONTENT of the mail.
> > Checking "HELO" might be worth NOTING in, say, spamassassin, but
> > it's not worth giving it a full YEAH/NAY decision power on.
> 
> I disagree. While content checking might be useful, I am not interested in
> that. That will never be anything but a temporary stop-gap. On the other

WEll hardly.  It leaves a space for policy management in general.
And in corp-land that's critical
The number of times you see "PROPRIETARY INFORMATION, Copyright (mycompany)"
can be quite thrilling.  And explaining to people: "No, mailing
deeply proprietary code to your ISP in cleartext so you can work
on it at home is *not* ok"

> hand, whether or not the connecting server is set up properly does matter.
> If everyone did these checks, then we'd have fewer spammers using more
> properly configured servers and NOT literally the possibility of using
> every Windows computer on the planet. Then blacklisting and putting
> pressure on the ISPs would be more effective.
That's a massive "if".

"If" they actually procecuted a spammer and help them partly
responsible for the $BILLIONS that spam costs corporations each
year ...  "IF" they put them in JAIL for stealing my computer
resources and connections (friend, early on, had his ISDN up for
4 days continuously when he was away when a spammer relayed through
him - real costs he had to pay to MaBell).

> > Dual homed machines, NAT boxes and (big one) the fact that the RFCs
> > don't mandate that the HELO argument must be reversable etc.
> No. I don't know why you and so many others insist that a dual-homed
> machine can't be set up properly! Ever hear of split DNS? Know how to bind
> sendmail to a specific IP? Know how to have sendmail send from a specific
> IP? If not, then get some O'Reilly books. The rest of the world and I
> should not be concerned with receiving email from improperly configured
> servers.

Thanks.  Been doing firewalls since before DEC SEAL came out.  DNS for
quite a bit longer than that.  "CAN they be setup right?"  Sure.
ARE they?  Often not.  Am I willing to lose business because I won't
speak to them?   Well, when a high paying client sends me a .ppt document,
I don't stomp off and refuse to work with them.  They pay ME to bring
my big bag of Clue to them.

> I have a multihomed mail server - it is the upstream router and firewall
> for my primary server. So I know that mail to the Internet appears to come
> from one IP when coming from that server, and it appears to come from
> another IP when going to my protected server. It's all part of being a
> sysadmin, though. Learn and fix, like I'm trying to do here.

And "IF" (see above) every NetBSD box is setup right, then that's 1%.


It's about as useful as 'give me a list of everyone who will connect to
me and I'll add that to the "allow on port 25" list'.

And notable: very few Windows boxes speak SMTP.
Very many windows boxes can be 0wn3d in under 10 minutes however.
Makign the world "right" just isn't gonna happen.
Making Windows secure isn't either, until someone like the
(0wn3d) gov't comes in and says "we're not buying these until
they have basic security in place"

Me?  I long advocated a T3 between AOL, GEnie, Progidy, Compuserve
and other providers.
And a 56k line from them to the Rest of the Internet.
Keep those intel boxes far from me.
I get very few spams from IPv6 originators.