Mailing List Archive

Support open source code!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tlug: dot forward & procmail

>>>>> "Simon" == Simon Cozens <> writes:

    Simon> Jonathan Byrne (lists.tlug):
    >> Please, no.  The last thing the world needs is another MX that
    >> won't take mail from anyone.

    Simon> I think this is what's called an exaggeration, and a
    Simon> relatively pointless one at that.

I've never seen a bounce off of qmail[1], unless the user doesn't exist
(I've never seen a "host-doesn't-exist" bounce off of qmail at all; I
suspect qmail domains are usually well-run).

Bounces off of sendmail are rare too.  Most bounces I've seen are
either valid (non-existent address) or due to some homebrew mess.

I imagine that as a postmaster Jonathan sees quite a few of these; but 
I think you should be fair to DJB and qmail and remember that people
who think like Simon does often will choose qmail and configure it to
bounce noncompliant mail.  I don't know what the standard setting for
qmail is, but I know that smail intentionally violates RFC-1123 by
rejecting connections initiated with an invalid HELO in its
out-of-the-box configuration.

    >> then take a look at instead.  The qmail
    >> philosophy seems to be "Be very strict in what you produce
    >> (make it correct) and be even worse about what you accept."
    >> That's nice, but doesn't work very well in the real world IMHO.

    Simon> I admit that if I was writing an MTA, then I would follow
    Simon> the traditional design philosophy. But I'm glad someone is
    Simon> actually standing up to the RFCs, and sticking to them, for
    Simon> a change.

No, you don't have that option if you want to obey the letter of the
RFCs.  The RFC specifically says to be strict in what you produce,
liberal in what you accept.  This is affirmed over and over again in
many RFCs.  Eg, even though sending a correct and DNS-findable
hostname in the HELO command is mandated (I think by RFC-821, and
definitely affirmed in RFC-1123), RFC-1123 specifically prohibits
refusing mail on the basis of broken HELOs.  (This accords with my
experience that broken HELOs normally correspond to ignorant but
honest Linux admins and ignorant and lazy Windose lusers; spammers
invariably use _somebody else's_ correct HELO.)

Standing up for RFCs is a good thing, but trying to enforce them on
others is a bad idea, unless the only person who loses mail (etc) is
the sysadmin himself.

[1]  Except for the very embarrassing period when I was a spam relay,
then I saw lots of them.

University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
Next Nomikai: December 17 (Fri), 20:00 Tengu TokyoEkiMae 03-3275-3691
Next Technical Meeting: January 14 (Fri) 19:00
* Topic: "glibc - current status and future developments"
* Guest Speaker: Ulrich Drepper (Cygnus Solutions)
* Place: Oracle Japan HQ 12F Seminar Room (New Otani Garden Court)
more info:        Sponsor: Global Online Japan

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links