Markus Stumpf | 4 May 00:50 2005
Picon

deja vu: draft-grandhi-pc-smtp-00.txt


AFAIK the same type and idea of proposal as discussed before in
    draft-arun-ncc-smtp-02.txt
with the same flaws and even from the same group ... HP India.

Now the field is called Pc instead of Ncc.

The author agains completely mixes 2821 and 2822.

Reminds me of some broken handheld (psion?) software in the end 90s.
They sent the Bcc field along for the SMTP server to take care of it.

	\Maex

--

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

willemien | 4 May 12:30 2005

Re: deja vu: draft-grandhi-pc-smtp-00.txt


I agree with Markus
This draft  is only good to test your knowledge of the various mail protocols by finding all the errors in this one.

On a first quick reading I discovered 3 errors

1 wrong naming of RFC's
2 non existing entities (SMTP headers???)
3 (RFC2822?) headers changing by non recognising MDA's?? (that means nothing less than a non backward compatability)

Who can find more errors ...

> 
> AFAIK the same type and idea of proposal as discussed before in
>   draft-arun-ncc-smtp-02.txt
> with the same flaws and even from the same group ... HP India.
> 
> Now the field is called Pc instead of Ncc.
> 
> The author agains completely mixes 2821 and 2822.
> 
> Reminds me of some broken handheld (psion?) software in the end 90s.
> They sent the Bcc field along for the SMTP server to take care of it.
> 
> \Maex

Arun Sankar | 4 May 18:30 2005
Picon

Re: deja vu: draft-grandhi-pc-smtp-00.txt


Hi Mark,

ncc and pcc are vastly different utilities. Similar mail header addition 
is one similarity though. But I guess the kind of application and the 
kind of audience both are looking at are very different.

Ncc is more of a negate that simplifies the users work in typing out a 
whole lot of mail-ids and utilize the availability of aliases which are 
available. We had discussed already of the inability for the whole world 
to apply to it. But it is the same case with a broken MTA who may have 
the Cc not implemented properly. To be more practical it can be 
implemented probably on an org wide scale wherein mandated MTA's and 
MUA's are to be used and this is not seen like a push it down the throat 
feature but a take it if you feel like feature.

Another point that came about is utility of the ncc feature. We do not 
argue the utility of the Cc feature, though it is similar to the To 
field, Cc has its own merits and just because someone does not use the 
To field and the Cc field is very redundant, we do not go ahead and 
think of removing the Cc. Ncc is more of a feature that is helpful to 
all who do a lot of mailing to aliases and I do not mean mailing-lists 
when I say aliases.

I guess branding the both as a deja vu might not be entirely ok just 
because they sound similar.

(a deja vu occurs where there is a change in the Matrix ;))

willemien <at> amidatrust.com wrote:
(Continue reading)

Frank Ellermann | 4 May 19:12 2005
Picon
Picon

Re: deja vu: draft-grandhi-pc-smtp-00.txt


Arun Sankar wrote:

> ncc and pcc are vastly different utilities

Yes, if you want PCC you'd implement it somehow at your MSA.

All it does is to take a list of addresses, forward one mail
to each recipient, and copy the corresponding RCPT TO to the
2822 To.  Doing it at the MDA is backwards, not allowed, and
won't fly without a "worldwide update" (the FUSSP paradox).

                     Bye, Frank

Bruce Lilly | 4 May 20:02 2005
Picon

Re: deja vu: draft-grandhi-pc-smtp-00.txt


On Wed May 4 2005 12:30, Arun Sankar wrote:

> But it is the same case with a broken MTA who may have 
> the Cc not implemented properly.

MTAs don't "implement" Cc.  MTAs (SMTP, see RFCs 821, 2821) have only
RCPT TO.  The distinction between "To" and "Cc" is in (human) user space,
and is not well-defined even there.  Moreover, while delivery
conventionally is consistent with user-level text in the message header,
there is no requirement that that be the case, just as with physical mail
(nothing prevents one from putting a check to a utility company in an
envelope addressed to a family member, or a personal letter intended for
a family member in an envelope addressed to a utility company).  Don't
mess with user-to-user (message header) communications; see
draft-lilly-field-specification-03.txt, section 4.3.1 -- for HTML fans,
try
http://users.erols.com/blilly/Internet-Drafts/draft-lilly-field-specification-03.html#4.3.1

