Re: spam emails with "to:" line missing

[li...@lazygranch.com]

On Fri, 15 Apr 2022 11:06:35 +0200
Tinne11  wrote:

> 
> > Am 15.04.2022 um 08:49 schrieb Fourhundred Thecat
> > <400the...@gmx.ch>:
> > 
> > Are there any legitimate cases where "to:" might be missing?
> 
> 
> RFC 5322 says: "The only required header fields are the origination
> date field and the originator address field(s).", i. e. the "Date:"
> and the "From:" header field.
> 
> 
> 
> I have sent this answer without any address in the to header field.

This email had a "TO" to me. 

I just experimented on my own, that is do a message using BCC and then
one with the TO field. I can confirm the message using BCC didn't have
a TO field. This is on my own postfix/dovecot implementation.

I routinely send messages just using BCC if I know that all the
recipients don't have each others email addresses. 

Re: spam emails with "to:" line missing

[Viktor Dukhovni]

On Fri, Apr 15, 2022 at 04:30:19PM -0600, @lbutlr wrote:

> However, it is *very* common for a BBC email to have a To header with
> no email address in it at all,

This violates RFC5322 and earlier versions.  The "To:" header must
contain at least one address (or group).

https://datatracker.ietf.org/doc/html/rfc5322#section-3.4
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.3

-- 
Viktor.

Re: spam emails with "to:" line missing

[@lbutlr]

> On 2022 Apr 15, at 07:30, Benny Pedersen  wrote:
> 
> On 2022-04-15 10:47, Bernardo Reino wrote:
> 
>> Many e-mails are sent to "BCC" lists, so they have no To: header (or
>> have one with "undisclosed-recipients").
> 
> bcc does not remove or add to

No, and that's not what what said. However, it is *very* common for a BBC email 
to have a To header with no email address in it at all, and not that uncommon 
to see one with no To address at all )or at least it was, since I recall being 
confused by this last century).

>> So I'd be careful with rejecting/filtering only based on that.
> 
> spammers does not know all that details :=)

Rejecting messages that are valid based on a misunderstanding of what is 
correct is a mistake that WILL end up biting someone hard.

If you're picking around with your own email, have at it, you've no one to 
blame but yourself. However, if your mail server handles email for anyone but 
you, you should be respectful enough of the rules and norms to not screw up 
their email.

-- 
A bird in the hand makes it difficult to blow your nose.

Re: Virtual domains

[Emmett Culley]

On 4/15/22 10:15 AM, Matus UHLAR - fantomas wrote:

On 14.04.22 08:26, Emmett Culley wrote:

I recently changed the host name of one of the servers from one domain I am 
hosting to another of the domains the server is serving.

Upon verifying the server I noticed that the Received: headers on email sent 
via that server now have the new host name


This is completely irelevant to mail processing, unless the new mail server's 
name does not exist in DNS, or has a SPF record that disqualifies the server 
from announcing itself.


and so causes Thunderbird to show the from address in red for emails from 
domains that are different from the server's hostname.


Sorry, I have no idea what you are talking about. Can you provide a screenshot 
somehow?


Is there anything I can do to specify that the Recieved: headers have the 
"correct" domain name depending on what domain is sending an email (From:)?


you do not need this. your problem apparently

I have DKIM working in such a manner.  When an email is sent for domain.one 
(From: domain.one) the dkim signature contains the signature for domain.one and 
if sent for domain.two (From: domain.two) it contains the dkim signature for 
domain.two.  No matter what the server's hostname is set to.

I guess I am asking if there is any way to map the sending domain written to 
the header (From.: domain.tld) to the domain the email was sent as? Similar to 
how opendkim does when choosing the DKINM signature to add to the outgoing 
email's header.


the domain in From: should be the one you or other senders have configured in 
thunderbird or other mail clients, and is not related to the mail server's name.

This was caused by a missed configuration with my mail server's openDKIM 
configuration.  Thanks for the clue.



On 4/14/22 9:58 AM, Wietse Venema wrote:

The Received: headers contain the value of the "myhostname" parameter,
i.e.  the identity of this Postfix MTA instance. This name should
match the IP address where the MTA sends and receives mail.

