Hello all,
I'm writing to seek involvement in an SPF-related project.
SPF has a long-standing, documented flaw in the way forwarders are
addressed. While SRS was an attempted solution, it appears that it has
serious implications for the forwarders, who are expected to implement it.
So, I propose an alternative method, the "forwardmaster" method.
Who/what is the forwardmaster and why is it needeed?
===============================================
The forwardmaster is a brother of the postmaster, in a sense.
The forwardmaster is an autoresponder that records the a user's
forwarded accounts. The user sends to the forwardmaster a list of
accounts where he expects to receive mail through in the local mailbox.
The autoresponder runs along side the user's domain mail system. Based
on the user's forwarding paths, the front-end MTAs can make personalized
SPF exceptions on behalf of that user, such that their forwarded email
still reaches them.
This way, email arriving at the user's mailbox via a forwarder will be
delivered, even though the SPF check on the MAIL-FROM fails.
Theory of operation
===================
The user makes up a list of his forwarded email addresses that are
forwarded to the current domain. He sends the list to the forwardmaster
autoresponder, who enters the list into a local database.
The front-end MTA needs to check SPF after RCPT, but before DATA. First,
the sender's SPF record is checked. Then, using the recipient forwarder
list, the domains on the list are checked for SPF "PASS".
If one of the forwarders's records authorizes the incoming IP address,
the front end MTA accepts the email, and passes information to the spam
filter downstream that the mail has likely arrived through a
user-approved forwarder. (ie, direct-SPF=fail + via-SPF=pass +
via=name@forwarder.com)
If a reputation database is used, it should be based on the forwarder.
If the domain has a backup-MX, it should be considered a global
forwarder for all users.
Who should implement this
=========================
- MTAs that deliver to mailboxes
- Due to the ability to daisychain forwarders, even a forwarder may
receive mail from another forwarder, and thus it's SPF check will fail.
It is recommended that forwarders know their upstream forwarding
arrangements in order to filter mail more reliably on behalf of their users.
Some concerns
=============
1. Privacy ... a list of the user's forwarders is on file with the
domain. Is this really an issue? The recipient domain is expected to
handle the user's mail, and the the same information can be obtained
from the email headers.
2. Junk arriving through forwarders
If the forwarder does a poor job of filtering junk
(spam/phish/whatever), it will be reflected in the user's mailbox.
Such junk will likely have the "To:" header point to the forwarded
account, so it's easy to identify that it wasn't the local domain that
allowed the junk, but a forwarder approved by the user. In the case of
forged headers, it will be unlikely that the forged "To:" contains the
local domain name, as a common forger does not know where the forwarded
account is actually delivered. In any case, it is the user's desire to
receive through that forwarder, and thus not the local domain's fault.
Some design requirements
========================
1. The forwardmaster should accept a list of forwarders only from users
with local mailboxes, or who have forwarding arrangements on the local
domain. The receiving MTA knows if the request email is genuine or not
(was it submitted locally? was a password used? does it pass my domain's
SPF checks if not?)
2. The forwardmaster should check the list of forwarders submitted by
the user, and report if some of them do not publish SPF records. For
those it should report that unauthorized mail is possible and likely to
arrive through that forwarder. Also, it should advice the user to
request the forwarder to publish SPF records.
3. When the request mail arrives from a third party, the forwardmaster
should inform the third party of the required procedure:
MAIL-FROM: postmaster@forwarder.com
RCPT-TO: forwardmaster@mydomain.com
550 "Dear postmaster@forwarder.com, please request your user to contact
forwardmaster@mydomain.com directly from their @mydomain.com account"
The same error message should be given if the sender fails SPF, or if
the sender is not a local user.
This would be used later when forwarders will automatically offer to
register the forwarded email account with the destination forwardmaster.
However, this third party registration will never work, so it's good to
set the ground-rules for this rejection message early, to avoid
misunderstandings later.
4. Mail to the forwardmaster is never forwarded from anywhere, so never
make SPF exceptions for the forwardmaster. Also, mail for the
forwardmaster is not expected through the backup MX, but may be expected
through the domain's backup outgoing servers, if any.
5. plain text should be supported initially, HTML and rich text later.
6. The format of the request from the user may be similar to a
mailing-list that allows "subscribe" messages to a list-request
autoresponder.
I would be very supportive if someone would work on this, and there are
more design details to be discussed that don't belong in this
introductory post.
I am currently working on integrating the SPF compiler into a DNS
server, and on several SPF reliability items that have been documented
before. I can and will write such an autoresponder when I'm done with
the current work, but if I have to do it all alone it will take me that
much longer.
This is a good time for SPF supporters to contribute, and your
contribution will be appreciated.
Thank you,
Radu.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
I'm writing to seek involvement in an SPF-related project.
SPF has a long-standing, documented flaw in the way forwarders are
addressed. While SRS was an attempted solution, it appears that it has
serious implications for the forwarders, who are expected to implement it.
So, I propose an alternative method, the "forwardmaster" method.
Who/what is the forwardmaster and why is it needeed?
===============================================
The forwardmaster is a brother of the postmaster, in a sense.
The forwardmaster is an autoresponder that records the a user's
forwarded accounts. The user sends to the forwardmaster a list of
accounts where he expects to receive mail through in the local mailbox.
The autoresponder runs along side the user's domain mail system. Based
on the user's forwarding paths, the front-end MTAs can make personalized
SPF exceptions on behalf of that user, such that their forwarded email
still reaches them.
This way, email arriving at the user's mailbox via a forwarder will be
delivered, even though the SPF check on the MAIL-FROM fails.
Theory of operation
===================
The user makes up a list of his forwarded email addresses that are
forwarded to the current domain. He sends the list to the forwardmaster
autoresponder, who enters the list into a local database.
The front-end MTA needs to check SPF after RCPT, but before DATA. First,
the sender's SPF record is checked. Then, using the recipient forwarder
list, the domains on the list are checked for SPF "PASS".
If one of the forwarders's records authorizes the incoming IP address,
the front end MTA accepts the email, and passes information to the spam
filter downstream that the mail has likely arrived through a
user-approved forwarder. (ie, direct-SPF=fail + via-SPF=pass +
via=name@forwarder.com)
If a reputation database is used, it should be based on the forwarder.
If the domain has a backup-MX, it should be considered a global
forwarder for all users.
Who should implement this
=========================
- MTAs that deliver to mailboxes
- Due to the ability to daisychain forwarders, even a forwarder may
receive mail from another forwarder, and thus it's SPF check will fail.
It is recommended that forwarders know their upstream forwarding
arrangements in order to filter mail more reliably on behalf of their users.
Some concerns
=============
1. Privacy ... a list of the user's forwarders is on file with the
domain. Is this really an issue? The recipient domain is expected to
handle the user's mail, and the the same information can be obtained
from the email headers.
2. Junk arriving through forwarders
If the forwarder does a poor job of filtering junk
(spam/phish/whatever), it will be reflected in the user's mailbox.
Such junk will likely have the "To:" header point to the forwarded
account, so it's easy to identify that it wasn't the local domain that
allowed the junk, but a forwarder approved by the user. In the case of
forged headers, it will be unlikely that the forged "To:" contains the
local domain name, as a common forger does not know where the forwarded
account is actually delivered. In any case, it is the user's desire to
receive through that forwarder, and thus not the local domain's fault.
Some design requirements
========================
1. The forwardmaster should accept a list of forwarders only from users
with local mailboxes, or who have forwarding arrangements on the local
domain. The receiving MTA knows if the request email is genuine or not
(was it submitted locally? was a password used? does it pass my domain's
SPF checks if not?)
2. The forwardmaster should check the list of forwarders submitted by
the user, and report if some of them do not publish SPF records. For
those it should report that unauthorized mail is possible and likely to
arrive through that forwarder. Also, it should advice the user to
request the forwarder to publish SPF records.
3. When the request mail arrives from a third party, the forwardmaster
should inform the third party of the required procedure:
MAIL-FROM: postmaster@forwarder.com
RCPT-TO: forwardmaster@mydomain.com
550 "Dear postmaster@forwarder.com, please request your user to contact
forwardmaster@mydomain.com directly from their @mydomain.com account"
The same error message should be given if the sender fails SPF, or if
the sender is not a local user.
This would be used later when forwarders will automatically offer to
register the forwarded email account with the destination forwardmaster.
However, this third party registration will never work, so it's good to
set the ground-rules for this rejection message early, to avoid
misunderstandings later.
4. Mail to the forwardmaster is never forwarded from anywhere, so never
make SPF exceptions for the forwardmaster. Also, mail for the
forwardmaster is not expected through the backup MX, but may be expected
through the domain's backup outgoing servers, if any.
5. plain text should be supported initially, HTML and rich text later.
6. The format of the request from the user may be similar to a
mailing-list that allows "subscribe" messages to a list-request
autoresponder.
I would be very supportive if someone would work on this, and there are
more design details to be discussed that don't belong in this
introductory post.
I am currently working on integrating the SPF compiler into a DNS
server, and on several SPF reliability items that have been documented
before. I can and will write such an autoresponder when I'm done with
the current work, but if I have to do it all alone it will take me that
much longer.
This is a good time for SPF supporters to contribute, and your
contribution will be appreciated.
Thank you,
Radu.
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com
