----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, June 25, 2005 11:37 AM
Subject: [spf-discuss] Re: DM News says: MSN requires Sender ID
Authentication
Which RfC, chapter or page number, says "create missing 2822
header field from the envelope for received SMTP data" ? You
said that this is a _standard_ claiming authority in the field,
and I want to see where it is, because so far I didn't know it.
I went through that (last message) and you really don't understand yet?
Frank, the odds are good, will you not see a standard how the ergonomics
of a MUA or BBS or ONLINE system will behave or designed, nor the gateway
conversion or transformation process. Probably the closet thing is RFC
1123.
I guess it is so much common sense, no one bother to put write it down.
Why would look for it? Maybe someone did bother to mention it somewhere in
the annals of the RFC drawers.
Overall, you need to understand all the PIECES and see it all as a system
engineer and then it will make sense to you Frank.
I would guess you might find it in in "some" document that described an
Integrated Environment, that puts all the pieces together.
But it is all common sense:
BBS/Online Host/OffLine Reader
From: X
To: Y
Text: DUH!
Gateway Export
[Network Header Block]
Network From Address <--- From:
Network To Address <--- To:
Message Header Block
Body
[Optional Header Block, some Networks]
Transport
Network From Address
Network To Address
Payload
Gateway Import/Transformation
From: <-- Network From Address, if From Missiong
To: <-- Network To Address, if To Missing.
BBS/Online Host/OffLine Reader
From: X
To: Y
Text: DUH!
Of course, you have all the extra stuff, and other ideas that may alter the
Network From Address aka Return Path. This is the same for Fidonet too
Frank!
Frank, most online mail systems (attleast commercial ones) all had gateway
programs. Something one gateway works generically for many systems, but
most of time is it built-in or some 3rd party author created the Interface
between a gate and the online system. But the key was the user address
translation, for example:
Frank Ellermann <---> Frank(_dot_)Ellermann(_at_)winserver(_dot_)com
or:
Local user From: <---> Network From Address
So incoming mail into the system will automatically give you mail and mail
you create is automated translated into a network format for outbound and so
one.
Maybe it's in the same RfC where "MDA" is defined, and I don't
have this RfC on my hard disk. It's also needed for the next
draft-hutzler-spamops.
Well, maybe. Let me take a quick look at RFC 1123 Hosting Requirements, I
already like this document since it covered ideas for internet HOSTING
systems like us. Needs to get updated though.... looking....Ok, I don't
wish to get into semantics, but for a person like me it is obvious. Dig
around RC 1123 and see if you grab various sentences. But sees section
5.3.7 section.
- Final Destination/storage?
Sure, I know the submit/MSA part, 2476(bis), or the 821/1123
ideas, but what you tested was data without 2822 header fields.
If an odd Sender-ID implementation tries to test a missing PRA
before an ersatz-2822-From is created from the envelope, then
it's just buggy, no surprise.
I don't follow you.
Maybe I have a hard time with SenderID because I don't see it fit well into
the mail system infrastructure efficiently or reliably. So maybe others
(administrators, having nothing better to use) try to FIT it into the
picture and then try to use it as a justification to change long BCP
methods.
I'm a technical software engineer. I see something good, I embrace it and
give credit where credit is due. SenderID/PRA does it do it me for. It is
bad. Plain and simple and the repercussions are already being felt. I can
see the harm starting with Hotmail.com. I hope others don't follow this
behavior. I already see the Market Confusion with my customer base
implementing SPF2.0/PRA when we never declared any kind of support for it.
Adding it for other PRA systems to check, but not adding a SPF1 tell me the
"Chieftain effect" is in play - follow the noise.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com