On Wed, 3 Nov 2004, Frank Ellermann wrote:
william(at)elan.net wrote:
http://www.elan.net/~william/emailsecurity/draft-leibzon-emailredirection-traceheaders-00pre02.txt
Ignoring minor stuff like typos:
I did find about dozen and corrected them yesterday. But I've serious
problems because of how using quick-reading techniques affected me and
now I make lot more typos and have harder time finding them myself.
So don't "ignore" what you found, send them to me privately.
That draft is apparently a
consequence of the "Submitter" drafts. You capture the 2821
effects of the "Submitter" in a new 2822 header "Redirected".
While I mention Submitter in the draft often, it is not a "consequence".
The draft is intended to capture ALL changes done to SMTP parameters
during email forwarding/redirection process (and I used Submitter as
example because I partially based examples on the ones from
responsible-submitter draft).
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 and leave it only with existing parameters already
described by RFCs. Please send your comments on if think this is better.
For traditional SMTP without "Submitter" that's unnecessary,
because the "for" clause in the time stamp line could trace
the RCPT TO. Unfortunately that's not always the case for
privacy reasons, and when I send an abuse report to unknown
3rd parties (i.e. both abuse@ and postmaster@) I sometimes
get a bounce "root(_at_)somewhere over quota" without hint, which
address failed, either abuse@ or postmaster(_at_)(_dot_)
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.
In that case I have to test both addresses separately to get
the necessary evidence for rfc-ignorant.org. But in theory
"for" could be good enough for traditional SMTP (incl. SRS).
Ah, supporter of rfc-ignorant - good to hear. Just a reminder if you
were reporting ipwhois problems, these now should go to me, see
http://groups.google.com/groups?hl=en&lr=&c2coff=1&selm=3e2c7220.0410280944.37fa6319%40posting.google.com
http://www.completewhois.com/invalidwhois/invalid_ipblocks.htm
BTW, did you read the new "Sendmail message tracking" RfCs ?
I did not, that's why I ask, maybe it's related to your memo.
That is former MSGTRK working group. I've commented multiple times about it
on ASRG and did consider writing "reverse" message tracking draft (see last
two slides of
http://www.elan.net/~william/emailsecurity/asrg-emailpathverification-presentation.pdf)
based on that as well (so recepient could check if previous servers in the
path handled te message). The problem with message tracking is necessity
for each server to keep track of all messages that pass through by means
of new "message tracking" service and that is hard requirement for large
ISPs and overall it seems better to do this by means of cryptographic
signatures where instead of keeping track of each email its enough for
sender to just publish public key or provide key verification service.
On page 10 (alamater to company) you write:
| SUBMITTER=bob(_at_)company(_dot_)com(_dot_)example
Why not SUBMITTER=bob(_at_)almamater(_dot_)edu(_dot_)example ? As shown in
the
time stamp line: Received ... for <bob(_at_)almamater(_dot_)edu(_dot_)example
You're correct it should have been <bob(_at_)almamater(_dot_)edu(_dot_)example>
and besides that the message there was being transmitted from
"mail.almamater.edu.example" and not from "maillist.org.example".
Will fix.
Original-Sender (etc.) for mailing lists is nice, that's what I
tested with GMaNe and a "Test for Seth" Sender here. And Lars
fixed it, GMaNe now preserves an original Sender somehow... ;-)
| 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?
But I do like the "Alice in Woderland" parts of your draft :-)
Good to know. I was very unsure what reaction to this would be as IETF
(with an exception of occasional pigeons carrying ip packets) is usually
a lot more serious and putting something like this even in example could
cause people to not take the draft itself seriously.
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 and ask around if it can be
done all together by defining standard "Original-" prefix and having
it reseved for this kind of information as reference to old value
of the header. I suppose to do it, separate draft will have to be
published and IANA registry modified in some way to account for
standard prefixes.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net