Hello all; (new to the RG and list...
This message I think presents a fundamental problem that I have not seen
addressed (or at least referred to to-date) in the discussion, perhaps a
reading of the archives is in order or a document archive contains such. What
I am referring to is a Statement of Requirements that enumerates an acceptable
solution. Below is such a beginning, and without such a document I don't think
much headway can be made.
In addition, methods for addressing this "engineering" issue could quickly
devolve to a 'religious war' of principle OR, an unwanted debate that has no
objective technical basis. As this is the case, and with due reference to the
discussion below, I feel a discussion thread or drafting activity - which would
be happy to participate in
http://new.infobro.com/AboutUS/People/EricWilliams/ericwilliams.html - on a
specific, logical and concise requirement document is suggested.
Taking a language from the note below:
1. We stop forgeries of mail headers and force all senders to reveal
their name (but that I mean source, not actual name for personal emails,
etc).
Requirement 1) The proposal MUST address the issue of RFC821 [or envelope
protocol] originating MTA/MUA authenticity.
2. We provide means for mail servers to authenticate in such a way that
spammer can not easily change just their domain or their ip and begin
sending email again (they'd soon be detected and their mail server
blacklisted).
See Requirement 1).
3. Law outlaws sending unsolicited commercial email
Requirement 2) The proposal SHOULD be amenable to legislation, in place or
pending as close as possible.
4. ISPs use filtering to get rid of unwanted spam that may still path
through the cracks (i.e. spammer got new mail server and it has not been
blacklisted yet or they hijacked the server, etc. etc.)
Requirement 3) The proposal MUST provide a flexibility for integration with
other ANTI-SPAM (UBE/UCE) approaches [it shouldn't break anything].
Requirement 4) The proposal SHOULD provide implementation specifics that
address the issues of privacy, security and which reflect end use choices, of
either providers or users.
Requirement 5) The proposal SHOULD/MAY [not sure how strong this would be as a
requirement] include a mechanism for implementation in messaging relay systems
(MX hosts), end use 'post offices' (MTAs), and end node mail recipient systems
(MUAs). Proposals that include only one of these messaging system components
MUST include mechanisms for interaction with the other components.
Requirement 6) The proposal MAY include a method for extension to or
integration with other protocols, e.g. HTTP, that may be used to relay
messages.
I feel there are many more 'technical' requirements which can be discussed in
turn, but first some requirements may be in order. In any event, these at
least provide a strawman from which further discussion may be derived and do
appear to satisfy the framework described in the charter.
my $.02
-----
Eric Williams
PGP Public Key
http://new.infobro.com/KeyServ/EricDWilliams.asc
Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789
On Thursday, March 27, 2003 11:33 PM, william(_at_)elan(_dot_)net
[SMTP:william(_at_)elan(_dot_)net]
wrote:
On Fri, 28 Mar 2003, Kee Hinckley wrote:
At 6:11 PM -0800 3/27/03, william(_at_)elan(_dot_)net wrote:
Opt-out will not be effective all by itself.
Of the proposals we have seen so far, which would change the dynamics
of opt-out as I've described them?
The proposals offered so far are incomplete, that is why we all can not
decide on any one... But I'll tell general solution:
1. We stop forgeries of mail headers and force all senders to reveal
their name (but that I mean source, not actual name for personal emails,
etc).
2. We provide means for mail servers to authenticate in such a way that
spammer can not easily change just their domain or their ip and begin
sending email again (they'd soon be detected and their mail server
blacklisted).
3. Law outlaws sending unsolicited commercial email
4. ISPs use filtering to get rid of unwanted spam that may still path
through the cracks (i.e. spammer got new mail server and it has not been
blacklisted yet or they hijacked the server, etc. etc.)
This leaves commercial opt-in email lists where company is setup as real
business that does not hide itself and they get permission to send user an
information on their product (airline ticket offers) but you do not want
to receive "extra" advertisements of credit card offers as you're not
interested in that. This is where opt-out system comes in and helps,
it regulates commercial email and forces them to respect your wishes.
Now the system I described allows for automated white-listing of certain
commercial emails where users want to receive them - that will help on
filters and allow them to be more effective and have less false-positives.
--
William Leibzon
Elan Communications Inc.
william(_at_)elan(_dot_)net
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg