-----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-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
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-----
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007