Subject: [Asrg] 7. BCP - Areas of research

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 07 Dec 2003 01:35:22 -0500

As part of our BCP efforts, we want to determine which areas we should 
pursue, and how to proceed in them. Below is a copy of a message from 
the old BCP list outlining some of the areas we can be looking into. We 
are seeking comments from list members about this, and will consider 
creating subgroups to pursue specific efforts.

Sincerely,
Yakov Shafranovich
Co-Chair, ASRG

----------------------------------------------------------------------------------------
> Date: Sun, 30 Nov 2003 16:47:36 -0500
> From: Philip Miller
> To: ASRG-BCP Mailing List
> 
> In light of the recent discussions on the list involving how a recipient MTA
> should respond to the current practices of senders, I thought we should try
> to assemble a list of everyone whose practices we might make recommendations
> for.
> 
> Here's my first cut at such a list:
> 1. Message originators - human users, automated software
> {developers,administrators} (order confimation/receipt systems)
> 2. Message originating system {administrators,developers} - the MTA which
> the originators connect to. Normally, this is a corporate or ISP MTA. In
> this role, an MTA is moving a message from submission to transport.
> 3. Relaying MTA {administrators,developers}
> 4. Recipient MTA {administrators,developers}
> 5. Final recipients - human users, automated software {admins,devs}
> 6. MUA Authors
> 7. Support personnel (corporate IT/help desk, ISP installers, etc.)
> 8. Message examination software {devs,admins} - Spam filters, virus scanners
> 9. Mailing list software - developers, admins, subscribers, users
> 
> I expect that I've missed a few here.
> 
> Once we have a relatively comprehensive list, we should assemble all of the
> 'common sense' best practices that have been somewhat implicit in
> discussions on this list, but may not be eminently apparent to any random
> person. We can collect them for draft publication, but we should probably
> evaluate them first in light of their effect.
> One practice that is assumed but rarely explicitly stated is strictly
> following the relevant standards and pushing users to do the same. For
> example, the Postfix documentation recommends using a domain name in the
> $myorigin configuration setting (used as its outgoing HELO/EHLO argument),
> but it doesn't make it clear that there are relevant standards that have
> place requirements on the contents of this field. It's quite possible to
> place random garbage here instead of an FQDN, and I don't think Postfix even
> prints a warning if one does.
> 
> Philip Miller

-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"Some lies are easier to believe than the truth" (Dune)
-------

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

---

From: Matthew Elvey <[email-masked]>
Date: Sun, 07 Dec 2003 12:52:49 -0800

On 12/6/2003 10:35 PM, Yakov Shafranovich sent forth electrons to convey:

> the old BCP list outlining some of the areas we can be looking into. 
> We are seeking comments from list members about this, and will 
> consider creating subgroups to pursue specific efforts.
>
>> ...Here's my first cut at such a list:... 
>
http://www.bestprac.org/principles.htm has a pretty extensive list, and 
someone's opinion of what the BCPs are, laid out in extensive detail.  
I'd like to see prepay forfeit, deposits and/or cleanup fees be BCP.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 07 Dec 2003 16:42:54 -0500

> I'd like to see prepay forfeit, deposits and/or cleanup fees be BCP.

I took a quick look at that site, the information seems to be very 
concise. We were thinking of something more along the lines of RFCs 
2505, 2635 and 3098, outlining the information and the reasons behind 
it, as well as adressing some of the conflicts with existing RFCs such 
as permissibility of filtering during SMTP, etc. We can definatly use 
that information and it will probably need to be expanded further.

Yakov
-------
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"I ate your Web page. / Forgive me. It was juicy / And tart on my 
tongue." (MIT's 404 Message)
-------