On Tue, 17 Feb 2004, Vernon Schryver wrote:
> > From: "william(at)elan.net"
>
> > > It is also a classic example of what is wrong with the MUA filtering
> >
> > You certain dont assume that there is nothing wrong with the filtering
> > system you use and others may try duplicate as well. Otherwi
> From: "william(at)elan.net"
> > It is also a classic example of what is wrong with the MUA filtering
>
> You certain dont assume that there is nothing wrong with the filtering
> system you use and others may try duplicate as well. Otherwise how would
> you explain that you have Elan and comple
On Tue, 17 Feb 2004, Vernon Schryver wrote:
> It is also a classic example of what is wrong with the MUA filtering
You certain dont assume that there is nothing wrong with the filtering
system you use and others may try duplicate as well. Otherwise how would
you explain that you have Elan and c
Thn enclosed example of how not to filter spam is offered for those
who might want to preemptively add accuspam.com or downloadfast.com
to their blacklists.
It is also a classic example of what is wrong with the MUA filtering
tactics Robert Brown advocates.
I certainly did not try to contact any
> From: "Robert G. Brown"
> ...
> Or, mark for later accept/reject decisioning AFTER the SMTP server per
> se, in the filter pipeline between the server and the mail spool of the
> addressee. Spam assassin does the right thing already (and this is
> exactly what it does).
***NO***! Except when
On 17-feb-04, at 23:47, Robert G. Brown wrote:
This is where, and why, I take issue with filtering and discarding at
the level of the SMTP server, unless the accept/reject decision can be
made with 100% precision
Imagine a networking transport protocol such as TCP, that discarded
packets not base
On Tue, 17 Feb 2004, Vernon Schryver wrote:
> >(Silently discarding _is_ a bad idea, when done by the SMTP server
> > itself. IMHO, it's better to mark for later discard -- which actually
> > could be done in such a way as to mark only for those recipients who
> > requested the more restrictiv
Hi All,
The EDU Team is offering several training sessions on Sunday afternoon in Seoul
that are open to ALL IETF ATTENDEES. These sessions include:
- Newcomers Training (in both English and Korean)
- Editors Training
- Introductory WG Chairs Training
- Security Tutorial
Details about these sessi
At 8:55 AM -0800 02/17/2004, Ted Hardie wrote:
It would be useful if those present were familiar with the previous work
in METAD and FIND as well as the citations given in the BoF
agenda.
By the way, the old FIND charter and documents are listed here:
http://www.ietf.org./html.charters/OLD/find-c
> From: John Leslie
> ...
> > - local administrative choices that keep bastion SMTP servers ignorant
> > of per-user filter preferences
>
>This is a feature, not a problem. If the end user wants a filtering
> process individualized that much, s/he should choose to use a SMTP
> server
Vernon Schryver <[EMAIL PROTECTED]> wrote:
>
> I know of many millions of spam that are filtred during the DATA command
> every day, and I don't claim to know about any really big sites.
>
> The only problems are:
> - local administrative choices that keep bastion SMTP servers ignorant
>
At 6:38 PM +0800 02/17/2004, wang liang wrote:
There has been some discussion for Internet information retrieval service in
work groups of IRTF. Now this issue will be discussed in the BOF of
Application Area.
As one of most important services of Internet, current information retrieval
service is s
A new IETF working group has been proposed in the Routing Area. The IESG has not made
any determination as yet. The following description was submitted, and is provided for
informational purposes only. Please send your comments to the IESG mailing list
([EMAIL PROTECTED]) by February 19.
Routi
There has been some discussion for Internet information retrieval service in
work groups of IRTF. Now this issue will be discussed in the BOF of
Application Area.
As one of most important services of Internet, current information retrieval
service is still far from our expectation---precise, compr
14 matches
Mail list logo