spf-discuss
[Top] [All Lists]

Re: Re: Redirected Trace header draft

2004-11-07 19:51:08
On Sat, 6 Nov 2004, Frank Ellermann wrote:

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.

This is "internal last call". The draft will be published as ID
within about a week and despite that I already started working
on version1 of the draft (which will no longer have New-* headers
and reuse Original-* for that) the version 00 to be publshed
will be primarily the same as current pre03.
 
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).

I've kept SUBMITTER in only one of 3 examples for Redirected draft,
which will hopefully make it clear that its independent concept. 

And next version of responsible-submitter will in fact have the example 
that use Redirected header and recomendation for forwarders to use it to 
record when value of SUBMITTER is changed. I'll also give you couple 
other  previews of next version of responsible-submitter (I'll show you 
latest "01pre" version in about 10-15 days after Redirected is published 
as ID). The other new things there are:

 1. Either reference to SRS draft (of which there is none...) or directly
    inclusion of SRS algorithm as part of draft as a way to carry SUBMITTER
    value to MTA that did not advertise SUBMITTER extension.
 2. Addition of "Submitted-By:" header now for use strictly as trace header
    for MDAs to record last value of SUBMITTER in exactly same way they
    currently use Return-Path: header to record last value of MAIL FROM
 3. Reuse of v=spf1 record (Microsoft has shown me bad example, so be
    ready to kill me as well) but I do believe this time the SUBMITTER
    with its reuse of SRS will basicly be the same as SPF. But I'm not
    Microsoft, I'll not force it on you and there will most likely be 
    some kind of modifier proposed for spf1 records.

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.

Received is so badly maintained/used I don't want to toach it at this time,
its also not designed to list "changes" and can only list current values 
at the time header is added and majority of values being added by means of 
Redirected header can not be expressed in Received right now except by
adding new class of clauses (this is what "from" "by" "with" are called I 
think) since Received system does not allow for carrying RCPT and MAIL 
additional parameters at all.

So yes - everything does point to that new header concept is better for
recording what happened during forwarding/redirection.

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").

Redirected header is a trace heder and does not care about changes done 
to email afterwards or know about it - it only records that happened to 
email when forwarding step occured and what values were then changed. It
is in fact "connected" to received headers as it also includes "by".

Of course Sender-ID "Resent-abuse headers" won't survive
broken mailers, but we all know that Sender-ID is FUBAR.
Being forced upon the world by one very irresponsible company, I
hope we  can spread the message about the stupid (evil?) giant that
does not care about damage it can cause on the land.

Ah, supporter of rfc-ignorant - good to hear.

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

From comments in the entire bogon list data file published at
http://www.completewhois.com/bogons/data/bogons-cidr-all.txt:
"# This file does not include the following additional iana reserved blocks:
 #   10.0.0.0 - 10.255.255.255     - reserved for intranet local networks
 #   127.0.0.0 - 127.255.255.255   - reserved for local loop on each computer
 #   172.16.0.0 - 172.31.255.255   - reserved for intranet local networks
 #   192.168.0.0 - 192.168.255.255 - reserved for intranet local networks
 #   224.0.0.0 - 239.255.255.255   - used for multicast routing
 # All these ip blocks are commonly used for local ethernet or local machine
 # and hence if you filter them you may accidently shut down your own network
 # Please manually add to your configuration those of the above blocks that
 # you know for certain are not used on your local network"

Removing "completewhois" again, please fix this, test entry
127.0.0.2 is a MUST for rxwhois.cmd. 

I've not heard that 127.0.0.2 is a requirement for dnsbl and we've ran 
bogons list for over a year now and its quite used and never had complaint 
about not including that ip. I'll check around with other people running 
rbldnsd and ask if they add this ip address for testing purposes and if 
most do, I'll do it as well just for dns version of our lists. 

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).

[Note: This is probably OT to SPF but I suspect there are enough people
 here who are interested in preventing ip abuse and identifying those who
 may cause it, so I'll answer here. But if this turns into discussion I
 would suggest SPAM-L or possible one of newsgroups like NANAE]

