Subject: Re: [ietf-dkim] from'less 2822 messages

From: Damon <[email-masked]>
Date: Thu, 24 Jan 2008 20:05:15 -0500

On Jan 24, 2008 8:02 PM, Michael Thomas <[email-masked]> wrote:
>
> I don't think this is handled in the current spec, but it's certainly
> possible to get delivered an otherwise valid 2822 message that doesn't
> have a From: address (or a null header field). What should an
> implementation do in this case?
>
>                Mike
> _______________________________________________

Such as a bounce?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jan 2008 17:02:14 -0800

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Jan 2008 17:20:32 -0800

> Such as a bounce?

I thought that a bounce was a MAIL FROM: <> ? I don't recall seeing a
null 822 From:, but I could easily be wrong.

		Mike

---

From: John Levine <[email-masked]>
Date: 25 Jan 2008 02:55:00 -0000

>implementation do in this case?

It's not a valid RFC 2822 message, so I think it'd be fair to declare it
out of scope.  And in any event, if there's no From: line, the chances
of author forgery would seem to be, ah, limited.

R's,
John

---

From: SM <[email-masked]>
Date: Thu, 24 Jan 2008 19:44:38 -0800

At 17:02 24-01-2008, Michael Thomas wrote:
>I don't think this is handled in the current spec, but it's 
>certainly possible to get delivered an otherwise valid 2822 message 
>that doesn't

The From: field is not optional (2822).  If there isn't an author 
address, there isn't a domain on which the implementation can do a SSP lookup.

Regards,
-sm

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 09:39:27 +0100

> I thought that a bounce was a MAIL FROM: <> ?

Yes, of course this could be also another auto-reply.

> I don't recall seeing a null 822 From:

That would be a clear syntax error, and I think one
technical reason why DKIM uses "From" is that it's
guaranteed to exist.  Like "Date", all other fields
are optional (or can be one or more of To/Cc/Bcc).

Missing or empty 2822-From is for SSP what missing
or domain literal HELO is for SPF, receivers can't
use it.  They are free to reject it as syntax error,
or to reject a "valid" From: user@[127.0.0.1] as too
weird for their tastes.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Jan 2008 04:23:43 -0800

> or to reject a "valid" From: user@[127.0.0.1] as too

I'm aware that this is not legal, but these sort of things
happen in the real world, and are the kind of things that
cause interoperability and/or deployment issues. Since SSP
is a security protocol, we can pretty much be guaranteed that
somebody will eventually start probing the edge cases, so
to the degree that we can provide guidance is to the better,
IMO.

In this particular case, the interoperability issue is that
some implementations might label this as "suspicious", others
not. I don't think we want that variability.

		Mike

		Mike

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 25 Jan 2008 16:00:22 +0100

> to the degree that we can provide guidance is to the better,

Some early SPF drafts tried to "ban" domain literals together
with weirder constructs.  But that is a "receiver policy",
and HELO [1.2.3.4] from IPv4 1.2.3.4, or similar MAIL FROM:
<postmaster@[1.2.3.4]>, might be perfectly valid.

As far as a "sender policy" is concerned, IPv4 1.2.3.4 can't
have an SPF (or TXT) record, and therefore it's pointless to
talk about it in RFC 4408.

If you want a note stating that cases where it is impossible
to find an SSP are always "suspicious", what does that mean
for say a From: postmaster@[1.2.3.4] ?  IMO that is no job
for SSP, IPs simply cannot have a "sender signing practice".

There are numerous ways to create syntactically broken From
header fields, and if receivers bother to reject an SSP FAIL,
but accept syntactically invalid constructs, they are in need
of medication, not of convoluted prose in the specification.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Jan 2008 08:09:57 -0800

> of medication, not of convoluted prose in the specification.

Frank, you're (inadvertently?) bringing up exactly the kind of
corner cases that I was trying to raise so that SSP implementations
have the same behavior in their presence. It may be that all we
practically need to do is refer to 2822 and say that if the From:
field is missing, or if the header field body is missing, or if
the domain part of the address spec is missing or not a datom(??),
then the algorithm terminates and returns, oh say, "malformed" or
something like that.

		Mike

---

From: John Levine <[email-masked]>
Date: 25 Jan 2008 22:14:19 -0000

>then the algorithm terminates and returns, oh say, "malformed" or

Well, gee.  What if there are two From: lines?  Three From: lines?  A
From: line with two addresses but no Sender:?  A From: line with two
addresses, one of which has no @ sign?  A From: line with a couple of
embedded carriage returns?  The number of ways one can construct a
string of bytes that is not a 2822 message is limitless, and it's hard
to see any beneft in trying to enumerate them.  If it's not a 2822
message, SSP doesn't apply.

