RE: HELO vs. MAIL FROM

> I'm still thinking about the proposal to verify
> the host name given in HELO/EHLO instead of
> MAIL FROM sender envelope address.
>
> I agree on two details:
>
> - It is a good idea to consider the sending MTA as
>   an originator of an error message if the sender
>   envelope address is empty (<>) and to use the
>   given host name (or it's domain part?) instead for the
>   RMX lookup.

I think we've agreed on that a long time ago.  DMP and SPF use HELO for null
reverse path messages.

> - It does not break any forwarding mechanism.

> I'll give a real world example:
>
> This particular message is sent with a sender envelope
> address  <[email protected]>, because I am the originator
> and initiator of the message. correct.
>
> But it is delivered to the world through my ISP's relay
> which's host name is sklave3.rackland.de, which is also
> used in the EHLO command.

Hm, I wonder if some kind of provision could be made such that, if checking
MAIL FROM fails, at least ensure the HELO'd hostname is valid so we know who
is responsible for sending the mail.  I'm interested in restoring
accountability, but it actually doesn't matter who I restore accountability
TO.

So how about this:

* If source IP is allowed to send mail for the domain in MAIL FROM, OK.

* If not, or if non-participant, or if null sender, check HELO'd hostname to
see if it's allowed to send mail for itself.  If so, accept the mail.  If
not, bounce it, tag it, or do something else.

It's a little weaker than purely authenticating against MAIL FROM, and it
would allow some spam through, but it would clearly point the finger at
who's accountable - the admins of the server that HELO'd itself.  And it
would allow .forward.

For DMP though, It would require possibly a third lookup.  Possibly two for
the sender domain and one more for the sender host.  For obvious things like
null reverse paths it would skip to the HELO lookup, but for .forward it
would cause additional DNS overhead.

>From a DMP approach it would go like this:

C: HELO clientmachine.example.com
S: 250 servermachine.example.net Helo clientmachine.example.com [192.0.2.1]
C: MAIL FROM:<[email protected]>
S: (Check DMP records for not-example.com - no match for 192.0.2.1)
S: (Check DMP records for clientmachine.example.com - match found for
192.0.2.1)
S: (optional: check forward DNS or reverse DNS or both, for
clientmachine.example.com, and let's say it was acceptable)
S: 250 OK not authorized sender for not-example.com, but
clientmachine.example.com authorized to send for itself

A spammer would have to go to the trouble of creating DMP records for
machines he has full control over, ensure they HELO or EHLO with a correct
hostname, make sure they match the right IPs, etc etc etc... maybe a spammer
might take the time to do this if he has rooted a bunch of DNS servers, or
some such BS.  And that's assuming the receivers don't verify forward or
reverse DNS.

Of course some DMP participant might have an open relay or an open proxy.
Well, this is a problem anyway and they'd get fingered rather quickly.

--
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email protected]>
What's a PGP Key?  See <http://www.pan-am.ca/free.html>
GOD BLESS AMER, er, THE INTERNET. <http://vmyths.com/rant.cfm?id=401&page=4>