Bruce Lilly | 4 May 20:42 2005
Picon

Re: deja vu: draft-grandhi-pc-smtp-00.txt


On Wed May 4 2005 06:30, willemien <at> amidatrust.com wrote:
> 
> I agree with Markus
> This draft  is only good to test your knowledge of the various mail protocols by finding all the errors in
this one.
> 
> On a first quick reading I discovered 3 errors
> 
> 1 wrong naming of RFC's
> 2 non existing entities (SMTP headers???)
> 3 (RFC2822?) headers changing by non recognising MDA's?? (that means nothing less than a non backward compatability)
> 
> Who can find more errors ...

4. the formatting is screwed up (no formfeeds between pages)
5. the boilerplate is out of date
6. published this month, but with last year in the copyright lines
7. ABNF rule "display-name" undefined
8. based on a flawed assumption that transport uses message content
   rather than SMTP command arguments
9+:
idnits 1.71 (02 May 2005)

draft-grandhi-pc-smtp-00.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
  * The document seems to lack separate sections for Informative/Normative References.
(Continue reading)

Markus Stumpf | 4 May 21:45 2005
Picon

Re: deja vu: draft-grandhi-pc-smtp-00.txt


On Wed, May 04, 2005 at 10:00:34PM +0530, Arun Sankar wrote:
> to apply to it. But it is the same case with a broken MTA who may have 
> the Cc not implemented properly.

Ok, I'll give you a mantra:
   rfc2821 is different from rfc2822.
   SMTP servers don't care about mail headers (**)

If you type in addresses to the 2822.To and 2822.Cc and 2822.Bcc and
2822.From lines in your mail client it is in the scope of the MUA to
"translate" them to correct RFC2821 syntax, i.e. send appropriate
MAIL FROM: and RCPT TO: commands in the SMTP dialogue and remove any
Bcc: lines. A SMTP MTA doesn't even know what those funny characters
are/mean, which it receives during the DATA (Dont Anytime Touch Anything)
phase.

If in real life you write a letter (this is rfc2822) and give it to your
secretary (i.e. your mail client aka MUA) to make copies and send it to
the recipients and add them to your real life post folder s/he has to
put it in envelope(s) and put addresses on them (this is rfc2821).
And it is also in the scope of your secretary (aka the MUA) to write
correctly addressed envelopes taken from the information in your letter
and maybe the post-it [tm] on it saying whom to send a carbon copy (Bcc)
to and to not make copies with the post-it on the letter.
The postal system (this is the MTA) doesn't look at your letter inside
the envelope to see where to send it to. They don't care what is inside
the envelope and it is neither their job nor does anybody want them to
do that and read their letters.

(Continue reading)

Kartik Gopalan | 6 May 00:51 2005
Picon

draft-duan-smtp-receiver-driven-00.txt


We'd like to solicit feedback from the SMTP community on
our recent IETF draft titled "Receiver-Driven Extensions to SMTP".

http://www.ietf.org/internet-drafts/draft-duan-smtp-receiver-driven-00.txt

The abstract of the draft is attached below.

As we are new to the IETF process, we welcome any suggestions
pointing out potential improvements as well as deficiencies in the draft.

The following DiffMail project website and our related paper in SRUTI'05
might also be of interest.

http://www.cs.fsu.edu/~duan/projects/diffmail/diffmail.htm

Thanks,
Zhenhai Duan, Kartik Gopalan, Yingfei Dong

Abstract:

