--On Mittwoch, August 18, 2004 13:48:13 -0400 "Stuart D. Gathman"
<stuart(_at_)bmsi(_dot_)com> wrote:
On Wed, 18 Aug 2004, Ralf Doeblitz wrote:
--On Dienstag, August 17, 2004 08:50:19 -0400 Anthony DePinto
<anthony(_at_)idmi(_dot_)net> wrote:
> With the .name domains, all you can purchase/control is
> firstname(_at_)firstname(_dot_)lastname(_dot_)name(_dot_) The e-mail forward
for
> firstname(_at_)lastname(_dot_)name is controlled by the registrar itself so it
> doesn't touch our servers at first. If I send an e-mail from
> anthony(_at_)idmi(_dot_)net, which is my address and we run SPF, to
> firstname(_at_)lastname(_dot_)name it first goes to the registrar's mail
server
> which forwards it AS anthony(_at_)idmi(_dot_)net to
> firstname(_at_)firstname(_dot_)lastname(_dot_)name so we reject it because
the foreign
^^^^^^^^^^^^^^^
> mail server is trying to send mail as myself. Convoluted, so I hope
> that made more sense.
Just whitelist the registrar's mailserver on your system, so that SPF
checks will not be applied to mail that is forwarded by the registrar.
*He* is not doing the SPF checks.
He is. He tried sending mail from his "normal" domain to his .name-account,
which then got forwarded to his "normal" domain MX which then in turn
rejected the mail because of a failing SPF test.
The party with the .name domain that
he is trying to send mail to does SPF checks.
Which in this case was himself.
However, all .name
emails are forwarded by the registrar in a manner unfriendly to
SPF. So yes, SPF filters ought to automatically whitelist .name
registrars somehow - but they don't do that now.
They don't need to whitelist them automatically. IMHO manual whitelisting
of your the servers that forward mail from your own alternate accounts
shlould not be too hard. And the result ist exactly the same as envelope
rewriting: effectively no SPF tests (as we can assume that the forwarder
does not use SPF or he would also use SRS or something like that).
The real solution is for .name registrars to make their forwarding
SPF compatible. The obvious solution is return path rewriting (SRS),
with perhaps some optimizations for SES. I wonder if the .name
registrars even check SPF themselves?
I still prefer people individually whitelisting their own alternate
accounts - there are no size limits exceeded by long enevlope sender
addresses (which might not be uncommon with SES), no disguised source
routing for DSNs.
Ralf Döblitz