>>>...
>>> ..."
>>>
>Now, these are the rules....
>
>However, I still believe it is perfectly legal to refuse mail if
>- the HELO matches my own MX, or lists one of my IPs
>or
>- the MAIL FROM pretends to be one of my users
>
>I am currently refusing this stuff at the MTA level and suggest to
>authenticate (my own users
>would do that, if they use the server to send mails to each other)
>So far the only exception is ebay processing where an ebay server tries to
>send mail
>FROM a valid user on the system TO the same user (and perhaps to others)
>
>Wolfgang Hamann
>
>
Wolfgang,
Here I agree with you entirely; My systems return an error
message saying "You're lying" and refuse with a 550 if someone forges
one of my addresses or 'MX's in the HELO/EHLO. But that is not the same
as the case of "validating" the domain; That is a case of directly
validating the HELO/EHLO sign-on and recognizing that it is forged -
you have no need to "check" against the client IP to do that (the
specific case mentioned in the RFC), so it doesn't seem (to me) that
section 4.1.4 applies in that case.
Even if I'm wrong, I still agree with you - an obvious forgery
*can* and should be refused on that basis alone.
Paul Shupak
[EMAIL PROTECTED]
P.S. I've seen ebay use questionable "From:" lines, but I allow them;
They seem to always (for my systems) use valid HELO/EHLO names. You
are *probably* also on safe ground refusing an obviously forged "From:"
line (I haven't checked, but in general it seems almost obvious - still,
you can't refuse mail to "postmaster" on that basis - Section 4.5.1 RFC2821
again; Also, other things which seem obvious, like a authoritative name
server must have an 'SOA' record for that domain, have actually been
forgotten by oversight in the RFCs - and hopefully will be fixed in a
revision or new RFC). I don't, but probably should also refuse "From:"
lines forging my own domains (every case like that I have gotten has been
caught be some other level of filtering, but refusing at the SMTP level
would be preferable!
