From: Frank Ellermann
Sent: Friday, October 22, 2004 12:49 AM
Seth Goodman wrote:
Nothing in SPF forces a recipient to reject anything.
Sure, but you were talking about 2822 tests at the border MTA,
and I wanted to stress that there can be valid reasons to never
ever look "into" received mail. Except from finding the end
of DATA and inserting a time stamp line before it. And the
Return-Path if it's an MDA.
No MTA ever has to look inside the body (including headers), unless they
care about 2822 forgery. If the sender says they enforce 2821=2822, the
recipient at least has the choice to do that and reject on failures of the
senders published policy. These failures are either forgeries or the sender
has published an inappropriate policy for their site. It's just like
"-all". Don't publish it unless you mean it.
I don't think I understand what the case is for "never" looking inside the
envelope. Even mail that is otherwise accepted, it is still going through
SpamAssassin or a Bayesian filter. In fact if someone is offering me a
message, why should I exclude myself from scrutinizing anything in that
message before deciding to accept it? Presumably, the sender wants the end
recipient to read the body, but somehow wants to prevent he MTA from reading
the body? I'm obviously misunderstanding something.
My comment is that most people _can_ set them to both be
the same, though they may not like the address they are
restricted to.
Okay, that's clear. In my case it's not that I don't like my
other address, it's only that I prefer my usual From: nobody@,
because every spammer in the world has it already. And of
course I don't like to add an "eh"-Sender manually by such
sophisticated procedures as "edit file outbox" ;-)
Your case is the reason that this cannot be a requirement, but has to be
specified by the domain owner. If there are cases that a local provider
requires such equivalence, you don't like it and they block port 25, you
would have to contract for a separate mail service that you access over port
587. Unfortunately for people who want to set up their outgoing mail as you
do, the world is moving in the direction of requiring the at least the 2821
and 2822 domains to be the same. Eventually, it may get more strict.
The current DK proposal signs only the 2822 sender and ignores the 2821
identity. The fact is that these identities are intrinsically tied together
since the a message must be submitted by a single party and the two
addresses are placed in the message by a single MSA. One submitter, one
MSA, so how do we justify two different identities? I know the RFC's
currently permit this, but those RFC's were written at a time before the
current epidemic of forgery and phishing.
Various people have proposed schemes where every header has a cryptographic
signature. This is an enormous burden on the recipient and is drastic
overkill for the majority of cases. It also creates a situation that is
hard to deal with when some, but not all, signatures check out. Though the
RFC's clearly allow a disconnect between the 2821 and 2822 identities, there
are a number of statements that indicate that the addresses must be working
and at least in the case of 2821, that the address is appropriate for
handling delivery problems for the given message. This implies to me that
is SHOULD be the sender. That doesn't ay we have to enforce it, but it also
doesn't say that we _can't_ enforce it, especially if the sender agrees.
I think we should discuss further the fact that the message is, in fact,
always submitted by a single party to a single MSA, and what are the real
benefits of continuing to allow the two addresses to be from different
domains? This is analogous to insisting that you want to make phone calls
but have the name and number appearing at the caller-ID display on the other
end be something unrelated to your name and phone number. That would
completely break the utility of telephone caller-ID and is not accepted.
Your particular use case is not malicious, but the great majority of cases
where there the two addresses do not correspond are malicious. Let's
explore this further, please.
<...>
If nothing else, it should be worth a couple of points in
SpamAssassin.
Maybe. Actually I don't see why SA should be impressed by the
presence of a redundant Sender: header only to get William's
"equivalent header". It's not directly related to spam, it's
anti-phishing to a certain degree, depending on the MUA and
the user. Most of the time I use "view all headers" and see
the Return-Path, an equivalent Sender won't help me then.
I was unclear here. What I meant to say was the fact that the sender
asserted 2821=2822 equivalence and the message passed that test. This would
have to be communicated in the SPF header, where the recipient gets some
idea of what level of validation the message received through SPF.
Anyone who can enforce submission rights for their domain
would want to do this to hinder 2822 joe-jobs.
Yes, domain owners can arrange it. Not all users are domain
owners. Otherwise I'd simply add the MSA in question to my
sender policy. And the IP of SYMPA. And the IP used by my
news server for submissions to moderated groups. After these
three steps even Sender-Id would work with my v=spf1 policy ;-)
Pobox.com users have per user policies, that's as good as a
real domain for SPF. So maybe Meng sees another good reason
to support William's idea.
I don't think it's fair to criticize Meng for that. Most ISP's don't
provide a service where submission rights are enforced. Providing that, in
whatever form, is simply a response to a need that results from the huge
inertia at ISP's. It has little to do with William's suggestion. It is
simply an email service that behaves as all responsible email services ought
to behave, but haven't realized that yet. The fact that Meng is one of the
first to realize that and fill the gap is to his credit. I'm sure this is a
very tiny piece of their revenue and he would be just as happy if all ISP's
did the right thing and made this service unnecessary. With relatively few
people knowledgeable enough to request such a service, I wouldn't be
surprised if they don't earn a profit from it.
--
Seth Goodman