ietf-822
[Top] [All Lists]

Re: ABNF, and miscellany

2005-05-13 00:46:12

Bruce Lilly wrote:

I suspect that they move on to other documents.

Yes, most likely.  And while I didn't study all details in
Bill's nice PDF there was no 2234bis entry.  BTW, noted as
the 2nd PDF I've seen for ages working even on my OS/2 box.

e.g. the unused
  3*5[foo]
construct.  After some thought, you may realize that that's
equivalent to *5foo

I'd expect 0, 3, 4, or 5 foo.  If what you say is true it has
"a high astonishing factor", one of the taboos in my religion.

You probably interpret "is equivalent to" as "syntactically
equivalent", everywhere, in all contexts, i.e. 3*5*1(foo).

I've no idea how to interpret a hypothetical 3*5*1(foo), it's
a bit like 2^3^2 or 2**3**2, 64 or 512 ?  If in doubt LTR, 64.

Same idea for 3*5*1(foo) => 3*5(*1(foo)) => 0, 3, 4, or 5 foo.
That's what I expected, how do you get *5(foo) ?  I don't see
1*2(foo).  But I love syntax puzzles ;-)

BTW, to fix this, if it's at all a problem, it would be enough
to replace "*1(foo bar)" by "(*1(foo bar))", similar in 3.7.

OTOH it says "repetition before optional", and "optional" has
the same priority as "grouping",  So that's 3, 4, or 5 of an
optional foo => 0, 3, 4, or 5 foo.  If it ain't broken...

Now nobody is going to exploit ABNF oddities

You mean nobody excluding you and me ?  <gd&r>

next thing you know nobody is following the rules.

BTW, empty rules, I knew how Keith did it in RfC 3834, another
solution is:  prose-val = "<" *(%x20-3D / %x3F-7E) ">"

Credits to Bill Fenner, I was blind.  But I'm determined that
the drafts I'm interested in follow all rules.  That could be
another problem in your review form, it mixes formal issues
and technical issues.

Of course both kinds are interesting and relevant, but in the
case of say 2368bis it might be better to split it.  OTOH as
long as the author doesn't answer reviews, dito here on this
list his Archived-At I-D => DNP :-(

Yes, as in RFC 822:
   CHAR        =  <any ASCII character>

Okay, if it's used to import stuff like RfC 20, but a line...

     atom        =  1*<any CHAR except specials, SPACE and CTLs>

...is hard to read, a proper enumeration like atext in RfC 2822
with the prose as comment is IMHO better.

And in my parallel universe three IESG members MAY overrule you,
see <http://mid.gmane.org/E1DWIdy-0004gS-Ug(_at_)newodin(_dot_)ietf(_dot_)org> 
;-)

USEFOR has gone so far down a rathole as to be unsalvageable

The last usefor-03 draft was very close to ready from my POV.
Otherwise I intend to salvage at least its msg-id syntax with an
"updates: 1036, 2822", if you're interested I can post it here.

"reverse-path which can be used to report errors" (STD 10)

Yes, it "specifies who the mail is from", "a return route (which
may be used to return a message to the sender when an error
occurs with a relayed message)", "contains the source mailbox",
"a reverse source routing list of hosts and source mailbox",
"a source route from the current location of the message to the
originator of the message)".   Finally "send it to the originator
of the undeliverable mail (as indicated by the reverse-path)".

Want more ?  I skipped some less CLEAR "should", but when I said
*_criminal negligence_* about any "bounces-to" I was NOT joking.

My, how blithely you wave away other people's real problems. See
http://www1.ietf.org/mail-archive/web/asrg/current/msg12017.html

That was about draft-hutzler-spamops-04, a perfectly sane future
BCP.  The spiritus rector of the "bounces-to" friends is one of
its co-authors, it does nowhere mention a "reverse path".  Let's
discuss this on the SMTP list.

see JCK's recent message on ietf-smtp.
Earlier:  
<http://mid.gmae.org/427AF416(_dot_)3E1D(_at_)xyzzy(_dot_)claranet(_dot_)de>

HELO FQDN (otherwise "neutral" => forget it, see above).
Many times not under the control of the sender.

Of course.  But for all host names (FQDNs) under your control
you are free to publish which IPs they use if they say HELO in
an SMTP session.  For more details check the list of authors in
draft-ietf-marid-cvs-csa-02 and draft-ietf-mardid-intro-02

There are many details where STD 10 / RMX fans like me and the
"bounces-to" fans actually agree.

That won't slow down spam

It certainly slows bounces to innocent bystanders, "my" spammer
got the idea after about four months.  With a V.90 line I know
that there's a difference between zero and 1000 bounces per day.
Not *1000( foo ) but really *1( 1000( foo ))

it will inconvenience many legitimate senders.

That's why it's a voluntary system for those wo really want it.

It is widely known that spammers are early adopters of SPF and
similar wacky schemes.

Yes, it's not voluntary for spammers, they are forced to respect
it if they want to reach their primary victims.  Read:  No more
"bounces to" protected secondary victims (forged reverse paths).

Several billions of bacteria eat feces; that doesn't make it
a good idea for all organisms.

I'm not sure about the "voluntary" in your example.

 [at the end of 4.1.1.2]
| "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF

That's nice. And when you make "final delivery", what will you
put in the Return-Path field?

| notification MUST be sent using a null ("<>") reverse path

Found in 6.1.  Okay, maybe it's not exactly clear.  The STD 10
syntax has the same issue, <mailbox> can't be empty.

have you ever tried to change what your "Mozilla 3.0" uses?

Sure.  It assumes that I have an FQDN or get lost.

I suspect you'll find that it uses the RHS of your mailbox as
the HELO domain.

AFAIK it uses the output of "hostname.exe" aka gethostame() (?)

Any mail provider expecting 100% accurate FQDNs in the HELO of
his own users (on the "ours" side) will be soon out of business.

                             Bye, Frank