The Differentiated Mail Transfer Protocol (DMTP) provides simple
extensions to the Simple Mail Transfer Protocol (SMTP) that
enable receivers to exercise greater control over the email delivery
process. The current SMTP-based email delivery architecture is
fundamentally sender-driven and distinctly lacks receiver control over
the message delivery mechanism. This document describes DMTP
that enables receivers to classify senders into three categories -- allowed,
denied, and unclassified -- and process the delivery of messages
from each category independently. As is the current practice, receivers
may directly accept messages from senders in the allowed
category and decline senders in the denied category. In addition,
DMTP receivers require senders in the unclassified category to
store messages on the senders' own mail servers. Such messages
are retrieved only if and when the end receivers wish to do so.
By granting greater control over message delivery to receivers and
imposing greater message storage and maintenance overhead on
senders, DMTP provides significant advantages in controlling spam.
DMTP also easily operates in conjunction with (but does not require)
many currently deployed anti-spam techniques.

Markus Stumpf | 6 May 20:15 2005
Picon

port 773 vs port 587


I hope this isn't off topic here ...

Port 587 is "submission" (RFC 2476)
Port 773 is "submit"

I couldn't find real information to port 773 or "submit", but it seems to
be elder than submission, as I can find it already in RFC1700 (Assigned
Numbers).

I could also find
http://ftp.belnet.be/pub/mirror/ftp.ietf.org/ietf-mail-archive/ietf/2003-03.mail

   From: Dave Crocker <dhc2 <at> dcrocker.net>
   Date: Fri, 28 Feb 2003 19:37:45 -0600
   Subject: Re: IAB policy on anti-spam mechanisms?

   [ ... ]
   Email standards provide for posting of email to the usual port 25 or to
   port 773 for the newer "submit" service. (Submit is a clone of SMTP that
   operates on a different port and is permitted to evolve independently of
   SMTP, in order to tailor posting by originators, differently from
   server-to-server email relaying.)
   [ ... ]

which sounds exactly like "Message Submission" to me.

As "Message Submission" is a RFC and 587 is referenced in the RFC what
is 773 good for? Is this simply outdated information? Should 773 be
"deallocated" to stop further confusion or is "submit" really existing
and different to submission?

	\Maex

--

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

Matthew Elvey | 6 May 20:44 2005
Picon

Re: draft-duan-smtp-receiver-driven-00.txt (DMTP/DiffMail)

Given the initial crosspost, I'm doing the same (though they may be 
rejected) and suggesting all follow-up go to one list, only.  I suggest 
asrg.

FEEDBACK:
Yes, this is ~= IM2000, but with an improvement: it's potentially 
sometimes backward-compatible with SMTP.
Generally, this draft (which I'll refer to as DMTP or DiffMail) has 
features (the draft lists 3 advantages*) that, IMO, are better provided 
by other systems.
Addressing them in reverse order:
3)This is better provided by greylisting+.  That forces the sender to 
maintain something like a real mail queue.
2)Standard use of DNSRBLs (and sometimes RHSBLs with CSV or SPF) reduces 
bandwidth and storage costs more effectively and is compatible with all 
senders and most receivers today, with no code changes, and generally 
require just trivial configuration changes.
1)Again, greylisting allows a receiver a window of opportunity to allow 
the sender to get on a BL (or the message to enter a razor2 type DB) 
before receiving the message.  It is true, however, that DMTP does 
provide a potentially larger window, and does so without indroducing a 
significant delay.  The question is, is this worth the cost of requiring 
senders and receivers support new commands and a new reply code?

Confused by acronyms? See
<http://wiki.fastmail.fm/wiki/index.php/ClientSmtpValidation#.23Acronyms.2FGlossary>
for elucidation.

+See <http://greylisting.org>

*Purported Advantages:
   "1. By asking senders (non-regular contacts) to maintain messages on 
their mail servers, spammers are forced to keep their servers up. They 
cannot simply send a large number of spam messages, shut down their 
servers, and switch to another domain (and/or change IP addresses). In 
this way, DiffMail helps to improve the effectiveness of 
IP-address-based filtering schemes.
   2. Since a (complete) message is only retrieved by a receiver at his 
will, less bandwidth and storage resource will be consumed at the 
receiver side if the user does not retrieve the majority of messages 
from non-regular contacts.
   3. Spammers now have more responsibilities to maintain their outgoing 
messages[.]"

On 5/5/05 3:51 PM, Kartik Gopalan sent forth electrons to convey:
<snipped>

Gmane