Completewhois is not a blacklist operator and we do not take submissions.
We do most of the list generations with automated process based on certain 
criterias of what is considered to be bad for whois (primarily to find
those who are purposely entering invalid information in whois or those
who are using blocks that do not belong to them so as to avoid being
identified for whatever activity they are engaged in). In some cases
automated process do not work 100% and so we do do accept reports from
users which can help in focusing our investigations and helping in 
refining automated scripts. If investigation results are that whois data 
is found to have a problem, we try to contact owner of ip block or contact 
upstream ISP and tell them about the problem. If they fix it or tell us 
they are working on it with date of what it would be fixed, the the 
result has been achieved, but if they do not respond we'll list block 
as to show results of our investigation and to let others know about 
existance of the problem and that it was not possible to get anybody to 
correct it. 

As for reports we do not require real user name or email although I 
personally do not like reports that are anonymous, it makes it hard to 
contact person back and let them know results of investigation (i.e.
if for example we were able to reach correct responsible person for the
ip block in question, we'd let them know so they could report whatever
the problem was with the block) and it also makes me question the
reasons for reporting the data or any data that has been included.

 [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 ?

Original-* are trace header so they are not supposed to be modified
but new headers with same name can be added by subsequent systems
(and new Original headers are supposed to be added to the top
like with Received and with all other trace headers).
 
|   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.  

In next version of SUBMITTER I'll not longer require it to be used
as parameter to MAIL if it is the same as MAIL FROM.

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.

My opinion about it now is that they should either do SUBMITTER or
do SRS with SRS being kind of like SUBMITTER when subsequent system
did not advertise SUBMITTER capability or sending system could not
support it.

I question using HELO on by itself for whitelisting - in that case we 
might as well just do only HELO authentication like Dougals Otis suggests.
My opinion is that we do need HELO authentication and it should be done no 
matter what MAIL FROM is and is independent necessary part of security 
SMTP session but that it does not replace MAIL FROM authentication part
of SMTP session security.

 [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.

Yes and I don't want to publish ID that will be compared to one 
published on April 1st :)
 
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 only works if both recepient and sender comply with it, I've slightly
hard time imagining all senders wanting to comply with this RFC...
 
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.

There I disagree with them. IETF is about protocol design not about
policy implementation - so policy on WHOIS belongs with ICANN
and protocol for WHOIS with IETF (CRISP WG particularly).

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 ? 
There are actually occasionally used but without definition by any IETF 
document except for one case:
 Original-Envelope-ID      - This is defined in RFC1894 and RFC3464
 Original-Encoded-Information-Types
 Original-Recipient
 Original-Content-Type
 X-Orig-Message-ID
 X-Original-Envelope-From 
 X-Original-NNTP-Posting-Host
 X-Original-Trace 
 X-OriginalArrivalTime  

Its mostly by obscure MUA and less often used MTAs right now that add
these headers but there does seem to be need for it (independent from 
Redirected header) so some standartization of this seems in order and
I'll try to work on  this in separate document that will define use of 
Original-* headers.

I see Original-stuff everywhere,
therefore I thought that only Original-subject is really new,

If you saw Original-something that was not in the list above (which I 
primarily had to create myself and I'll note that the Oiriginal-* that is 
defined by RFC is exactly the one from the list I've never seen in any 
email :) then please let me know.

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)

I've feeling this is where I'm heading as soon as the draft starts
to be discussed at ietf-822 (which is unfortunetly composed primarily 
of people who just love attacking any new ideas that seem to want to add 
to their precious SMTP which they seem to want to keep static forever).

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).

Redirection has more of "automated" feeling to it while remailing
can be seen as being same as forwarding (i.e. I remailed this to
you just now).

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.

I hate to be the one fighting DCrocker & Co (as I have much respect
for his previous work) and will try to avoid it although judging from 
ietf-mailsig mail list it will not be possible. But hopefully this will 
not be immeditly killed by them as its just a trace header and does not 
change any behavior just helps document it.

---
William Leibzon, Elan Networks:
 mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/


<Prev in Thread] Current Thread [Next in Thread>