RE: [IMail Forum] Help with listing on ORDB.org !!!

[Wes Odneal]

Amen to that.  I do agree with you on almost all points.  My personal mail server is very tight, opposed to company mail server that demands so much more attention.   The facts are RFC is here.  People use RFC.  And mail customers, at least mine, just don’t get all of it.  So the minute you walk into work, all of a sudden you have to change your perspective on spam.  The system does need revamping.  And until it does, I have to answer phones and emails to explain to customers what happened to their 1 good email that was blocked for some reason, while they have no idea how many bad emails also got blocked.  You almost have to act like their parent and hold their hand.  If they don’t get their way, then they will complain to no end and THEN leave.  And for a good reason too.  Our customers are mostly not tech related in any sort or way.  The attitude of “just make it work and don’t break it” presides everywhere.  Therefore it is not my place to be non compliant with org, as long as it doesn’t interfere with another.   My 2 cents.   Don: nicely stated. Side note- your last message was filtered by Outlook as Junk Mail ;) Thanks, Wes Odneal From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Kiiskila Sent: Wednesday, April 21, 2004 3:52 PM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Help with listing on ORDB.org !!!   You make a very interesting argument, but as far as the customer is concerned, I’ll cross that bridge if I ever come to it.  I *do* allow null sender on my company’s server for the specific reason I gave in my previous response.  I agree in principle and personal practice at home with the sentiment of looking out for #1.   I’m quite sure that a lot of people agree with my sentiment when I say:   When confronted with the myraid of irresponsible urchins who push get-rich-quick schemes, illegal scams, drug ads, pornography to any email address, profit from using other people’s bandwidth and time, and an onslaught of utter garbage that people call “advertising”, I think any reasonable person would understand that sometimes you may have to “break the rules” in order to survive on the net.   But on my personal domain’s server outside of work, I do not accept null senders purely for these reasons. Of course, on my personal server, *I* am the customer.  Any mail coming from my own server is personal in nature and thus, if I can’t get to mail to or from someone’s server I can see why and relax the rules for them, or I find a way around it.  I have taken control of my server’s destiny and resources, and have the right and freedom to do what I will with bandwidth and resources I have purchased. Here’s the other thing… I have the right to refuse mail outright by checking RBL’s, statistics filters, virus filters, content filters, and I do. Why should null sender being a candidate for refusal be any different? Heck, look at the door of any business establishment that serves food… “SHIRT AND SHOES REQUIRED” is plastered all over the place.  But I’m sure that some jerk out there finds it perfectly all right to come in with his B.O. and foot fungus into where I want to chow down on a fajita platter.     Which takes me to the obvious question, and what could be a principle defense of the practice: “What possible legitimate reason should there be to send email to anyone on the internet with a null address?”   The answer: “There is only one: error reporting.”  And even then, you see that you at least get an identifier of postmaster or mailer-daemon @ tld, so that identifies the message without a null sender, so that begs the question even further. If the mail server has the courtesy to identify where a message originated, then everyone else should too.   Some of this lunacy that we encounter on the net has to be tempered with some common sense, and when we find rules or regulations that go against it, maybe it is time to exercise a little initiative and either 1) ignore the rule, or 2) make a change to it.   If you read section 4.1.1 of the RFC821 it states that in the command semantics for SMTP there has to be a return path and mailbox listed to which the server can respond with error conditions (mailbox unavailable, etc).  So really, if you think about it, it’s contradictory in the first place.  It’s like saying “You have to have a return route and mailbox, but, OHHH you can ignore that rule because Null Senders are required to be accepted…” Utter nonsense if you ask me.  If you can’t send the email properly and identify yourself, then why accept the email in the first place?   Even the Can-SPAM act has provisions about accurate return addresses, so you could construe any commercial email going out with a null address as being a violation of federal law, of which it is.  Do you know anyone use a null address for their personal usage? No. Why? Well, so you know who the mail is from to provide a return route.  It’s just plain common sense.   If the server itself uses null to prevent mail loops, that’s fine, let it do it internally in code, but why should everyone else be forced to accept mail from a source that can’t be reliably identified in the email address as the originator?  Even IP addresses aren’t 100% reliable ways of determining where an email really came from with open relays around.    Of course there is the argument that you can just create an email with a fake return address, but then, your mail is caught during address verification, and can be blocked at the server level.   So, it’s ok to block an email *with* an address based on the fact that the return address is false, but it is *not* ok to block an email *without* a return address. Does anyone else think this kind of reasoning is stupid?   The null address portion of the RFC was and still is very shortsighted.  The particular RFC we are discussing was written at the beginning of the 80’s when the general populace didn’t even have the kind of access to the internet that they do now.  Hell, it didn’t happen until almost 10 years after it was written, and even then, the penetration of the internet 10 years ago was not anything like it is now.   One could make the argument that email in general for the internet was not really well thought out in the first place, and coupled with modern day issues like address spoofing, email virus spreading, mailbombers, professional bulk emailers, address harvesting, site crawling for emails on websites, message boards, unscrupulous vendors who sell their email lists to spammers, null senders, deceptive headers, false return addresses, and idiots running open relays, it would be quite obvious to anyone that runs an email server for any length of time that the whole system of email needs a serious revamp.   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wes Odneal Sent: Wednesday, April 21, 2004 2:47 PM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Help with listing on ORDB.org !!!   If I am your customer that you host mail for and I do important business with a large EDU that relies on RFC.  All of a sudden, I can’t send mail to them because you refuse NULL senders.  Rejected every time.  What do you do?   Wes From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Kiiskila Sent: Wednesday, April 21, 2004 2:35 PM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Help with listing on ORDB.org !!!   Ditto here. The RFC’s were probably written when no one even considered the impact of spam.   IMHO Null sender should only be allowed from automated processes (scripts in your servers to tell you when processes fail etc) within your own network address range, there ought to be an option (or update to the RFC even) to allow refuse null sender from outside your ip range and still be compliant.   Don Kiiskila Network Administrator Snapstream Media LLC http://www.snapstream.com "You cannot make anything fool-proof. The fools are too inventive!"   -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Langston, Cale Sent: Wednesday, April 21, 2004 7:30 AM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Help with listing on ORDB.org !!!   Who cares about RFC compliance. Look out for #1!   From: Wes Odneal [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 7:36 PM To: [EMAIL PROTECTED] Subject: RE: [IMail Forum] Help with listing on ORDB.org !!!   Don’t check refuse NULL senders.  That puts you out of RFC compliance also.   http://www.ipswitch.com/support/IMail/guide/imailug8.1/Appendix%20E%20reg_tips6.html   http://www.rfc-ignorant.org/policy-dsn.php   Thanks, Wes Odneal From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Ulrich Sent: Tuesday, April 20, 2004 5:47 PM To: [EMAIL PROTECTED] Subject: [IMail Forum] Help with listing on ORDB.org !!!   For some reason, we've been blacklisted on ORDB.  We're on 7.08 and haven't changed any settings in ages.  We're very tight on relay settings. They report: ----------------------------------------------------------------------------------- Return-Path: <[EMAIL PROTECTED]> X-Original-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from mail.cydian.com (emailconfig.cydian.com [208.34.50.132])         by bockscar.ordb.org (Postfix) with ESMTP id F2189557C         for <[EMAIL PROTECTED]>; Tue, 20 Apr 2004 13:24:53 +0000 (GMT) Received: from localhost.localdomain [212.242.88.2] by mail.cydian.com with ESMTP   (SMTPD32-7.07) id A49B8C009C; Tue, 20 Apr 2004 09:24:43 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] X-ORDB-Envelope-From: [EMAIL PROTECTED] X-ORDB-Envelope-To: [EMAIL PROTECTED] Subject: ORDB.org check (0.7097115109686880.8643653302) ip=208.34.50.132 Message-Id: <[EMAIL PROTECTED]> Date: Tue, 20 Apr 2004 13:24:53 +0000 (GMT) ----------------------------------------------------------------------------------- Obviously, they're sending as "[EMAIL PROTECTED]" My question is how? This account not only has a long cryptic password, but is disabled. I know I can't delete the account. On the admin screen, I've checked: User Cannot Change Password, Account is Disabled, and Hide from Information Services. Not checked: User cannot modify LDAP attributes, allow web access, host administrator, list administrator, imail system administrator On SMTP security, I have slected: --------------------------------- * relay for local users only and checked: --------------------------------- allow remote mail to local groups refuse null() senders check valid sender auto-deny possible hack attempts disable SMTP-VRFY command and not checked: --------------------------------- allow remote view of local groups disable SMTP-AUTH reporting Am I missing anything? Does anyone have any ideas on this?  I'm getting irate calls from customers whose email are getting bounced, and from what I can see, it should be config'd correctly. Thanks! Chris