On 15 Jan 2021, at 17:51, Dan Mahoney (Gushi) wrote:
All,
In doing a sort of my mailbox, I'm finding that there are many popular
spams with to: undisclosed-recipients. Which is *legal* but, in some
cases shouldn't exist.
In our particular use case, the box we're looking to
All,
In doing a sort of my mailbox, I'm finding that there are many popular
spams with to: undisclosed-recipients. Which is *legal* but, in some
cases shouldn't exist.
In our particular use case, the box we're looking to protect is the
dayjob's info@ box. Nobody should
They can say something along these lines: "Rejected by local policy. Although
e-mails to undisclosed recipients are allowed by RFC-822, the same does not
mandate their acceptance."
Sent from ProtonMail Mobile
On Fri, Oct 27, 2017 at 4:33 PM, David B Funk
wrote:
> On Fri, 2
On Fri, 27 Oct 2017, A. Schulze wrote:
Am 27.10.2017 um 07:15 schrieb @lbutlr:
RFC 822 is obsolete, replaced by RFC 2822.
... which is obsoleted by RFC 5322 and updated some other RFCs
see https://tools.ietf.org/html/rfc5322
And it still explicitly says that construct is legal:
rfc5322:3.4
Am 27.10.2017 um 07:15 schrieb @lbutlr:
RFC 822 is obsolete, replaced by RFC 2822.
On 27.10.17 16:08, A. Schulze wrote:
... which is obsoleted by RFC 5322 and updated some other RFCs
irelevant, the group addresses are still valid:
group = display-name ":" [group-list] ";" [CF
Am 27.10.2017 um 07:15 schrieb @lbutlr:
> RFC 822 is obsolete, replaced by RFC 2822.
... which is obsoleted by RFC 5322 and updated some other RFCs
see https://tools.ietf.org/html/rfc5322
On 25 Oct 2017, at 08:29, Rupert Gallagher wrote:
> Reading RFC 822 again, I spotted the endorsement for the case at hand.
> The named header is compliant to the standard, as quoted below.
RFC 822 is obsolete, replaced by RFC 2822.
--
Apple broke AppleScripting signatures in Mail.app, so no r
Reading RFC 822 again, I spotted the endorsement for the case at hand.
The named header is compliant to the standard, as quoted below.
However, the same standard does not compel a server to accept e-mail
sent to undisclosed recipients: we are free to reject it by local policy.
6.2.6
On 10/24, Dennis German wrote:
> Is there? should there be a rule for a header like:
> To: undisclosed-recipients:;
There is a meta rule in spamassassin version 3.3.1:
header __TO_UNDISCLOSEDTo =~
/(?:undisclosed-recipients|destinataires inconnus):/i
It has no score on i
On 25/10/10 04:21, Dennis German wrote:
> Is there? should there be a rule for a header like:
> To: undisclosed-recipients:;
There was a rule UNDISC_RECIPS in version 3.1, and it scored about 0.8
points. I don't know why it was removed; presumably it hit too much ham.
It used to
Is there? should there be a rule for a header like:
To: undisclosed-recipients:;
On 11/30/2009 03:15 AM, Matus UHLAR - fantomas wrote:
> On 27.11.09 14:04, Philip A. Prindeville wrote:
>
>> for the ruleset:
>>
>
>> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
>>
> just FYI, sendmail can be configure
On 27.11.09 14:04, Philip A. Prindeville wrote:
> for the ruleset:
> header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
just FYI, sendmail can be configured to do different things when To: is
missing - there's sendmail option NoRecipientAction, configured
John Hardin wrote:
On Fri, 27 Nov 2009, Philip A. Prindeville wrote:
header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
Just how do I go about figuring out what the "To:raw" value is (for
example)?
header __TO_RAW To:raw =~ /.+/
If you're analyzing
On Fri, 27 Nov 2009, Philip A. Prindeville wrote:
header __L_UNDISCLOSED1 To:raw =~ /undisclosed-recipients: ;/
Just how do I go about figuring out what the "To:raw" value is (for example)?
header __TO_RAW To:raw =~ /.+/
If you're analyzing something that ma
John Hardin wrote:
On Mon, 23 Nov 2009, LuKreme wrote:
On Nov 23, 2009, at 12:05, Philip Prindeville
wrote:
I want to block all messages that I'm getting that have:
To: undisclosed recipients: ;
undisclosed recipients is used for Bcc: mail
I used it all the time. And you WILL &
On Mon, 23 Nov 2009, John Hardin wrote:
Granted, but in metas such a test can be useful:
http://ruleqa.spamassassin.org/?rule=%2FTO_NO&srcpath=jhardin
Every now and then, someone posts a link like this one, and I find myself
looking at a kind of 'index' page that frankly doesn't mean a thing t
On 11/23/2009 05:11 PM, LuKreme wrote:
> On Nov 23, 2009, at 12:05, Philip Prindeville
> > wrote:
>
>
>> I want to block all messages that I'm getting that have:
>>
>> To: undisclosed recipients: ;
>>
>> with no Cc: line.
>>
>
On 11/23/2009 05:11 PM, LuKreme wrote:
> On Nov 23, 2009, at 12:05, Philip Prindeville
> > wrote:
>
>
>> I want to block all messages that I'm getting that have:
>>
>> To: undisclosed recipients: ;
>>
>> with no Cc: line.
>>
>
On Mon, 23 Nov 2009, LuKreme wrote:
On Nov 23, 2009, at 12:05, Philip Prindeville
wrote:
I want to block all messages that I'm getting that have:
To: undisclosed recipients: ;
undisclosed recipients is used for Bcc: mail
I used it all the time. And you WILL 'block'
On tir 24 nov 2009 01:11:38 CET, LuKreme wrote
I used it all the time. And you WILL 'block' legitimate mail.
and thats always sender to decide its legitimate :)
i see a pattern there
--
xpoint
On Nov 23, 2009, at 12:05, Philip Prindeville > wrote:
I want to block all messages that I'm getting that have:
To: undisclosed recipients: ;
with no Cc: line.
What's Cc: have to do with it? undisclosed recipients is used for
Bcc: mail
I used it all the time. And yo
On 11/23/2009 12:18 PM, Michael Scheidell wrote:
> Philip Prindeville wrote:
>
>>
>> but as you say, if it can't tell the difference between "" and undef,
>> then that's an issue.
>>
>>
>>
> use header ALL to check for a \nCC
> (which could be blank)
>
> or just use your MTA to reject it
Philip Prindeville wrote:
but as you say, if it can't tell the difference between "" and undef,
then that's an issue.
use header ALL to check for a \nCC
(which could be blank)
or just use your MTA to reject it at SMTPtime.
On 11/23/2009 12:10 PM, Michael Scheidell wrote:
> Philip Prindeville wrote:
>
>> Hi.
>>
>> I want to block all messages that I'm getting that have:
>>
>> To: undisclosed recipients: ;
>>
>> with no Cc: line.
>>
>>
>>
Philip Prindeville wrote:
Hi.
I want to block all messages that I'm getting that have:
To: undisclosed recipients: ;
with no Cc: line.
I went round and round with this a while back.
SA 3.25 has a problem with perl null vs 0 vs ''.
so a To header (or CC header) with n
Hi.
I want to block all messages that I'm getting that have:
To: undisclosed recipients: ;
with no Cc: line.
Unfortunately, the rule that I have:
header L_UNDISCLOSEDTo:raw =~ /undisclosed-recipients: ?;/
describe L_UNDISCLOSED To: list is meaningless and no Cc:
ttp://www.nabble.com/Undisclosed-recipients-tp18296454p18302696.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
t up postfix to use spamassassin based on this page:
>> http://www.akadia.com/services/postfix_spamassassin.html. That part is
>> working fine, mail passes through spamd and back into postfix for
>> delivery.
>>
>> The problem is that the delivered mail shows up wit
to
'undisclosed-recipients'. What's causing this? How can I stop it?
Is this happening with all delivered mail or only messages that lack To:
or Cc: headers?
--
Sahil Tandon <[EMAIL PROTECTED]>
d mail shows up with the To: header set to
> 'undisclosed-recipients'. What's causing this? How can I stop it?
I guess it only happens when there's no To: or Cc:. I'd say it's postfix
option. I removed it in sendmail when I found this problem (stops SA from
scoring
losed-recipients'. What's causing this? How can I stop it?
--
View this message in context:
http://www.nabble.com/Undisclosed-recipients-tp18296454p18296454.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
Does anyone know why the UNDISC_RECIPS was removed from
20_head_tests.cf tests? I searched the dev lists and it's mentioned in
the context of being obsolete when ran against the corpus but I've seen
alot of spam that is seen as being sent to undisclosed-recipients (aka
BCC). I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo Van Dinter writes:
> On Mon, Jan 10, 2005 at 12:07:39PM -0500, Matt Kettler wrote:
> > It's not tagged because there's no subject header to be tagged. This is a
> > bug in SA 3.0.0 and 3.0.1, but was fixed in SA 3.0.2.
>
> Just because it annoy
On Mon, Jan 10, 2005 at 12:07:39PM -0500, Matt Kettler wrote:
>
> It's not tagged because there's no subject header to be tagged. This is a
> bug in SA 3.0.0 and 3.0.1, but was fixed in SA 3.0.2.
>
> http://bugzilla.spamassassin.org/show_bug.cgi?id=3816
>
To be fair. This was not a bug, but a
On Mon, Jan 10, 2005 at 12:07:39PM -0500, Matt Kettler wrote:
> It's not tagged because there's no subject header to be tagged. This is a
> bug in SA 3.0.0 and 3.0.1, but was fixed in SA 3.0.2.
Just because it annoys me -- this was not a bug. It worked exactly
as it was designed to. However, en
At 10:50 AM 1/10/2005, Damien Kemens - Equinox Development wrote:
I seem to be having a problem that defies SA logic, so there
must be another variable Im not aware of. A message comes through our
network for Undisclosed Recipients. Here are the related headers:
>X-Spam-Chec
Hi,
I
seem to be having a problem that defies SA logic, so there must be another
variable I’m not aware of. A message comes through our network for
Undisclosed Recipients. Here are the related headers:
>X-Spam-Checker-Version:
SpamAssassin 3.0.0 (2004-09-13) on eq-
38 matches
Mail list logo