Postfix can send and receive email on behalf of many domains. Email
is not like HTTP, and there is no requirement that the Postfix MTA
identity matches the name of every domain that it handles mail for.
But it is supported ever since Postfix got SNI support a few years
ago.


On 14.04.22 10:02, Emmett Culley wrote:

Thanks Wietse.  I will study up on SNI.  I am working on new servers with 
RockyLinux 8 and so will also be using a newer version of postfix.


SNI is only used when you connect to the server to send or receive
e-mail, and your customers have multiple servernames configured in their
mail clients.

If you have @example.com domain address and connect to mail.example.com, you
only need SNI if other users with @example.net address use mail.example.net
on the same server.  This way, if you have separate certificates for
mail.example.com, mail.example.net etc, you need SNI.

If you have single certificate with alternative names mail.example.com,
mail.example.net etc, you do NOT need SNI.

Usually, people use mail.example.org as smtp/imap/pop3 server and
use @example.com or @example.net addresses, and server only needs
certificate for mail.example.org.


I see that I was concerned about nothing, simply because thunderbird had a working DKIM 
checker.  I had assumed it was a misconfiguration on the mail server that was causing the 
warning.  It wasn't until I looked a the header source for those emails that looked 
"bad" that I found they did not have a dkim signature.

They all relay via my main servers and the "bad" one's were not listed in the 
opendkim trustedhosts file on those servers, and so no DKIM signature was added upon 
relay for those servers.

Emmett

Re: Virtual domains

[Matus UHLAR - fantomas]

On 14.04.22 08:26, Emmett Culley wrote:
I recently changed the host name of one of the servers from one domain I am 
hosting to another of the domains the server is serving.


Upon verifying the server I noticed that the Received: headers on email 
sent via that server now have the new host name


This is completely irelevant to mail processing, unless the new mail 
server's name does not exist in DNS, or has a SPF record that disqualifies 
the server from announcing itself.


and so causes Thunderbird 
to show the from address in red for emails from domains that are different 
from the server's hostname.


Sorry, I have no idea what you are talking about. Can you provide a 
screenshot somehow?


Is there anything I can do to specify that the Recieved: headers have the 
"correct" domain name depending on what domain is sending an email 
(From:)?


you do not need this. your problem apparently 

I have DKIM working in such a manner.  When an email is sent for domain.one 
(From: domain.one) the dkim signature contains the signature for 
domain.one and if sent for domain.two (From: domain.two) it contains the 
dkim signature for domain.two.  No matter what the server's hostname is 
set to.


I guess I am asking if there is any way to map the sending domain written 
to the header (From.: domain.tld) to the domain the email was sent as?  
Similar to how opendkim does when choosing the DKINM signature to add to 
the outgoing email's header.


the domain in From: should be the one you or other senders have configured 
in thunderbird or other mail clients, and is not related to the mail 
server's name.



On 4/14/22 9:58 AM, Wietse Venema wrote:

The Received: headers contain the value of the "myhostname" parameter,
i.e.  the identity of this Postfix MTA instance. This name should
match the IP address where the MTA sends and receives mail.

Postfix can send and receive email on behalf of many domains. Email
is not like HTTP, and there is no requirement that the Postfix MTA
identity matches the name of every domain that it handles mail for.
But it is supported ever since Postfix got SNI support a few years
ago.


On 14.04.22 10:02, Emmett Culley wrote:
Thanks Wietse.  I will study up on SNI.  I am working on new servers with 
RockyLinux 8 and so will also be using a newer version of postfix.


SNI is only used when you connect to the server to send or receive
e-mail, and your customers have multiple servernames configured in their
mail clients.

If you have @example.com domain address and connect to mail.example.com, you
only need SNI if other users with @example.net address use mail.example.net
on the same server.  This way, if you have separate certificates for
mail.example.com, mail.example.net etc, you need SNI.

If you have single certificate with alternative names mail.example.com,
mail.example.net etc, you do NOT need SNI.

Usually, people use mail.example.org as smtp/imap/pop3 server and
use @example.com or @example.net addresses, and server only needs
certificate for mail.example.org.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
You have the right to remain silent. Anything you say will be misquoted,
then used against you.

