> ...as far as the customer is concerned, I'll cross that bridge if I
> ever come to it.
How do you propose to "come to it" if you block non-delivery
notifications, thus suppressing information from both sides (the
sender and the intended recipient)?
> I'm quite sure that a lot of people agree with my sentiment when I
> say...
It's a trite, condescending syllogism to accuse those who don't want
to block null senders of being unwilling to "break the rules" and, by
extension, of being unreasonable. Everybody knows that you do what you
can. Unfortunately for your well-worn argument, blocking null senders
is something you _cannot_ do if you claim to offer SMTP service. (I
don't know what you call what you're "offering" to yourself on your
personal account, but I'm glad you're not selling that service to
anyone else.)
> 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?
If you don't see the difference between envelope rejection of a legit
message with a full reverse-path (where the reverse-path will receive
the resultant notification, unless it's been erroneously turned off at
some point in the transport chain) and envelope rejection of null
senders (which means that the notification is silently dropped and
nothing ever reaches either party), you'd better read up on SMTP.
> 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...
Nonsense. If you're talking about a null sender with an "identifier,"
you're talking about RFC 822 header information. You're rejecting the
message at the envelope, so this is utterly irrelevant.
> 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...
Get a grip, my man. Do you think you've made a miraculous discovery
about RFC 821? Do you not see where RFC 821 makes an EXPLICIT
exception for null reverse-path in the case of error notifications? Do
you want to go through this argument, 20+ years on?
> 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.
It's common sense to assume that person-to-person e-mail never has a
null sender. It's not common sense to block all null senders as a
result. You are rapidly approaching the lunatic fringe of your side of
this so-called "argument" by implying that allowing null senders is
done to allow person-to-person(s) mail.
> 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?
It's not stupid, because the null reverse-path has a specific meaning
that is outlined in several RFCs which you appear to not have read
thoroughly.
--Sandy
------------------------------------
Sanford Whiteman, Chief Technologist
Broadleaf Systems, a division of
Cypress Integrated Systems, Inc.
e-mail: [EMAIL PROTECTED]
SpamAssassin plugs into Declude!
http://www.mailmage.com/download/software/freeutils/SPAMC32/Release/
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html
List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
