Prev: Sendmail permissions
Next: Hold all outgoing emails for x minutes before sending
From: Grant Taylor on 6 May 2010 18:21
fesarlis wrote:
> is it possible to reject a message that has no recipients? For
> example, when sender has used only BCC to specify all recipients.

I would think it would be possible to make Sendmail require a To:
header, just like it can require other headers.



Grant. . . .
From: D. Stussy on 6 May 2010 20:43
"Grant Taylor" <gtaylor(a)riverviewtech.net> wrote in message
news:hrvfd3$852$2(a)tncsrv01.tnetconsulting.net...
> fesarlis wrote:
> > is it possible to reject a message that has no recipients? For
> > example, when sender has used only BCC to specify all recipients.
>
> I would think it would be possible to make Sendmail require a To:
> header, just like it can require other headers.
>
> Grant. . . .

With properly crafted macros, one can check for such, but note that such a
requirement is not consistent with the RFCs and standards.


From: Grant Taylor on 6 May 2010 23:31
D. Stussy wrote:
> With properly crafted macros, one can check for such, but note that
> such a requirement is not consistent with the RFCs and standards.

Agreed.

Though, seeing as how spammers have been going against the spirit of
RFCs for so long, we postmasters are having to start considering going
against the letter and some spirit of the RFCs to protect our end users.



Grant. . . .
From: mikea on 7 May 2010 09:14
Grant Taylor <gtaylor(a)riverviewtech.net> wrote in <hs01hp$ce5$2(a)tncsrv01.tnetconsulting.net>:
> D. Stussy wrote:
>> With properly crafted macros, one can check for such, but note that
>> such a requirement is not consistent with the RFCs and standards.
>
> Agreed.
>
> Though, seeing as how spammers have been going against the spirit of
> RFCs for so long, we postmasters are having to start considering going
> against the letter and some spirit of the RFCs to protect our end users.

The RFCs, like the Constitution of the United States, are not a suicide
pact. They are guidance, like military regulations, and deviation from
either by a commander (i.e., systems administrator, mail administrator)
is permissible for good and sufficient reason, though a good explanation
to Higher Authority had best be prepared and forthcoming on demand.

Many of them were written in kinder, gentler times, when the worst
things happening on the Internet were network partitions and the Usenet
spam of Canter and Siegel, and true malicious action was not even on the
horizon of most folks' ponts of view.

--
Mike Andrews, W5EGO
mikea(a)mikea.ath.cx
Tired old sysadmin
From: D. Stussy on 7 May 2010 16:57
"mikea" <mikea(a)mikea.ath.cx> wrote in message
news:0agdb7-fc3.ln1(a)mikea.ath.cx...
> Grant Taylor <gtaylor(a)riverviewtech.net> wrote in
<hs01hp$ce5$2(a)tncsrv01.tnetconsulting.net>:
> > D. Stussy wrote:
> >> With properly crafted macros, one can check for such, but note that
> >> such a requirement is not consistent with the RFCs and standards.
> >
> > Agreed.
> >
> > Though, seeing as how spammers have been going against the spirit of
> > RFCs for so long, we postmasters are having to start considering going
> > against the letter and some spirit of the RFCs to protect our end
users.
>
> The RFCs, like the Constitution of the United States, are not a suicide
> pact. They are guidance, like military regulations, and deviation from
> either by a commander (i.e., systems administrator, mail administrator)
> is permissible for good and sufficient reason, though a good explanation
> to Higher Authority had best be prepared and forthcoming on demand.
>
> Many of them were written in kinder, gentler times, when the worst
> things happening on the Internet were network partitions and the Usenet
> spam of Canter and Siegel, and true malicious action was not even on the
> horizon of most folks' ponts of view.

I'm quite aware of that. However, some people think that gives them the
license to do whatever they want. It doesn't. If someone chooses to
deviate from the standards in disallowing something which the standards
permit:

1) They must take responsibility for their own actions and not blame
others. Some DNSBL operators don't seem to understand that. And...
2) They must do so in a way that is itself valid (and generally accepted)
under the standards.

For example, if one decides to reject all HTML-formatted e-mail (with the
proper MIME headers), then one should do so by responding with a "554 5.6.1
HTML-only messages not supported" rejection message at the SMTP DATA
transmission phase. Accepting and bouncing is not acceptable.


There are valid uses for BCC'ing all the recipients, especially if the goal
is to hide each recipient's mailbox from the others because it is known to
the sender that the recipients don't know each other and have asked for
privacy against disclosure of each of their respective mailboxes.
Therefore, if one wants to reject messages which have no visible recipients
in the headers, one may (with an SMTP rejection sequence, e.g. "554 5.1.0
No visible recipient in headers"), but one should also note that such
messages are technically valid, and therefore should not do something
blatently contrary such as list all the senders (by IP) on some public
DNSBL.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Sendmail permissions
Next: Hold all outgoing emails for x minutes before sending