Re: spam emails with "to:" line missing

[Bernardo Reino]

On Fri, 15 Apr 2022, Benny Pedersen wrote:


On 2022-04-15 10:47, Bernardo Reino wrote:


 Many e-mails are sent to "BCC" lists, so they have no To: header (or
 have one with "undisclosed-recipients").


bcc does not remove or add to


I didn't say that :)
(maybe the "so they have no.." implied some causality?)

Rephrased: There are e-mails sent only to addresses in [B]CC: which might not 
have a To: header at all.



 So I'd be careful with rejecting/filtering only based on that.


spammers does not know all that details :=)


It is IMHO irrelevant what you think spammers may or may not know.. I would just 
advice not to reject/block based on lack of To: header.


Rspamd tags such e-mails with the MISSING_TO flag, to which you can assign 
whatever score you wish (default is 2.0 IIRC).


Cheers,
Bernardo

Re: spam emails with "to:" line missing

[Benny Pedersen]

On 2022-04-15 10:47, Bernardo Reino wrote:


Many e-mails are sent to "BCC" lists, so they have no To: header (or
have one with "undisclosed-recipients").


bcc does not remove or add to


So I'd be careful with rejecting/filtering only based on that.


spammers does not know all that details :=)

Re: spam emails with "to:" line missing

[Benny Pedersen]

On 2022-04-15 08:49, Fourhundred Thecat wrote:


I am receiving spam emails, where the "to:" line is entirely missing in
the email header.

The header has "X-Original-To:" and "Delivered-To:", but no "to:" line.

I have pasted the header here: https://ctxt.io/2/AABg30FRFQ

How could I block such emails? Can I use header-check for this?

Are there any legitimate cases where "to:" might be missing?


not really, i would like to see what "spamassassin -t spam.msg" gives at 
your install

Re: spam emails with "to:" line missing

[Jaroslaw Rafa]

Dnia 15.04.2022 o godz. 02:21:46 li...@lazygranch.com pisze:
> 
> The header doesn't look odd because the mailing list provides a TO
> field.

No, it doesn't. I don't see any "To:" field in the headers of Tinne11's
message. I do see a "Cc:" field, but not "To:".

And referring to the original questions about legit cases of e-mails without
"To:" field - if someone sends an email to multiple recipients that are
listed in the "Bcc:" field (as it is often done due to privacy), and does
not specify the "To:" field, this will be the case.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: spam emails with "to:" line missing

[Peter]

On 15/04/22 6:49 pm, Fourhundred Thecat wrote:

I am receiving spam emails, where the "to:" line is entirely missing in
the email header.

The header has "X-Original-To:" and "Delivered-To:", but no "to:" line.

I have pasted the header here: https://ctxt.io/2/AABg30FRFQ

How could I block such emails? Can I use header-check for this?


The short answer is you can't.  the long answer is that header_checks 
each header individually and compares them against your pcre file. 
Since a legitimate email will match several headers that don't start 
with To: you can't try to match that and reject the message accordingly.


In order to do it you will need a milter or content filter.


Are there any legitimate cases where "to:" might be missing?


It is possible, although rather unusual.  A message must have a 
recipient, but not necessarily specified in a To: header.  You're not 
likely to get much, if any legitimate mail with a missing To: header, 
though.



Peter

Re: Muliple mail delivery

[Wietse Venema]

Daniel Azuelos:
> [ R?dig? dans le sens de lecture normal.
>   Written in the usual reading direction. ]
> 
> Le (on) 23/03/2022, Homer Wilson Smith  a ?crit 
> (wrote):
> 
> [...]
> | Presently I got 3 drives rsyncing from the mail drive repeatedly through
> | out the day.  It works...
> 
> This looks like the best method to manage a backup of mailboxes partition.
> To avoid too heavy impact ( FS locking, and disk errors ) use a partition
> on a disk which isn't the one holding the mailboxes.

Or you could use Dovecot's replication
https://wiki.dovecot.org/Replication

Wietse

Re: Muliple mail delivery

[Daniel Azuelos]

