-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Arthur Kahlich wrote on spf-devel:
Julian Mehnle wrote:
Stuart D. Gathman wrote:
Unfortunately, way too many of my clients customers send their email
with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in
general is regrettably not an option at this late stage of RFC2821
apostasy.
That shouldn't be an issue. End-user software should never be allowed
to connect to recipient MTAs directly. Instead, they should be
channeled through a sender-side submission server (MSA) with
authentication. The MSA can then ignore any brain-dead input data and
override it when relaying the mail.
I have been a lurker on [the spf-devel] list up until now, but I have a
common use case that seems to contradict what Julian has said [above].
Unless I am missing some subtlety here, whenever I send email to another
user on my mail server my end-user software is connecting directly to my
recipient MTA, using the same mechanism that a remote mail server would
use to deliver mail to my mail server. The validation mechanism is
different in that a login is required, but that is the only difference I
know of. Since I administer a small organization I can enforce proper
HELO names, but in general this is not true.
(This really belongs on spf-discuss, so please follow up there.)
Arthur, in your scenario, your internal MTA is dual-acting as the MSA,
given that your end-user software still authenticates with it when sending
mail to other users on that server. So my statement still holds.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFW2MVwL7PKlBZWjsRAn2dAKD6+OrXvx+no6JjtBN2zJM97G90aACfegSI
LVC3JHRG/KqkH4nh7SogSOQ=
=00AO
-----END PGP SIGNATURE-----
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735