Why is this turning out to be such a big problem when there is such a
simple solution to the problem? It's called the "Sender" field in the
header and it's been there since day one, RFC 821.
Forget SRS, it's not needed.
Forwarders should always add a "Sender" header record because the they
are sending the forwarded message.
Mailing lists should use the "Sender" since they are sending the
message...
MSA's should always add a "Sender" header when the "From" field is not
the same as the authenticated sender.
SPF tests should always use the "Sender" if there present, not the
"From".
So the SPF check should work as follows.
If there is a "Sender" use it for checking and ignore the "From" else
use "From".
Problem solved, now I can use my AOL address when sending from another
ISP without having an issue with SPF. The "From" is not forged if the
"sender" is present.
So Meng, can you update the SPF docs to include this and then we can
put this one to bed and move on to other topics.
On 11 Jan 2004 at 14:17, Meng Weng Wong wrote:
Note: I would prefer spf-discuss to focus on the challenge of adoption.
If you can help implement sender rewriting in an MTA, please join the
spf-devel list.
These are my thoughts on a strategic response to the forwarding problem.
Postfix-users has been going back and forth on the SPF issue. They have
identified forwarding as the biggest obstacle to SPF. I proposed sender
rewriting (http://spf.pobox.com/srs.html) and asked what it would take
to implement in Postfix. I personally believe that SRS is a horrible
hack, that it is terribly inelegant, and can lead to monstrously long
return paths if a message passes through multiple forwarding providers.
I also believe that the choice between 1.6 billion spams per day and an
ugly return-path is a no-brainer.
Schemes involving cryptography are the long-term solution. SPF may only
only be a step along the way, but it is a necessary step. I expect the
SPF syntax and architecture to outlive the "a mx ptr" mechanisms, as we
move toward next-generation mechanisms like "smime" and "gpg" and "envid".
In twenty years I expect to see signature credentials being passed in
the message headers or body or envelope. That will require upgrading
everyone's MTAs. And when those credentials are being passed,
forwarding will work again. Until then, I expect this to happen:
1) organizational forwarding providers like acm.org, pobox.com, and
alumniconnections will implement SRS. They have people on their
payrolls to do just that sort of thing.
2) major ISPs which provide forwarding services will implement SRS.
3) proactive / cutting edge / early-adopter / small hobbyist sites that
support forwarding will also implement SRS, by applying patches to
their MTA. We need to start working on SRS patches for MTAs so they
can do this.
4) MTA admins at sites that don't care about forwarding will watch
forwarding break. But this is okay! Why is this okay? Because the
ordinary end user population doen't care that an /etc/aliases entry
has stopped working. The ordinary end user population cares that
their mail gets through. I am counting on them to adapt: if a
forwarding address bounces, they will figure out an alternative email
address for the person, and they will use that instead. They won't
go on a campaign to convince everyone that classical forwarding as we
know it is an absolute moral good and must be defended at all costs.
(Well, some people will, but they tend to get ignored.) Forwarding
is just one way of doing things that people have gotten used to. It
will break for a little while, and then, when we move past designated
sender schemes, it will start working again.
So now what the world needs is SRS patches to MTAs. Here are some
thoughts from the postfix list:
On Sat, Jan 10, 2004 at 11:35:11AM -0500,
Victor(_dot_)Duchovni(_at_)morganstanley(_dot_)com wrote:
| On Sat, 10 Jan 2004, Wietse Venema wrote:
|
| > That would be too late. The SMTP server must know whether an RCPT
| > TO or MAIL FROM presents a valid address before accepting the mail.
| >
|
| Also the counter in the cookie cannot reasonably scale to more than one MX
| host without introducing unreasonable requirements for centralized
| storage.
|
| 1. I am not likely to either implement SPF or say that SPF is a good idea
| any time soon.
|
| 2. This said, the question of *when* to perform SPF rewriting if such
| rewriting were to be done wisely or otherwise can be made clearer:
|
| - SRS Rewriting is only performed when the recipient address is
| changed in transit through the current host. So backup MX hosts
| do no rewriting, they are not forwarders, they are relays.
|
| - Also gateway systems do no rewriting, even when they do rewrite
| the envelope recipient, when they perform gatewaying for the
| destination system.
|
| - Virtual alias domains may have recipients in related domains
| behind a gateway (corporate deployment) or recipients in
| unaffiliated domains (ISP deployment). Postfix would have to
| distinguish between the two cases, presumably the "smtp"
| transport would SPF, and the "relay" transport would not.
|
| - SRS Rewriting is only performed when the original sender is
| intended to receive bounces, no such rewriting is required for
| mailing list submissions. Rewriting is required for alias
| expansions lacking a local "owner-" alias.
|
| - Hosts may not apply SPF restrictions when receiving mail from
| backup MX hosts or gateways associated with their organization.
| Only mail originating from suitably defined external systems
| that is again to be forwarded needs SRS sender rewriting.
|
| ...
|
| The implementation logic in the delivery agent would be something along
| the lines of:
|
| if (strcmp(rcpt, orcpt) != 0 /* Potential forwarding */
| && var_srs_rewriting /* Yes in "smtp" no in "relay" */
| && is_spf_domain(sender) /* Domain is not ours and does SPF */
| && !trusted_origin(origin) /* Did message orinate from "outside" */
| && .. more conditions? ...)
| {
| srs_sender = srs_rewrite(sender);
| }
|
| The trusted_origin() test needs to be performed accurately and is hard to
| get right. The SPF domain status lookup may fail, so one would have to
| defer the message until the sender domain status can be verified. Saving
| this in the queue file when the message is accepted can be wrong, because
| the message can be in the queue a long time, and the domain SPF records
| may change in the mean-time, so the status likely needs to be looked
| during delivery.
|
| Wietse's point about egress sender validation applies, since
|
| bounce+remote+cookie(_at_)mydomain
|
| cannot be easily checked on egress. And of course on ingress the
| bounce+remote+cookie(_at_)mydomain address would need to be checked in the
SMTP
| daemon (another policy server).
|
| Growth in the sender address along the forwarding path can get quite
| unreasonable, but once all the sites along the path use SRS cookies the
| address cannot be trimmed without saving state and introducing a central
| data store for cooperating MX hosts. If there was a *standard* SRS
| encoding acceptable to all, one could save just the previous hop's cookie,
| this is not likely to happen any time soon and imposes unreasonable
| constraints on the structure of the *local* part of the address whose
| semantics have always been *local*.
|
| If I were to bet money on the likelihood of widespread interoperable
| robust SPF/SRS adoption within the next 5 years, I would bet against it
| even at unfavourable odds...
|
| --
| Viktor.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
----------------------------------------------------------------------
John Warren, President | Tel.: +1 714-573-9650
Warren Engineering | Fax: +1 714-573-9289
14681 Danborough Rd. |
mailto:jwarren(_at_)wenet(_dot_)tustin(_dot_)ca(_dot_)us
Tustin, CA 92780-6755 |
mailto:info(_at_)wenet(_dot_)tustin(_dot_)ca(_dot_)us
| http:Someday.com
+--------------------------------------------------------------------+
| Any and all use of my email address for bulk email without my |
| expressed permission is prohibited. This means NO JUNK EMAIL, SPAM.|
| Support the anti-Spam amendment, Join at http://www.cauce.org/ |
+--------------------------------------------------------------------+
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