Subject: [EAI] Random comment on http://www3.ietf.org/meetings/ietf-logs/eai/2006-11-09.html :-)

From: Kari Hurtta <[email-masked]>
Date: 12 Nov 2006 13:18:05 +0200

[17:23:26] <pguenther> downgrading in the 8bit mime case similar
[17:23:44] <pguenther> bouncing is problematic: blowback spam (aka joe jobs)
[17:24:08] <pguenther> confidence in anti-spam required?
[17:24:30] <pguenther> randy: do we really have another choice?
[17:24:50] <pguenther> randy: proposals for better bounces exist

MAIL FROM:<...>   command on SMTP can be replaced with something else
but I do not think that it task of that working group ....

( IE. Bounces are not sent, but instead retriaved by original sender
      of mail.  However that kind changes are little too much  for
      internet mail architecture.... )

/ Kari Hurtta

  ( I guess that someone will then say "write draft", but I think
    that pain of misdirected bounces are not high enough compared
    with problems associated with change of architecture. )

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

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 12 Nov 2006 15:56:04 +0100

Kari Hurtta wrote:
 
> I guess that someone will then say "write draft"

Don't worry, 4408 is already published...

> pain of misdirected bounces are not high enough
> compared with problems associated with change of
> architecture.

...it's unnecessary to change the 821-architecture
with its literal reverse paths, only implementing
it after that feature was killed is difficult.  In
I-D.crocker-email-arch-05 (5.1) it's a SHOULD.

If nothing of 551, SPF, BATV is satisfying the pain
could force us to replace SMTP by IM - if IM is good
enough to replace SEND FROM maybe it can also handle
MAIL FROM.  I've no clue what bugs would expect us 
with xmpp, but it's designed to be TLS + UTF-8 ready.

Wrt UTF8SMTP and its funny "UIGO" aspects, maybe we
could address it at the MSA - the MSA could somehow
verify that the reverse path can handle UTF8 DSNs,
and otherwise reject the submission, a similar idea
as in 4409 (6.1) "enforced submission rights".

Frank