[Info-vax] Decuserve.org - Anyone know why it's down?

[Bill Gunshannon]

In article <m8kc5l$dfq$1 at news.kjsl.com>,
	helbig at asclothestro.multivax.de (Phillip Helbig (undress to reply)) writes:
> In article <ch2tvvFsca0U1 at mid.individual.net>,
> bill at server3.cs.scranton.edu (Bill Gunshannon) writes: 
> 
>> >> But people should realize, places that accept email from sites who's
>> >> A Record and PTR Record do not match are mis-configured.  Period.  The
>> >> RFC's explaion everything you should be doing.  
>> > 
>> > RFCs also say to bounce an email sent to a non-existent user.  These 
>> > days, this is a source of backscatter spam and a quick way to get 
>> > yourself marked as a spammer (since you will bounce to the forged From: 
>> > address, which is the real adddress the spammer wants to spam).
>> 
>> I doubt many places still "bounce" those messages.  My server checks for
>> existence of a user and if there is none just drops the message on the
>> floor.
> 
> I do the same.  According to the RFCs, our mail receivers are 
> misconfigured.

As I said, 90% or more of email servers are mis-configured.  What
needs to be taken into consideration is wether the mis-configuration
is due to a) incompetence, b) mis-understanding, c) out of date
standards.  I haven't read it in a rather long t ime but if the
RFC still says you need to bounce undeliverable email it really
needs to be updated.  Bouncing should be optional and controlable
as to what and for whom a message may be bounced.  In the meantime,
I will continue to drop them on the floor.  In my environment, a
location with a high user turnover and users who don't clean-up
their accounts before leaving, bouncing would be a major problem
even without worrying about backscatter.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>