Re: [exim] Rejecting messages with no "To:" or "Cc:" fieldin…

Inizio della pagina
Delete this message
Reply to this message
Autore: Murray S. Kucherawy
Data:  
To: Always Learning, exim users
Oggetto: Re: [exim] Rejecting messages with no "To:" or "Cc:" fieldintheheaders
> -----Original Message-----
> From: exim-users-bounces@??? [mailto:exim-users-bounces@exim.org] On Behalf Of Always Learning
> Sent: Tuesday, March 01, 2011 8:13 AM
> To: exim users
> Subject: Re: [exim] Rejecting messages with no "To:" or "Cc:" field in the headers
>
> > In fact, Section 4.1.4 of RFC2821 and of RFC5321 specifically disallow
> > filtering based on a reverse DNS mismatch of the HELO/EHLO parameter.
>
> In fact, no match = no emails accepted.
>
> If a sender can't be bothered to get the HELO / EHLO name right and
> therefore uses a bogus or non-existent name thereby emulating the
> behaviour of many spammers, why should we be 'bothered' to lower our
> security and accept emails from a site which can not be bothered to
> properly announce its authentic identity ?
>
> Laziness and/or sloppiness is indicative of a 'could not be bothered'
> attitude to security generally.
>
> Definitely don't want emails from any potentially dodgy sites.


I was just talking about what the RFCs say. I'm not saying filtering beyond that is technically or ethically wrong, but it's important to be aware of the difference.

I also filter on bogus HELO information at home, contrary to the RFCs, though I only do syntax checks and don't actually try the DNS checks. But even doing just that filters out a ton of junk. The most common deviation is the absence of a dot someplace in the parameter (which means the parameter can't possibly be a fully-qualified name, as required) or a parameter that looks like a valid IP address yet isn't enclosed in square brackets. And such checks don't introduce two DNS round-trip delays.

> We also refuse emails lacking these headers: To, From, Date and Subject
> although they can be blank. Plus, of course, no Message-ID:


The RFCs require From only, so something that doesn't have a From is not a valid email and you'd be fine to toss it.

The rest are your own local policy choices, and SMTP allows for that as well, but you're technically rejecting a syntactically valid piece of email in that case.

-MSK