ietf-smtp
[Top] [All Lists]

Re: rfc2821bis-03 Issue 25: Re: Recap Issues 0b/21/25

2007-04-30 15:02:01

Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
David F. Skoll wrote:

<snip language about "proper failure report">

SHOULD, should, recommended, or RECOMMENDED, what's going to happen
with those huge log files, apart from deleting them by a cron-job ?

1) disk space is cheap;
2) they presumably will be rotated, and only deleted after a week or
   more;
3) parsing them by a script looking for an incident will be simple.

If we avoid defining what a "proper failure report" is and leave it
up to SMTP implementors, I fear that e-mail will become completely
unreliable (instead of somewhat unreliable as it is today.)

Yes, but it's your proposal to say "SHOULD bounce" instead of the
"MUST bounce" in 2821.  I fear that this is another a loophole to
avoid real (and painful) solutions, based on "reject at the border".

   "Reject at the border" is already becoming a normal practice: be
patient...

I wouldn't be happy if an SPF PASS ends up in a log file deleted by
a cron job.  Maybe your SHOULD needs a qualifier:  "If the receiver
cannot validate the return-path then" etc.  

   We cannot presume universal use of SPF.

   OTOH, I could live with your wording...

For the "normal" case (in my parallel universe that's an SPF PASS
or a similar case :-) I'd like to keep the "MUST bounce" as it was.

   Don't hang on too tight to that horse -- it's pining for the
fjords... :^(

--
John Leslie <john(_at_)jlc(_dot_)net>