Alan J. Flavell wrote:
>
> > You can discard these messages
>
> That would be a serious step to take. Much more serious than overtly
> refusing mail, IMHO.
I agree, refuse the command, or refuse the message.
> > or put them on bigboard,
>
> Sounds like grounds for legal action against the postmaster. Of course,
> IANAL.
>
> > but you can't reject it.
>
> 7.7 says
>
> It is a well-established principle that an SMTP server may refuse
> to accept mail for any operational or technical reason that makes
> sense to the site providing the server. However, cooperation among
> sites and installations makes the Internet possible. If sites
> take excessive advantage of the right to reject traffic, the ubiquity
> of email availability (one of the strengths of the Internet) will
> be threatened; considerable care should be taken and balance
> maintained if a site decides to be selective about the traffic it
> will accept and process.
>
> I don't see anything there which prohibits you from deciding to reject
> mail "for any operational or technical reason that makes sense to the
> site providing the server". It does no more than to ask for care and
> balance in the interests of the wider community.
>
> The argument has been exercised repeatedly here that 4.1.4 says:
> An SMTP server MAY verify that the domain name parameter in the
> EHLO command actually corresponds to the IP address of the client.
> However, the server MUST NOT refuse to accept a message for this
> reason if the verification fails:
>
> and some appear to claim that this forces you to accept a mail if the
> HELO verification fails, overruling any other clauses that would allow
> you to reject it. I don't buy that.
Neither do I :)
> Even if I'm told not to reject mail solely on the basis of the HELO/EHLO
> domain failing to verify, I'm sure I can find some other justifiable
> reason for rejecting such mail, and I reckon 7.7 confirms my right to do
> that, even within the scope of the RFC itself.
>
> > If you will reject them, you should be filtered.
Why should 'we' be filtered? If you have problems with, or do not know
how to set up, DNS, then you are viewed as an 'untrusted' source.
5xx'ing 'untrusted' sources is universally acceptable I am sure.
> To adapt the wording of the RFC to modern conditions, I might say:
> Because sites have taken excessive advantage of the right to transmit
> traffic, the ubiquity of email availability (one of the strengths of
> the Internet) *is* threatened;
>
> We can't unilaterally change that deplorable state of affairs. We can
> only do our best to protect our users from the 'net (as well as to take
> responsible steps to protect tne 'net from our users, by the way).
Why not? That is what the SPF/Domain Keys/etc. people are trying to do :P
By the way, for all of you that do not like the idea of valid PTR records
go look again at the SPF FAQ (
http://spf.pobox.com/faq.html):
-But do you verify the PTR response?
--Yes, the hostname returned by a PTR has to also resolve back to the IP
--address given. This is standard practice.
Hmm, I guess if things like SPF do get implemented then you'll be a
world of hurt...
Oh, and do notice how they also say that 'This is standard practice'
for how DNS works.
--
--EAL--
