Hello,
I hope thanks to the nice SPF/RMX proposals, soon every domain will have
information about legitimate MTAs. Looks like very valuable work is
ongoing on these proposals :-)
There is still one significant recognised hole : there is no smooth
strategy to transition the internet to spf while addressing the
challenge of forwarding.
Forwarding is so common that as long as the "sender rewriting scheme" is
not in general use, SPF has limited value. And SRS requires such big
changes that we need something else in the meantime or IMHO SPF is
doomed :-(.
If we cannot reject based on from address (because of the forwarding
issue), then the SPF proposal could give a even bigger role to the HELO
content, and also ask the user to tell the sets of domains through which
his email is allowed to be forwarded. The SPF RFC already propose this
nice requirement:
An SPF-conformant mail client MUST announce EHLO or EHLO with a
hostname which passes the SPF test when sending mail with a null
envelope sender.
I think this condition should be checked even for emails with non-null
from, and the Received-SPF header should be modified/extended to
systematically include the results of the two tests:
spfquery based on from
spfquery based on helo
Then the RFC could be modified to say that email should not be dropped
based only on a "from validation" unless we are sure the sender cannot
be a legitimate forwarder for the destination (based for instance on
external info where the user explicitely tell that his email is not the
target of any forwarding service or old-style mailing-list).
Then in the most common case forgery is detected either:
- at HELO level (HELO forgery)
- if more information about authorized forwarders for the target is
known: we can analyse the whole chain of Received-SPF: headers, finding
where the email entered the set of authorized forwarders, and then using
the result of the spfquery based on the from spfquery result at the
entry point.
The list of authorized intermediate domains for a target could be
supplied in the DNS like the other SPF info (for instance through a
._smtp_user.domain.com, there was a reference to such a domain some time
ago on the list).
This scheme extention add more requirements to the original proposal,
dropping forged email is generally done later and to be as fool-proof it
requires that the user supply a set of allowed forwarding domains for
his target mailbox.
But on the other hand this solution can be deployed more easily than
SRS, the whole scheme of SPF preventing email forgery is reconciled with
forwarding. Users interested in not having spam have the responsability
of providing info about their authorized forwarders, either through some
DNS _smtp_user provided by the mailbox provider or in the beginning by
some default domain like _smtp_user.spf.mailzone.com provided by some
charitable organization.
Regards,
Loic
Note: even if intermediate MTAs are not SPF-enabled, the Received-SPF
info can generally be infered later based on the "Received:" fields, as
long as the SPF info is in the DNS for them. The internet can be fully
SPFized by just entering DNS info and making use of it at the target
mailbox location.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@©#«Mo\¯HÝÜîU;±¤Ö¤Íµøˆ¡
I hope thanks to the nice SPF/RMX proposals, soon every domain will have
information about legitimate MTAs. Looks like very valuable work is
ongoing on these proposals :-)
There is still one significant recognised hole : there is no smooth
strategy to transition the internet to spf while addressing the
challenge of forwarding.
Forwarding is so common that as long as the "sender rewriting scheme" is
not in general use, SPF has limited value. And SRS requires such big
changes that we need something else in the meantime or IMHO SPF is
doomed :-(.
If we cannot reject based on from address (because of the forwarding
issue), then the SPF proposal could give a even bigger role to the HELO
content, and also ask the user to tell the sets of domains through which
his email is allowed to be forwarded. The SPF RFC already propose this
nice requirement:
An SPF-conformant mail client MUST announce EHLO or EHLO with a
hostname which passes the SPF test when sending mail with a null
envelope sender.
I think this condition should be checked even for emails with non-null
from, and the Received-SPF header should be modified/extended to
systematically include the results of the two tests:
spfquery based on from
spfquery based on helo
Then the RFC could be modified to say that email should not be dropped
based only on a "from validation" unless we are sure the sender cannot
be a legitimate forwarder for the destination (based for instance on
external info where the user explicitely tell that his email is not the
target of any forwarding service or old-style mailing-list).
Then in the most common case forgery is detected either:
- at HELO level (HELO forgery)
- if more information about authorized forwarders for the target is
known: we can analyse the whole chain of Received-SPF: headers, finding
where the email entered the set of authorized forwarders, and then using
the result of the spfquery based on the from spfquery result at the
entry point.
The list of authorized intermediate domains for a target could be
supplied in the DNS like the other SPF info (for instance through a
._smtp_user.domain.com, there was a reference to such a domain some time
ago on the list).
This scheme extention add more requirements to the original proposal,
dropping forged email is generally done later and to be as fool-proof it
requires that the user supply a set of allowed forwarding domains for
his target mailbox.
But on the other hand this solution can be deployed more easily than
SRS, the whole scheme of SPF preventing email forgery is reconciled with
forwarding. Users interested in not having spam have the responsability
of providing info about their authorized forwarders, either through some
DNS _smtp_user provided by the mailbox provider or in the beginning by
some default domain like _smtp_user.spf.mailzone.com provided by some
charitable organization.
Regards,
Loic
Note: even if intermediate MTAs are not SPF-enabled, the Received-SPF
info can generally be infered later based on the "Received:" fields, as
long as the SPF info is in the DNS for them. The internet can be fully
SPFized by just entering DNS info and making use of it at the target
mailbox location.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname@©#«Mo\¯HÝÜîU;±¤Ö¤Íµøˆ¡