When I pointed out that the "first from" rule enabled a trivial end
run around SSP, by using a real first address and a forged second
address that is likely to be visible in MUAs, I naively assumed that
it would be obvious to everyone that any rule other than checking all
the addresses would have the same hole, hence the fix is to check all
the From: addresses, and then move on to something else.

But no, we got endless nattering instead.  This is not a subtle point,
and I share Steve Atkins' concern that a group of people who don't
understand the way that e-mail works can't design a working protocol.

R's,
John

---

From: Damon <[email-masked]>
Date: Fri, 25 Jan 2008 18:05:35 -0500

> the From: addresses, and then move on to something else.

I for one understood the assumption you made. Misunderstanding was not
this issue in my mind. The issue is what to do about evil do'ers that
would certainly take advantage of this "MUST" - It concerns me.

> understand the way that e-mail works can't design a working protocol.

What?

Regards,
Damon Sauer

---

From: Hector Santos <[email-masked]>
Date: Fri, 25 Jan 2008 18:25:01 -0500

John Levine wrote:

> addresses, one of which has no @ sign? 

And if you quickly skip down to South Beach, you will find Fidel Castro 
sun-bathing smoking a Cohiba, thumbing his nose at all the exiles and if 
you listen carefully, you can hear him whisper "What does this have to 
do with the price of rice in china?"

> But no, we got endless nattering instead.  This is not a subtle point,

What exactly is your point? The possibility of garbage in mail?

> understand the way that e-mail works can't design a working protocol.

Yes John, we all understand you have a copyright on understanding email 
technology.  Is this the reason you have no need to put your VBR system 
through any IETF Working Group vetting process?    Such WG vetting are 
not required because you understand email better than the rest of us?

Out of curiosity,  how is your VBR secured from not only all the garbage 
you say can occur in email, but also has multiple VBR-INFO: headers?

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Jan 2008 15:55:19 -0800

> message, SSP doesn't apply.

John, do you write code? The current draft is completely silent on this
issue. It doesn't even say "SSP doesn't apply". Exception conditions
are the classic places that different implementations do different things,
including treating them as "suspicious" in the current draft's parlance
which is almost certainly completely wrong. Nor do we have to fall
prey to the strawman that we'd have to enumerate an infinite list.

> But no, [self-important hectoring elided]
>
>   
> 	Mike
>

---

From: John L <[email-masked]>
Date: Sat, 26 Jan 2008 00:13:52 -0500 (EST)

> John, do you write code?

Quite a lot of it, actually.  Watch out or I'll tell you about the
Fortran 77 compiler and runtime library I wrote, and in particular all the 
kludges you need to parse Fortran properly.

> The current draft is completely silent on this issue.

Standards track RFCs are consistently silent about what you do with stuff 
that's outside the spec.  For example, look at RFCs 2045 through 2049 
which describe MIME mail.  They say a lot about what MIME conformant mail 
is, but the only thing they say about broken MIME is don't do that.  In 
2049 there's quite a bit about how to code defensively to avoid having 
stuff broken by common buggy mail systems, not what to do with stuff that 
shows up broken.

It wouldn't be harmful to say "This only applies to 822 or 2822 
conformatnt messages", but it would be redundant.

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 26 Jan 2008 11:19:05 +0100

> conformatnt messages", but it would be redundant.

Maybe there's a compromise, proposed SSP security consideration:

"Treating [SSP FAIL] more harshly than syntactically invalid
 messages not allowing to apply SSP could turn out to be a
 very stupid strategy."

Replace "SSP FAIL" by the corresponding weasel words of the week.

 Frank

---

From: <[email-masked]>
Date: Sat, 26 Jan 2008 21:26:19 -0500

I have been accused of writing code from time to time.
SSP is a policy/practice statement. Coding this is a two step process
get the value of SSP via a DNS lookup (the easy part)
the writers of software will then integrate this result into their current software offering which will have rather wide latitude on what to do with the results, some more effectively than others. We don't want to break current best practices or open new attack vectors unless there is a compelling case to do so. Legacy systems dont/wont care about DKIM/SSP. Certain vendors dont want to have to spend a ton of cash to update their DNS products that have trouble handling new ideas because that is not a profitable company line item. So John's comments are applicable. As well as Hector's "technical" points.
thanks,
Bill

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 28 Jan 2008 11:54:31 -0000

> message, SSP doesn't apply.

