spf-discuss
[Top] [All Lists]

RE: The pretty name

2004-09-30 14:22:23
[Mark]
I cannot believe you would even suggest this with a straight face.

Well, my face is mostly straight. I have been with the list and SPF for
around a year. Also in the MARID group. But I have never seen anyone
suggest something like this, even though it was the first thing that
popped into my head when I started thinking about email authentication a
few years ago. It seemed so stupidly simple I figured it wouldn't be
practical, and never brought it up, but I never saw anything in any
archives or on any list that really gunned it down in my head.

First notions about how to tackle a problem are usually bad ones, I'll
admit, but I don't see how header rewriting is any worse than some of
the cumbersome schemes I've seen bandied about. All of them require
compromises. I know modifying certain headers is considered bad form,
and it will of course cause problems with more esoteric mail situations
(like lists). But SPFv1 requires the hack-ish SRS to get around the
forwarding problem, and yet it seems to have been accepted fairly well.
 
Mixing layers is almost always a very bad idea; this being no 
exception. 

How will we ever validate 2822.from without checking it at SMTP time,
knowing what IP it came from? Or do you propose relying on a crypto
solution like DomainKeys for 2822 authentication (which wouldn't need IP
information)?

Do
you really want a few examples? The ol' mailing list, again. 
Do you really
think I am subscribed to this list with my, almost constantly 
differing, SRS
address? And how will the mailing list software recognize me? 
It could not;
unless it happened to catch my email at the SMTP dialogue 
layer (which is 
rather unlikely; far more likely is that that it will be 
delivered to some 
LDA, or alias-expanded script, which handles the mailing 
list; read: at an 
entirely different layer).

I already mentioned mailing lists and other forwarders as an issue.
Mailing lists (and forwarders) will still work for the most part. They
just won't show the 2822.from of the original sender. Maybe we can fix
that by adjusting the pretty name as I mentioned earlier, or by some
other scheme. As I mentioned, I would be willing to deal with the
inconveniences involving mailing lists and forwarded messages if it
protected my users from 2822.from forgery.

Anyway, with the current situation, I can easily forge messages to the
list that appear to be from you, because 2822.from is unauthenticated. I
can use my own SPF-compliant 2821.from. Plus, mailing lists could choose
not to do the 2822.From rewriting, leaving themselves open to 2822.from
forgery as they are today.

I really think of this idea as an edge-MTA stop-gap solution for an
organization that wants to protect itself from 2822.from forgery until
Unified-SPF or something better is deployed. Heck, it could be done on a
per-recipient basis, only for those users who require the extra
protection (and probably don't use mailing lists or understand
forwarders anyway).

What do you mean, "intact"? You make it sound like it is always there.
Basically, you would then also have to rewrite/add the 
Reply-To: header to
the original pretty 2822 From: address. But that is not for 
you to set;
because the sender has typically added a Reply-To: for 
*precisely* this
reason: to have a reply go elsewhere, instead of to the 2822 
From: address
(where replies would normally go).

I agree there will have to be some logic with how the Reply-To header is
handled: leave it alone if it already exists, don't add it if 2821.from
and 2822.from match, add it with the old contents of the 2822.from
header if it doesn't exist and we had to rewrite the 2822.from header,
etc.

I'd really like to hear if anybody can come up with something *besides*
mailing lists/forwarders the 2822.from rewriting scheme would really
break. I can't think of anything else, which is why I am here asking
questions.

Please, gun this idea down! I'd rather not waste any more time thinking
about it if it really is totally unworkable.

Regards,
        -Ryan-


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