Let's stop and take a deep breath.
Ok, now that we done that I'm going to restate my idea since my
original one was on the right track but had some flaws and my adjusted
one seems not to have gotten across.
First I'd like to stick to the problem that needs to be solved and not
what the mail systems are doing now.
The idea of using SRS is going to require changes to MTAs which would
also be the case with what I'm purposing but I think my changes follow
the RFCs better than SRS.
I also think that my idea is already based on what the intent of RFCs
2476 and 2821 but is not currently being used as I think it should be.
I could be wrong.
----
Problem.
Being able to prove that mail is being sent from a valid mail host and
or user.
Solutions:
SPF and IMX plus others. IMX does take care of where mail comes from
and SPF does protect the domain owner. Both can and should work
together.
----
Problem:
Being able to send mail using your legal e-mail address from a domain
other than the one in your e-mail address. This has very basic and
valid business reasons and needs to not be blocked.
Users in the the field may need to send mail from their company when
they can not get that mail back to their company mail server. The only
way that they can send it is to use the ISP mail server they are
connecting to.
The problem is how to do this and still track the sending user. SPFs
filtering could cause valid mail of this type to be blocked.
Solution:
The Sending MTA/MSA must make sure that the "MAIL FROM" in the SMTP
envelope MUST always contain the valid local authenticated e-mail
address of the of the sender no matter what the sender puts in the
"FROM" or "REPLY-TO" fields in the message header. Both RFC 2476 and
2821should be updated to require this since it's currently ambiguous.
The Sending MTA Should replace or add, as required, a "SENDER" field to
the message header, as stated in RFC 2476, that matched the "MAIL
FROM" used in the SMTP envelope.
I think that RFC 2476 should be changed to make this a MUST rather than
SHOULD requirement.
----
It is understood that a mail server that runs as an open relay need not
do any of this but we all know what happens to open relay mail servers
so it's a non-issue.
It is my belief that this then solves a lot of issues. You have domain
protection in messages sent as SPF is trying to do because you know who
the real sender is.
You have the ability to send a message using your valid and legal
domain name from another domain. This can be done since since you now
know who sent the message even though they have legally forged their
"From" e-mail address.
Forwarding can always be done since you know who forwarded the message.
Mailing list can forward without problems since she sender, the list,
is know.
You can block all mail sent with a "MAIL FROM" that contains a domain
that the sending mail server is not listed under without any issues of
blocking good mail.
Win, Win, Win so what am I missing?
----------------------------------------------------------------------
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;±¤Ö¤Íµø?¡