I think all you need, as Frank has pointed out, is a security
consideration to the effect that

"Verifiers should be aware that Bad Guys may attempt to subvert the
intentions of SSP by submitting messages that are non-compliant with RFC
2822 (for example by using empty From headers, mutiple From headers, Etc
{i.e. list a few examples, but not too may }).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 28 Jan 2008 08:50:28 -0800

>{i.e. list a few examples, but not too may }).

That seems like a good resolution to this long thread.

--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Tony Finch <[email-masked]>
Date: Mon, 28 Jan 2008 17:06:57 +0000

> talk about it in RFC 4408.

Put them under in-addr.arpa next to the PTR record.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN: SOUTHWEST 6 TO GALE 8 VEERING NORTHWEST 5 TO 7. VERY ROUGH,
OCCASIONALLY HIGH AT FIRST. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Mon, 28 Jan 2008 09:07:12 -0800

>> {i.e. list a few examples, but not too may }).

Unfortuntately, good guys (fsvo "good") do this to. I think we need to
add to this by saying that they should be considered SSP unknown, but
not suspicious or whatever the new phrase that replaces suspicious is.

		MIke

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 28 Jan 2008 18:20:17 +0100

> Put them under in-addr.arpa next to the PTR record.

The RIRs asked MARID to stay away from such ideas, and for the
purposes of RFC 4408, which boils down to a rather convoluted
way to classify IPs as "verboten" or permitted, it was anyway
irrelevant.  

For SSP I also don't see it yet, and with its attitude towards
RFC 2822 SSP can as well judge domain literals as "suspicious",
and I can contribute my favourite RFC 822 quote for this stunt:

| Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
|        is  permitted  only  as  a means of bypassing temporary
|        system limitations, such as name tables which  are  not
|        complete.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2008 12:36:39 -0500

> That seems like a good resolution to this long thread.

+1, non-compliant messages are immediately rejected.  It has nothing to 
do with SSP or DKIM or anything else.

The first rule of thumb is protocol compliance.  DKIM can not be based 
on allowing subjective *external* reputation concepts to trump or allow 
faulty messages to pass *any* standard compliance test.

-- 
Sincerely

Hector Santos, CTO

---

From: [email-masked]
Date: Mon, 28 Jan 2008 09:32:30 -0800 (PST)

> not suspicious or whatever the new phrase that replaces suspicious is.

I agree that the quoted text is a bit too focused on Bad Guys and makes it
sound like any incompliance is likely the result of Bad Behavior when in fact
ignorance - still the most powerful force out there - is a far more likely
cause.

But beyond that, I have to say I'm a bit confounded by the concern for invalid
messages shown here. There are a gazillion ways for messages to be invalid and
attempting to account for them all in our specifications is a practical
impossibility. And yet many members of this group seem to have no problem
blithely ignoring various legitimate protocol features. I find this dichotomy
to be more than a little perflexing.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2008 13:30:00 -0500

[email-masked] wrote:

> But beyond that, I have to say I'm a bit confounded by the concern for 
> invalid messages shown here. There are a gazillion ways for messages 
 > to be invalid and attempting to account for them all in our
 > specifications is a practical impossibility. And yet many members
 > of this group seem to have no problem blithely ignoring various
 > legitimate protocol features. I find this dichotomy to be more
 > than a little perflexing.

+1.

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Mon, 28 Jan 2008 13:49:34 -0500

>  > than a little perflexing.

+1,000,000
I am VERY sorry if I had anything to do with this thread going as long
as it did.
My reply to the first message was just to clear up my confusion.

Regards,
Damon

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 28 Jan 2008 20:17:44 +0100

A few days ago you said that more than one From address 
is irrelevant, and that "resending" old unsigned mails 
is as irrelevant as the whole concept of "resend", for
your stated POV a "+1" to Ned's concerns is rather odd.

 Frank

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2008 15:33:52 -0500

> your stated POV a "+1" to Ned's concerns is rather odd.

I said no such thing.

As a 25+ year veteran of the telecommunications, online hosting and 
electronic mail system and product design and commercial product 
manufacturer, it is ridiculous to suggest that none of this will work 
because there is the obvious potential of bad people sending 
non-compliant data.

 From the get-go, I thought the idea of trying to address all possible 
blatant malicious abuse of mail is ridiculous - see my "Price of Rice" 
message.   And your particular input in regards to resending mail as 
"me" is no different.  As long as you don't alter the originality, I 
don't see that as a problem.  If you intend to break it, then you have 
to be able to taken into account the "new considerations."  In my book, 
this would be a "Feature" to stop you from resending my mail in an 
altered state.

