SORBS Contact

Matthew Sullivan matthew at sorbs.net
Thu Aug 10 04:53:29 UTC 2006


Allan Poindexter wrote:
>   Matthew> so would you consider as it is my network, that I should
>   Matthew> not be allowed to impose these 'draconian' methods and
>   Matthew> perhaps I shouldn't be allowed to censor traffic to and
>   Matthew> from my networks?
>
> If you want to run a network off in the corner by yourself this is
> fine.  If you have agreed to participate in the Internet you have an
> obligation to deliver your traffic.
>   
That's a very "interesting" statement. Here's my response, I'll deliver 
your traffic if it is not abusive if you delivery my non-abusive 
traffic.  My definition of 'abusive' is applied to what I will let cross 
my border (either direction) - I expect you will want to do the same 
with the traffic you define as abusive, and I expect you to and support 
your right to do that.
> There are simple solutions to this.  They do work in spite of the
> moanings of the hand wringers.  In the meantime my patience with email
> "lost" silently due to blacklists, etc. is growing thin.
>   
Anyone using SORBS as I have intended and provided (and documented) 
will/should not silently discard mail.

If anyone asks how to silently discard mail I actively and vigorously 
discourage the practice.*  In fact because I disagree with that even in 
the case of virus infected mail I patches my postfix servers to virus 
scan inline so virus infected mail can be rejected at the SMTP 
transaction. RFC2821 is clear when you have issued an ok response to the 
endofdata command you accept responsibility for the delivery of that 
message and that should not fail or be lost through trivial or avoidable 
reasons - I consider virus detection and spam as trivial reasons - if 
you can't detect a reason for rejection at the SMTP transaction, deliver 
the mail.

Regards,

Mat


* except in extreme/unusual circumstances - for example, there are 2 
email addresses that if they send mail *to* me, they will get routed to 
/dev/null regardless of content.



More information about the NANOG mailing list