william(at)elan.net wrote:
{typos]
don't "ignore" what you found, send them to me privately.
That's something for an "internal last call" or similar, at
the moment your ideas / concepts are more interesting for me.
Maybe I should be clear that supporting SUBMITTER is not
a prerequisite for this draft. Perhaps it might even be
better to completely remove reference to Submitter
If it's meant to be independent of SUBMITTER, sure, remove
the SUBMITTER examples (and maybe add it to your SUBMITTER
draft).
There are other parameters that change during forwarding
then just "recepient" (which optionally may appear as "for"
clause in received) and draft is done to be able to capture
all these changes both for envelope and for headers.
I'm still uncertain about the new header, are you sure that
it can't be done with an upgraded time stamp line ? IIRC
there's a IANA registry for stuff like "from" "by" "with"
"for", maybe it's posssible to add your info to Received:
somehow.
Reason: In the worst cases the order of headers could be
modified resp. headers could be removed. It's evil, but
shit happens, and mail normally survives. Received: has
a built-in "resort" capability ("by A" below "from A").
Of course Sender-ID "Resent-abuse headers" won't survive
broken mailers, but we all know that Sender-ID is FUBAR.
Ah, supporter of rfc-ignorant - good to hear.
Sometimes. I still think that whois.denic.de is only
"stupid" but not "ignorant" (given that the IAB destroyed
RfC 954 without the obvious UTF-8 solution). But the IAB
is determined to destroy the Internet, and we all live on
borrowed time until all the evil forces agree on a common
strategy to get rid of the last rests of a free and simple
internet (like whois or gopher). But I digress.
Just a reminder if you were reporting ipwhois problems,
Rarely, but I was of course delighted when I could... ;-)
http://www.completewhois.com/invalidwhois/invalid_ipblocks.htm
Okay, I'll add...
$reverseip$.combined-hib.dnsiplists.completewhois.com
...to <http://purl,net/xyzzy/src/rxwhois.cmd> - acess on the
bogon list could be nice. Oops, but it doesn't work at all:
unknown 2.0.0.127.combined-hib.dnsiplists.completewhois.com
unknown 2.0.0.127.invalidwhois.dnsiplists.completewhois.com
Removing "completewhois" again, please fix this, test entry
127.0.0.2 is a MUST for rxwhois.cmd. And of course I won't
use a form where I'm forced to enter a phone number, weird
idea, either my evidence is good or it isn't. RFCI accepts
"munged" evidence (e.g. ##### for xyzzy). I've a script to
munge the evidence for RFCI, and I ask when my submissions
aren't accepted (shit happens).
[back to "redirected"]
it should have been <bob(_at_)almamater(_dot_)edu(_dot_)example>
Okay. I didn't read it again, how do you handle Original-XYZ
if XYZ has to be modified ? Simply Original-Original-XYZ ?
| C: MAIL FROM:<list(_at_)maillist(_dot_)org(_dot_)example>
| SUBMITTER=list(_at_)maillist(_dot_)org(_dot_)example
One of several reasons why I don't like the "Submitter" drafts,
and prefer solutions based on the traditional SMTP MAIL FROM.
Is your dislike based on that it duplicates SMTP MAIL FROM
too often?
Yes, one reason. But more important I'm paranoid, all these
"submitter" ideas try to nullify SPF, and I like RMX. I'm not
too worried about any "update all MTAs" scheme like "Submitter"
because I'm long dead before this ever happens in practice, but
the theory still worries me.
Meng's "local white list + HELO PASS" is IMHO more convincing
to bypass SPF MAIL FROM tests. Because as you said in another
thread, a central solution like trusted-forwarders.org is only
a temporary hack, and many forwarders refuse to consider SRS.
[Alice]
I was very unsure what reaction to this would be as IETF
Adding a Caveat: I can't really judge it, my DEnglish isn't
good enough to read the original, but still enough to refuse
any translation. Maybe I should try the "annotated Alice" ;-)
with an exception of occasional pigeons carrying ip packets
They publish an April 1st RfC almost every year, don't they ?
In the case of RfC 3865 they even do it on other occasions.
That's probably another reason why they closed MARID, RfC 3865
is the FUSSP (IETF style), no more spam after September 2004 -
only my poor ISPs somehow forgot to implement RfC 3865, sigh.
It would be a nice IAB joke, if they present RfC 3865 as their
contribution to the spam problem before the FTC. Mentioning
that they finally got rid of WHOIS, because that made hunting
spammers much too easy.
IANA considerations: Where's Original-Subject defined ?
You don't mention it as new for registration.
If I had to define all Original-* headers it would take me
another 3-4 pages. I decided not to do it right now
Oops, are they _all_ new ? I see Original-stuff everywhere,
therefore I thought that only Original-subject is really new,
I've no idea how to register a complete class of headers, but
I'm sure that the author of RfC 3864 will love the challenge,
just ask him. (JFTR, 3864 != 3865)
So the last idea of your draft is the new term "redirector"
instead of my clumsy "forwarding to 3rd parties". I like it,
but on spf.pobox.com you'd find the more common "remailer"
(at leaast it used to be there in the old spf.pobox layout).
Whatever the name is, "redirector" or "remailer", it's very
important that both RfC 2821 and crocker.mail-arch ignore the
underlying problem, "forwarding to 3rd parties" is as evil as
"open relays", and SPF + ( SRS / SES / SUBMITTER / etc.) fix
this blatant hole.
Bye, Frank