Now, I also said in more ways than one, provided we have a x822 
compliant message, there is no flaw in the concept of SSP looking up 
multiple From: co-author domains. I even provided some technical 
automating ideas to work with it.  I see that as a "no-brainer" and I 
think most programmers/developers will agree with me.

But I also indicated this is typically an issue or question of overhead 
and redundancy and we all know this can be controlled in the same way 
other technology or protocols has placed practical limitations in 
general in many aspects of the protocol; line limits, spaces or no 
spaces, etc, including DNS clients with its limits and more SPF with its 
recursive limits which is the closest facsimile for this concern.

All and all, this all is really about implementation and completely 
unrelated to the basic fundamental SSP protocol.  But I am one that 
believes that implementation guidelines and insights should be part of 
the functional and technical specification whichever you wish to call an 
RFC.

So sure, I am happy we have respective people like Ned finally around to 
provide input which I sincerely hope helps bring back some practical 
sanity in all this.

-- 
Sincerely

Hector Santos, CTO

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 28 Jan 2008 22:39:23 +0100

Hector Santos wrote:

>> is irrelevant
[...]
> I said no such thing.

What I had in mind was
<http://permalink.gmane.org/gmane.ietf.dkim/9276>

| The fact is, in most x822/non-x822 gateway systems, it is
| incompatible as MOST online electronic mail systems has
| only a 1 single author concept.  Anyone who say there were
| wrong for PRE-EXISTING as such for many years is not 
| correct.

Looking again it it is quite possible that I simply didn't
get what you were trying to say.  
 
 Frank

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2008 17:25:20 -0500

> get what you were trying to say.  

The fact that there are systems, you might wish to label them as legacy 
systems, but I will venture they are still active and currently 
supported systems, that don't expect to deal or work or make sure it is 
consistent with a multiple From: address concept.

To presume that this is a supported concept across the board from MTA, 
to MUAs, across multiple mail networks, etc, etc, is simply not the reality.

For a quick example, right now, using the Thunderbird MUA, it does not 
allow me to create a multiple from reply or new message.

 From a presentation standard, the TBird MUA presents only the 1st address.

I have not checked the Outlook MUA, but it will present all the From: 
lines as one.

But overall, I will not be surprise to see incompatibility because 
historically, in the annals of electronic mail systems, not just x822, 
it is an odd-ball consideration.  It is a special case for mail writing 
software to support this concept.

You can not expect this to survive across the board.

For our hosting system, which supports both x822 and raw proprietary 
transformation formats,  maybe operations use the transformation as a 
legacy interface and as well as security filter (no HTMLs).  I can tell 
you multiple From: addresses will not survive.

For legacy networking concepts, which we still have many customers 
using, QWK systems do not support it and FIDONET systems do not support 
it.  So the concept is a non-priority for these customers.

All our presentation devices, Online HTML, Off-loaded GUI, Online 
Console Text, etc, do not expect Multiple From: lines.

Are we alone?  I doubt it.

Now, at the SMTP level,  it would be something we need to take account 
for DKIM/SSP for verification purposes.  But thats it.   Users who are 
concern will 100% RFC x822/MIME support, will turn on their "Preserve 
Mime" user option and our system will store the message as it, no 
transformation.    So its not a big deal, and I doubt the multiple From: 
   potential will ever be a big deal to anyone because are extremely 
high, this will reflect malicious mail more so than legitimate mail, and 
if its legitimate then it will be correctly DKIM signed.

-- 
Sincerely

Hector Santos, CTO

---

From: Hector Santos <[email-masked]>
Date: Mon, 28 Jan 2008 17:48:45 -0500

> I have not checked the Outlook MUA, but it will present all the From: 

As a follow up, I did a quick test and the Outlook Express MUA will not 
allow you to create Multiple From: authorships,  but it will present 
(display) received mail with Multiple From: lines as one From: header line.

I have not checked the non-free commercial Outlook MUA version but I do 
know it will do more then the Outlook Express which is available on 
every Windows machine.  So maybe the commercial version will give you a 
Manual Editable or Multi-Select From: field as a "Feature."

I can tell ya that from an Online standpoint, this will be a MAJOR 
security concern to allow any online user (login authorized and 
especially anonymous) to edit their default From address or add addition 
ones when creating or replying to mail.

So I will never add this unless it was a secured concept for our mail 
readers/creation software.

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Mon, 28 Jan 2008 18:50:43 -0500

> Manual Editable or Multi-Select From: field as a "Feature."

Lotus Notes is the same way.

Regards,
Damon