Subject: RE: [Asrg] Rejecting Email

From: "Eric D. Williams" <[email-masked]>
Date: Tue, 1 Apr 2003 09:49:56 -0500

On Monday, March 31, 2003 11:50 PM, Steven F Siirila [SMTP:[email-masked]] 
wrote:
8<...>8
> I was just pointing out that we don't "refuse to listen to them".
> In fact, we occasionally get questions posed to our mail administration
> address (apparently from those that don't go past the first URL) asking
> why we are blocking them.  That address never blocks mail, of course.
>
> However, I do understand your point.  Every site will have differing
> requirements when it comes to blocking/filtering mail.  It is precisely
> this reason that sites should have available one or more configurable
> solutions at their disposal.  There is no one-size-fits-all that I can see
> at this time.

Should sites that block/filter, etc. include a 'standardized' link to a 
statement of policy or 'reason' description for blocking the message?  Of 
course we do have the abuse@ address [RFC2142] that is defined for CRM but what 
if there were also a standard address or 'link' to policy descriptions for 
blocking/filtering behavior?  This is not an proposal for a standard message 
but a standard Location: for such a message.

-e
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 1 Apr 2003 09:38:40 -0700 (MST)

> From: "Eric D. Williams" <[email-masked]>

> ...

HTTP is not SMTP.  If it were not impossible, it would also be a
mistake to mandate that every SMTP server be associated with an HTTP
server.  Thus "link" cannot mean "URL".  It would be almost as bad to
require that every SMTP server be associated with an STMP auto-responder
of some kind.

It is a good idea to communicate why a mail message was been rejected,
but it cannot and should not be mandated.  Rejecting mail does not
differ enough from rejecting connections from HTTP, FTP, or even telnet
clients.  Sometimes your security policies allow your computers to
say why they won't provide a given service, but sometimes they must
say at most "go away."

There have been suggestions or proposals in this mailing list for a format
or schema for more lucid bounce messages.  I'm convinced that is hopeless
by many things including the 20 years of efforts to make STMP error
messages understandable by more than high priests.  Still, such efforts
might have good results and are unlikely to do any harm here, because
bad results could not be imposed by pointy haired fiat.

(Anyone with much experience in the industry has seen efforts to make
computer error messages understandable do serious harm by making the
message long and unintelligible to absolutely everyone, including the
user interface mavens or other non-technical people responsible for
the "improved" messages.)

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg