Talk:solution proposed
The forwarding agreement should be simple - an MDA should accept all mail transmitted by this domain to that recipient, and not get involved in spam reporting. The assumptions on forwarded mail are that the Forwarder has already performed spam filtering and other Border functions per the recipient's instructions. The recipient should report spam directly to the Forwarder, not to the MDA.
Likewise, if there is a problem separating one mailing list from another, it should be resolved between the recipient and the Forwarder, and not involve the MDA. We need to keep the forwarding agreement simple, or there will be no universal solution.
Another simplifying assumption is that the MDA will not re-forward any mail (no chain forwarding). There is no good reason for re-forwarding, and it can only lead to confusion in reporting spam and handling bounces. Recipients should understand (and Forwarders should make sure they understand) how forwarding works, and why chain forwarding is unnecessary and unreliable.
MDAs that allow domain-level white listing are already set up to allow forwarding. No special software is required. Note, however, that the whitelisted domain must be that of the Forwarder, not the domain in the Return Address or in any address in the message headers.
The mechanism for setting up a forwarding agreement should not require any new protocols or even extensions of existing protocols. It should be easily automated, but should also work for small domains that have no such automation. A standard request form, from postmaster to postmaster, should be sufficient. For example:
Forwarding Request
To: postmaster@mda.com From: postmaster@forwarder.com Subject: Forwarding Request 8xPk7e
Forwarding Domain: <forwarder.com> Transmitters: [235.66.107.32-5] Recipient Address: <recipient@mda.com>
This recipient has requested that we forward mail to your domain. You should verify this with your recipient.
To accept this request, return this message with the subject line unaltered. To refuse this request, just ignore it. To discontinue forwarding at any time in the future, send an SMTP REJECT in reply to the RCPT TO: command. This will happen normally when the recipient account is removed from your domain.
Please whitelist mail forwarded from our domain to this recipient. This mail has been processed per the recipient's instructions, and needs no further filtering.
Do not report as spam any mail forwarded under this arrangement. The recipient will report spam directly to us at <spamreports@forwarder.com>.
Thank you for your time and attention.
Notice the following features: 1) The subject line is standardized for automated processing - two keywords and an authentication code. The code may be used to verify that a reply is valid. 2) The first three lines of the message body are also set up for automated processing. The information is complete and unambiguous, yet still human readable. 3) The remainder of the message has simple, complete, and unambiguous instructions for someone who might be seeing this kind of request for the first time. --Macquigg 18:43, 22 December 2008 (GMT)
Reasons to complicate the solution
The simpler the solution, the tougher. Why do more than is strictly necessary?
Reporting spam
Users at MDA.com, the broad-sense mail delivery agent exemplified above, have no formal method to distinguish forwarded messages from the rest of their mail. What tool do they use to report spam? Spam reporting is slowly getting standardized. However, currently only its format has been the subject of a proposed draft; see wp:Feedback Loop (email).
A Report Spam button displayed in the context of a message forwarded according to a subscription is ambiguous, since it may be used to either unsubscribe from the mailing list, or signal to the list owner that the message displayed is spam. Users would get the second meaning only if the button is list-specific, which implies the ability to automatically distinguish which list of which forwarder a specific message belongs to. (The latter information should be carried by an Authentication-Results or similar header, since Received headers are difficult to parse.)
On the other hand, even if it were clear where spam reports should be addressed, MUAs may prefer not to get in touch with unknown hosts for security reasons, as it happens for List-Unsubscribe of RFC 2369. Hence, it seems more practicable to uniformly direct all spam reports to the server that is directly responsible for delivering to the given mailbox.
- I agree that the current confusion over spam reporting is unacceptable. I would not expect the MDA to handle all reports, however. This puts too much burden on services that will not handle the reports properly. I use yahoo.com for my MDA, and I certainly don't want them involved in processing spam that came through my Receiver, box67.com. --Macquigg 20:23, 24 December 2008 (GMT)
Chain forwarding
Users choose a mailbox (web, IMAP, POP3) server based on a number of criteria, including convenience, availability, costs. However, they may also want to keep using email addresses at other domains for a variety of reasons, e.g. because it is the place where they work, or they have digital certificates or signed keys that include a given address, or they just gave the address to so many people and places that it will take some time to change it. The only solution in those cases is forwarding, at least temporarily.
- Forwarding is good. Chain forwarding should be discouraged. It serves no good purpose, and vastly complicates authentication, spam reporting, etc. --Macquigg 20:23, 24 December 2008 (GMT)
Users preferences
DNSBL filtering may be considered unreliable without proper whitelisting, since there are large free falling ISPs that don't care being blacklisted, and are still very popular in their area. Some people opt for never publishing their email address, that way they are never targeted by spammers. They would rather skip DNSBL filtering altogether, unless whitelisting were available.
In general, reputation services are based on people judgment. Imposing the choice of a fixed set of reputation services can be a characterizing feature of certain ESPs, but it makes no sense for forwarding. Even if the exemplified procedure mentions processing per the recipient's instructions, it is not clear where those instructions are stored and how the recipient can change them.
- That needs to be made clear by the Forwarder at the time the Recipient initiates forwarding. Blacklists, spam filtering, reputation assessment, and other Border defense functions should be done by the Border MTA. The MDA should handle only functions related to delivery. Things get very messy otherwise. --Macquigg 20:23, 24 December 2008 (GMT)
Automating the process
The exemplified request avoids the only SMTP extension formally required by the solution proposed by replacing the EHLO advertised URL with, e.g., postmaster@MDA.com.
The advantage of SMTP transport is that an handshake can be carried out even without software support. Good point. SOAP can use SMTP transport too; however, that's less readable.
A one-way handshake is certainly simpler than a three-way one. It is also less customizable. Postmaster@forwarder.com will never know whether a request has been refused (and why) or it is just taking more time to be accepted. A new agreement will be needed if MDA.com has to change its transmitters' IPs.
Finally, I think that the advantage of attempting a standardization is that compliant software can be written. I would be available to small and large domains alike.
Ale 15:25, 23 December 2008 (GMT)
- I will support your efforts to get an SMTP extension. Meanwhile, we have to do the best we can with what we've got, even if it is only an interim solution. --Macquigg 20:23, 24 December 2008 (GMT)
Forwarding Setup Confirmation
To: alice@forwarder.com From: postmaster@forwarder.com Subject: Forwarding Request 8xPk7e
Incoming address: alice@forwarder.com Destination address: alice@mda.com Forwarding setup page: http://forwarder.com/ForwardingSetup Options selected: A1 B3 C2 D5 WL Alternate address: alice-alternate@mda.com
To confirm this request, reply to this message with the subject line unaltered. To cancel this request, just ignore this message. To avoid confusion and possible rejection of this request, make sure proper arrangements have been made at the destination address. Do this now, before sending the reply to this message.
Failure to make arrangements at the destination may result in a surprising and sudden cancellation of forwarding sometime in the future. See below for details.
Upon receipt of this confirmation and acceptance of a "forwarding agreement" by the destination postmaster, we will forward mail as specified above. You can check the status of this forwarding agreement at your forwarding setup page. You can also initiate forwarding with no agreement by the destination domain, but see below for warnings.
We will send you a reminder once per month as long as your forwarding arrangement is active.
****** Details on setting up forwarding at a destination domain ******
The biggest problem in forwarding is erroneous spam reports against the Forwarder (us). If that happens, we will immediately cancel the forwarding arranagement, and notify you at your alternate address above.
Forwarded mail should go directly to its final destination, and not be forwarded again. "Chain forwarding" almost always leads to problems such as authentication failures, erroneous spam reports, etc.
Spam filtering, blacklisting, and other Border defense functions should be done just once, at the server which first receives the mail (the "Border MTA"). We will perform these functions to the best of our ability, following the instructions on your Recipient Options form http://forwarder.com/RecipientOptions.
Please whitelist mail forwarded by our domain to your destination address. Do not use the destination domain's spam reporting process. Report spam directly to us at <spamreports@forwarder.com>. See http://forwarder.com/SpamReports for details.
If your destination domain does not provide whitelisting, or is not able to properly authenticate our transmitters, an alternative is to set up a new account with a private name just to store your forwarded mail. Use an address that spammers cannot guess, like alice85770. For more recommendations, and a list of services that support forwarding, see http://forwarder.com/ServiceProviders.
--Macquigg 20:23, 24 December 2008 (GMT)