[ Rédigé dans le sens de lecture normal.
  Written in the usual reading direction. ]

Le (on) 23/03/2022, Homer Wilson Smith  a écrit 
(wrote):

[...]
| Presently I got 3 drives rsyncing from the mail drive repeatedly through
| out the day.  It works...

This looks like the best method to manage a backup of mailboxes partition.
To avoid too heavy impact ( FS locking, and disk errors ) use a partition
on a disk which isn't the one holding the mailboxes.
-- 
« The only thing necessary for the triumph of evil
is for good men to do nothing. »
Edmund Burke

daniel Azuelos

Re: spam emails with "to:" line missing

[Bernardo Reino]

On Fri, 15 Apr 2022, li...@lazygranch.com wrote:


On Fri, 15 Apr 2022 11:06:35 +0200
Tinne11  wrote:




Am 15.04.2022 um 08:49 schrieb Fourhundred Thecat
<400the...@gmx.ch>:

Are there any legitimate cases where "to:" might be missing?



RFC 5322 says: "The only required header fields are the origination
date field and the originator address field(s).", i. e. the "Date:"
and the "From:" header field.



I have sent this answer without any address in the to header field.


The header doesn't look odd because the mailing list provides a TO
field. I'm fine if you want to send me an email without a TO field. I'd
like to look at the header.


I've just sent you an e-mail with no "To:" header.

Cheers.

Re: spam emails with "to:" line missing

[li...@lazygranch.com]

On Fri, 15 Apr 2022 11:06:35 +0200
Tinne11  wrote:

> 
> > Am 15.04.2022 um 08:49 schrieb Fourhundred Thecat
> > <400the...@gmx.ch>:
> > 
> > Are there any legitimate cases where "to:" might be missing?
> 
> 
> RFC 5322 says: "The only required header fields are the origination
> date field and the originator address field(s).", i. e. the "Date:"
> and the "From:" header field.
> 
> 
> 
> I have sent this answer without any address in the to header field.

The header doesn't look odd because the mailing list provides a TO
field. I'm fine if you want to send me an email without a TO field. I'd
like to look at the header.

Re: spam emails with "to:" line missing

[Tinne11]

> Am 15.04.2022 um 08:49 schrieb Fourhundred Thecat <400the...@gmx.ch>:
> 
> Are there any legitimate cases where "to:" might be missing?


RFC 5322 says: "The only required header fields are the origination date field 
and the originator address field(s).", i. e. the "Date:" and the "From:" header 
field.



I have sent this answer without any address in the to header field.

Re: spam emails with "to:" line missing

[Bernardo Reino]

On Fri, 15 Apr 2022, Fourhundred Thecat wrote:


I am receiving spam emails, where the "to:" line is entirely missing in
the email header.

[...]

Are there any legitimate cases where "to:" might be missing?


Many e-mails are sent to "BCC" lists, so they have no To: header (or have one 
with "undisclosed-recipients").


So I'd be careful with rejecting/filtering only based on that.

AW: spam emails with "to:" line missing

[Ludi Cree]

Hi,

not exactly what you ask for, but:

I think it is absolutely safe to block "From: Smart Invest" and "Subject: 
become rich" with PCRE rules in header checks.

Greets,
Ludi


-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org  Im 
Auftrag von Fourhundred Thecat
Gesendet: Freitag, 15. April 2022 08:49
An: Postfix users 
Betreff: spam emails with "to:" line missing

Hello,

I am receiving spam emails, where the "to:" line is entirely missing in the 
email header.

The header has "X-Original-To:" and "Delivered-To:", but no "to:" line.

I have pasted the header here: https://ctxt.io/2/AABg30FRFQ

How could I block such emails? Can I use header-check for this?

Are there any legitimate cases where "to:" might be missing?

spam emails with "to:" line missing

[Fourhundred Thecat]

Hello,

I am receiving spam emails, where the "to:" line is entirely missing in
the email header.

The header has "X-Original-To:" and "Delivered-To:", but no "to:" line.

I have pasted the header here: https://ctxt.io/2/AABg30FRFQ

How could I block such emails? Can I use header-check for this?

Are there any legitimate cases where "to:" might be missing?