Barry Margolin wrote:
a <user>@alum.mit.edu address that forwards to their real
email service.
Okay, so I send MAIL FROM:<me(_at_)xyzzy> RCPT TO:<you(_at_)alum(_dot_)mit>
to the MX of alum.mit. This beast then "forwards" it to your
real address you(_at_)research(_dot_)example or whatever.
If it forwards my mail using the original MAIL FROM:<me(_at_)xyzzy>
this won't pass a SPF check, you should never get this forged
mail. In theory research.example could whitelist alum.mit as
"trustworthy" mail forger^H^H^Hwarder for you.
A better solution would be if alum.mit really forwards my mail
using its own MAIL FROM:<see(_dot_)below(_at_)alum(_dot_)mit> including my mail
as standard MIME message/rfc822.
Or it acts as "remailer" using its own MAIL FROM:<see.below@>
copying my mail incl. 2822 header "as is". That's explained on
<http://spf.pobox.com>, and there are schemes to encode the
local part "see.below" in a way allowing to identify the old
MAIL FROM:<me(_at_)xyzzy>
If me(_at_)xyzzy is a spammer, or if you(_at_)research(_dot_)example bounces,
the admin see(_dot_)below(_at_)alum(_dot_)mit can analyze and handle this.
However, they don't provide a mail submission service -- you
still have to send your mail out through whatever SMTP
server you would normally use.
Then they probably won't publish a sender policy, because it's
useless to have a "v=spf1 +all" or "v=spf1 ?all". OTOH they
have to handle the case where you(_at_)research(_dot_)example bounces -
in that case they would decode the local part "see.below", and
then forward the bounce to me(_at_)xyzzy using MAIL FROM:<> (empty
return address).
For MAIL FROM:<> my ISP (= MX for xyyzy) could SPF-check their
HELO alum.mit, and so they could publish a sender policy for
this case: "v=spf1 a ?all" if a:alum.mit is the IP of their
MTA. The ?all is for you using the mailer of research.example
with an utter dubious MAIL FROM:<you(_at_)alum(_dot_)mit>
There's no way for MIT to list all the possible mail servers
There is: ?all
they'll have to leave the domain unprotected, which means
that spammers are free to forge alum.mit.edu addresses.
Yes. Almost the same situation as without SPF for them. But
their ?all is only for you, if you are forced to lie in your
MAIL FROM (ab)using the research.example mailer.
There are several ways to avoid this problem. First of all
research.example could fix your MAIL FROM inserting your real
address MAIL FROM:<you(_at_)research(_dot_)example>
In theory your MUA could do this for you.
AFAICT, my MUA (Mac OS X 10.3.5 Mail) doesn't provide any
way to specify the envelope sender; it has one place to
specify the Email Address for a mail account, and it uses
this as both the envelope sender and the From: address.
"Officially" my stoneage Netscape 3.x also doesn't support to
specify the MAIL FROM. But that's not exactly true, I have
several "profiles" (= mail accounts), and I can create mail
without sending it immediately.
Therefore I can create a mail with my xyzzy-"profile", this
results in a 2822 From: me(_at_)xyzzy in my "outbox". Then I can
start another instance of Netscape with another profile using
the same file "outbox". In the second Netscape instance I'd
then use MAIL FROM:<me(_at_)2nd(_dot_)msa> still with the From: me(_at_)xyzzy
created before.
It's not very elegant, several copies of the same program with
the same file require some "manual" synchronization by me, or
in other words I can't POP both accounts simultaneousy, and
it's also tricky to do somethig with the 2nd account while the
1st instance POPs spam.
It also won't work with PRA and Sender-Id, because there's no
Sender:<me(_at_)2nd(_dot_)msa> in the MAIL FROM:<me(_at_)2nd(_dot_)msa> with my
old
2822 From: me(_at_)xyzzy
But it's good enough for classic SPF and existing MSAs.
I apologize if this has been discussed before.
Yes, but not often enough. Otherwise the fans of Sender-Id
and PRA would fix their scheme for compatibility with the real
world in the next decade.
Bye, Frank