[pfx] Re: Dovecot logging to files causes postfix to break

[Richard Rosner via Postfix-users]

On 19.05.24 18:06, Kim Sindalsen via Postfix-users wrote:

Can't open log file /var/log/dovecot/error.log: Permission denied )


Isn't this a filepermission-issue (ie. does the dovecot-user have permission
to write to the logfile)?

What is the permissions and user/group on the logfile - what user tries to
write to it (dovecot, dovenull or?...)?

As it turned out, everybody was forgetting, that in order for a non-root 
process to access files in a directory, it needs execute permissions on that 
directory. Those weren't granted.___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Dovecot logging to files causes postfix to break

[Richard Rosner via Postfix-users]

Am 19.05.24 um 14:06 schrieb John Fawcett via Postfix-users:



Hi Richard

though probably not relevant to your current issue, one thing to watch out for 
with the approach you are using is the value of postfix parameter postfix 
mailbox_size_limit. This value applies to all files written by the lda process 
that postfix spawns, not just the mailbox files, so also applies to log file 
sizes.

John


Thanks for the heads up, but I don't think it's relevant here. It's set to 0, 
so if I'm correct that should have turned the limitation off.


Richard

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Dovecot logging to files causes postfix to break

[Richard Rosner via Postfix-users]

Am 18.05.24 um 17:55 schrieb Wietse Venema:

Richard Rosner via Postfix-users:

I have a mailing server setup based on Debian Stable that uses
postfix for IMAP and SMTP and dovecot for internel mail handling,

You mean, Postfix for SMTP, Dovecot for IMAP.

Possible.



like filtering, sorting into users inboxes etc. I now wanted to
set dovecot to not write to syslog, but to dedicated files in
/var/log/dovecot. While everything indicates that this happens
successfully, postfix will soon start logging complaints:

 May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9:
 to=, relay=local, delay=3.2, delays=1.9/0.29/0/1.1,
 dsn=4.3.0, status=deferred (temporary failure. Command output:
 lda(user): Error: net_connect_unix(/run/dovecot/stats-writer)
 failed: Permission denied Can't open log file
 /var/log/dovecot/error.log: Permission denied )

That is a DOVECOT error message from the DOVECOT local delivery agent (lda).

Wietse


Why does it say postfix/local though? So you are sure this error can't have 
been caused by any interaction with postfix?


Richard

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Dovecot logging to files causes postfix to break

[Richard Rosner via Postfix-users]

I have a mailing server setup based on Debian Stable that uses postfix for IMAP 
and SMTP and dovecot for internel mail handling, like filtering, sorting into 
users inboxes etc. I now wanted to set dovecot to not write to syslog, but to 
dedicated files in /var/log/dovecot. While everything indicates that this 
happens successfully, postfix will soon start logging complaints:

   May 13 20:55:37 mail postfix/local[2824184]: 95BCF1000A9: 
to=, relay=local, delay=3.2, delays=1.9/0.29/0/1.1, dsn=4.3.0, 
status=deferred (temporary failure. Command output: lda(user): Error: 
net_connect_unix(/run/dovecot/stats-writer) failed: Permission denied Can't open log 
file /var/log/dovecot/error.log: Permission denied )

If it would only log the complaints I wouldn't worry, but as long as I don't 
revert the changes in dovecot's config, mail delivery is at least vastly 
delayed, most likely stuck alltogether. Now since dovecot does log to the files 
set up, my guess is that this is an issue with postfix. So the question is, why 
does postfix even try to access the log files dovecot uses? I haven't set 
postfix to log to them, in fact I don't see any settings as to where postfix 
will log to (I'm not the one that set up the server, I'm just maintaining it). 
Does anyone here know enough about how postfix and dovecot work together to 
figure out what the actual issue is and how to stop it from happening?


Best

Richard

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Don't BCC a particular domain

[Richard Raether via Postfix-users]

Should I take out thee always_bcc in main.cf? Would this solution also 
allow everything else to be BCC'd? Allsoo what would the line be if 
"lists" were not in the domain name. I'm not familliar with the syntax.


Excuse. my ignorance,

Richard

On 3/21/24 8:54 AM, Wietse Venema via Postfix-users wrote:

Richard Raether via Postfix-users:

We have an auditor account where all incoming and outgoing mail is BCC'd
to, to retain for compliance reasons. However, since mailman retains its
own archives, and we have a mailman on a separate server with a separate
domain, is there a way to tell postfix DO bcc everything EXCEPT DON'T
bcc anything from this particular domain? BTW, the other machine uses
our mail server as a relay, which might make a difference.

It is not possible with always_bcc (as the name suggests, it does
make any distinction).

It is possible if you use sender_bcc_maps and/or reciopient_bcc_maps.

Example for recipient_bcc_maps, to exclude BCC copies for recipients
that match anyth...@lists.example.com:

/etc/postfix/main.cf:
 recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc

/etc/postfix/recipient_bcc:
 # DO NOT indent text between the IF and ENDIF lines!
 IF !/@lists\.example\.com$/
 /./  ...auditor...
 ENDIF

Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Don't BCC a particular domain

[Richard Raether via Postfix-users]

We have an auditor account where all incoming and outgoing mail is BCC'd 
to, to retain for compliance reasons. However, since mailman retains its 
own archives, and we have a mailman on a separate server with a separate 
domain, is there a way to tell postfix DO bcc everything EXCEPT DON'T 
bcc anything from this particular domain? BTW, the other machine uses 
our mail server as a relay, which might make a difference.


Pardon my ignorance,

Richard Raether
Louisiana State University


___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Re: Using a second domain for outgoing mail

[Richard Raether via Postfix-users]

In addition, the boss just asked is there a way to restrict the group of 
users that can send from that second domain? We are using ldap for 
authentication. Please forgive any ignorance on my part.


On 12/19/23 10:22 AM, Noel Jones via Postfix-users wrote:

On 12/19/2023 9:41 AM, Richard Raether via Postfix-users wrote:

Problem:

Our mail server sends mail from cct.lsu.edu. A group of users want to 
send mail and have their address be stellar-group.org. We already 
have this in mydestination so we do /get/ email sent to that domain, 
but at current you can't send email /from/ that domain and have the 
address show up as that. Is there a way to do this in postfix?




Typically the sender information is set in the user's mail client. If 
they send mail with the new domain as sender, postfix shouldn't alter it.


It's possible for postfix to do the mapping using canonical_maps, but 
the first choice should be configuring the user's mail client.


If this isn't working as expected, please send logging demonstrating 
the problem, and your "postconf -Mf".




  -- Noel Jones
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] Using a second domain for outgoing mail

[Richard Raether via Postfix-users]

Problem:

Our mail server sends mail from cct.lsu.edu. A group of users want to 
send mail and have their address be stellar-group.org. We already have 
this in mydestination so we do /get/ email sent to that domain, but at 
current you can't send email /from/ that domain and have the address 
show up as that. Is there a way to do this in postfix?


Any advice would be appreciated.

Richard Raether
Sysadmin
Center for Computation and Technology
Louisiana State University
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

[pfx] No Postfix novice, but need novice-like advice (was Postfix or Dovecot cracked?!)

[Richard Troy via Postfix-users]

Hi All,

This is my first posting here, and maybe I should have found this WAY back 
in January, '23, if not LONG before. Surely background will help:


This 27 or so year old site now with Fedora / Postfix / Dovecot (with 
early adoption of all three) that I built was humming along just fine 
until a major disaster in January and I've not yet been able to fully 
recover because the Postfix / Dovecot pair has let the damned spammers in 
again and again and again and again!


OH, sure, I got it down to a trickle, but these few Russian sites always 
managed to get their spam through. I've never found out how they got in, 
but I'm sure they'd be back as soon as I reopen internet access on ports 
587 and / or 993.


I went through so much pain at trying to reconfigure, to no success (or 
incomplete success) that I've STRONGLY suspected that either Dovecot or 
Postfix got cracked - at least the modern version of January '23 on Fedora 
Server 37. (I haven't reopened the ports since the upgrade to 38.)


As soon as 38 became available, we upgraded. Current version(s) available 
upon request - and while the whole main.cf is HUGE and somewhat 
sensitive, bits of it are surely available, too.


In the disaster, we lost /var but not /etc, so I figured recovery would be easy 
and for nearly everything, it was. But while both Dovecot and Postfix came 
right back up with the old config files (and something of an effort to try 
and use the more modern, insofar as they're different), nothing I've tried 
so far has stopped the spammers from getting through, though as I say I 
haven't tried since the update to 38 - should I now? (No config has 
changed.)


Now, in these 5+ months I've tried so many things, I'm sure I've forgotten 
most of them and I don't know that a retrospective look is worth doing.


...I kept some notes that might be useful if anyone wants to see the evidence 
of the cracking, but in short, I kept a constant watch on the logs and when ANY 
relay happened that shouldn't, I'd instantly know it and shut things off 
entirely. However, that became untenable as I couldn't find the problem and had 
to just shut it off, pissing off users, etc, but I've had to do things like 
spend a month and a half traveling, and so forth and, well... Life goes on, as 
the saying goes.


---

Given all the work I did on Postfix to stop relaying from unauthorized 
parties, and how after a mountain of work the "open-mail-relaying" was 
only coming from a couple of spammers in Russia, it's my view they somehow 
cracked things, even though we changed 100% of ALL user passwords to VERY, 
and I mean completely impractical to crack values (30 chars plus). And so 
I want to blame Dovecot for letting through the relaying. They say no, 
it's Postfix!


Maybe someone on this list knows if it's possible that Dovecot being 
cracked can cause Postfix to become a spam relay but I'd like to sidestep 
that for at least the moment:


A new feature that would make a HUGE difference to sites like mine: Give 
me a white-list of the ONLY accounts (usernames) that can relay; NOTHING 
ELSE can relay. ... THAT would do it! But no! Neither in Postfix nor 
Dovecot is there such a thing! ...Such a thing CANNOT be that hard to 
implement and obviously useful to many; is there a good reason NOT to do 
this? Or am I wrong and it HAS been done?


Combine that with a greylist type function (similar to the postgrey 
package I have installed now) where the usual IP addresses for particular 
relay users were let through, and new ones delayed, THAT would be awesome, 
too! And this isn't even all that hard to do - I could do it if I didn't 
already have a thousand obligations in life!


And if someone tells me I'm wrong and points me at how to do these things, I'll 
fall out of my damned chair! And after picking myself up, I'll find a way to 
send that person some sort of gift. THIS WOULD HAVE SOLVED ALL MY PROBLEMS. And 
I'm sure MANY others could use this, too!


As a small digression on some of the above: I think I don't know enough 
about how Postfix's use of port 587 is properly secured - the "submission 
port". OK, STARTTLS we're told, but is it Postfix or Dovecot doing the 
authentication? Does Postfix EVER read a password file? I think it does 
not, and so I say it has to be Dovecot, but some clearing up of that would 
be nice... And, now that I think of it could this be a way to prove which 
is guilty of letting the spammers in?


---

I MUST get Dovecot's use of the ports 587 / 993 working again to allow my 
outside users to get email again, but HOW THE HELL DO I DO THIS and NOT 
let the spammers in?!


Thanks for any and all help,
Richard

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

emails with s9b1.psmtp.com

[Richard Raether]

Dear users wiser than me (probably everyone),

We have a legitimate domain, einsteintoolkit.org, but I'm getting mail 
for einsteintoolkit.org.s9b1.psmtp.com, which postfix doesn't allow 
through because it doesn't recognize it as a legitimate domain. What am 
I misunderstanding about psmtp and how it works, and does anyone know 
how I can get these emails properly delivered?


Any advice is welcome.

Thanks,

Richard Raether
Sysadmin
Center for Computation and Technology
Louisiana State University

Re: AW: mysql phpwebadmin

[Richard]

> Date: Thursday, May 26, 2022 16:14:53 +0200
> From: Maurizio Caloro 
>
>> Then why are you asking a non-Postfix question?
> 
> Because here I get a useful little possible hint quickly
> 

It's not clear whether you are referring to "phpwebadmin", as
referenced in your subject line (a product that seems to have been
last updated some years ago), or "phpmyadmin" as implied by the
client version number you refer to in the body of your message ...
but assuming the latter:

   

If something else, there are handy things like search engines which
should help you locate the correct place for your query.

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Op 12-04-22 om 14:20 schreef Jaroslaw Rafa:

Dnia 12.04.2022 o godz. 14:07:13 Richard Rasker pisze:

But according to the information supplied, I should also be able to
use smtp.xs4all.nl as a relay host, see
https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already
took care of the Spamhaus delisting).

Question: does this solve the PTR record problem?

Probably not, because smtp.xs4all.nl has IP address 195.121.65.191, and
reverse DNS for 195.121.65.191 is 195-121-65-191.dc.kpn.net. So it is also a
"generic" hostname which may cause some systems to reject mail sent from
this address. The ISP has configured it wrong; 195.121.65.191 should resolve
back to smtp.xs4all.nl.


Yes, I figured as much already ... Bit of a shame, really, because 
originally, XS4All used to be one of the very best ISP's worldwide, in 
regard to both technology as well as customer choice and customer 
service -- and I happily paid their rather steep subscription fees in 
order to have full control over what I could and couldn't do with my 
Internet connection.


After being taken over by KPN, all this seems to have gone down the 
drain, with only the high cost remaining. Apparently, this ISP doesn't 
want any 'difficult' customers doing things such as running their own 
servers and the likes.



For sending e-mail, you don't need to change the MX record.

And how does reverse DNS work in this case?

There is no reverse DNS issue for sending mail. Usually nobody is checking
reverse DNS for the hosts they send mail *to*.
Reverse DNS is checked in case of hosts one receives mail *from*.


Sorry, I wasn't being clear here. What I mean to ask is if (and how) 
using a mail relay for sending mail could solve the problem that at the 
receiving end, reverse DNS does not match the originating domain.



(And unfortunately, switching to freedom.nl as a new ISP has one
drawback wrt. VOIP -- I can only keep one of our current two phone
lines.)

Why is this? Is your ISP also your VoIP provider?


Yes (although this is way off-topic here). ISP's here offer a package 
deal with Internet, TV, and at least one phone line for what used to be 
a 'land line'.



I use a VoIP provider that is independent from my ISP and I have set up two
phone lines in my VoIP router. For one line, SIP is listening on port 5060,
and for the other on port 5061. Both lines register with their appropriate
credentials to VoIP provider's SIP server (my VoIP provider is using
separate login & password for each phone line). This setup will work for
any ISP as long as ISP isn't blocking inbound UDP ports 5060/5061.


Perhaps I could do something like that, but then I'd have to spend more 
time on that as well. The whole point is that I had everything working 
perfectly fine, but that my current ISP demolished essential 
functionality without offering any solutions or alternatives.


So I'm still trying to figure out what my best option is -- and a better 
understanding of the whole mail server/relay thing is important, which 
is why I'm asking here :-)

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Op 11-04-22 om 18:34 schreef Paul van der Vlis:
Hi Richard, 
...


Eventually you could use my mailserver as a relayhost. 


That is a very friendly offer, but if I do, that would of course only 
be temporary, so that I can send e-mail again, and I'd contact you in 
advance.


You need a username and password.


That's of course why I would contact you first :-)

But according to the information supplied, I should also be able to use 
smtp.xs4all.nl as a relay host, see 
https://www.xs4all.nl/eigenmailserver/ (in Dutch -- and I already took 
care of the Spamhaus delisting).


Question: does this solve the PTR record problem?

Just to make sure: I guess I need to change my MX record for this to 
work? 


For sending e-mail, you don't need to change the MX record.


And how does reverse DNS work in this case? Sorry if I ask beginners' 
questions, but as I said, I never had to get into these details of mail 
servers and anti-spam measures -- up until yesterday, it 'Just Worked'.


(And unfortunately, switching to freedom.nl as a new ISP has one 
drawback wrt. VOIP -- I can only keep one of our current two phone lines.)



But maybe you need to change the SPF settings, if you have them.


Best regards,

Richard

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Hi Paul,

Op 11-04-22 om 17:40 schreef Paul van der Vlis:


[snip]

Maybe switch to freedom.nl, they give you a good reverse DNS.
Also IPv6.


Thanks for the tip; I think that may be a good idea. They're a lot 
cheaper as well than XS4All/KPN -- I think I'll contact them first thing 
tomorrow morning to verify if they can indeed provide the services I was 
used to.




Eventually you could use my mailserver as a relayhost. 


That is a very friendly offer, but if I do, that would of course only be 
temporary, so that I can send e-mail again, and I'd contact you in advance.


Just to make sure: I guess I need to change my MX record for this to 
work? As I mentioned before, I'm not very proficient in mail server 
administration, mostly because Postfix, once it's up and running, Just 
Works -- for years on end.


Thanks once again, also to all the others who took time to reply,

Best regards,

Richard

Re: Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Hello Matus, and others,

Op 11-04-22 om 16:17 schreef Matus UHLAR - fantomas:

On 11.04.22 15:38, Richard Rasker wrote:

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a 
correct PTR record pointing to mail.linetec.nl, causing a lot of 
ISP's to reject e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?


this will not help your problem. many ISPs will reject not because 
helo name but because of your reverse DNS format.


ask your ISP to change reverse DNS for your IP to mail.linetec.nl when 
possible.

if not possible, you'll need external smtp server, or different ISP.


Thank you for your swift answers!

Unfortunately, my new ISP says they can only do that for business 
accounts, which would cost me several dozen euros extra per month. I'm 
pretty angry about this, because I explicitly chose my previous ISP 
(XS4All) for their excellent technical features & support -- and they 
did not warn me that their take-over by the current ISP (KPN) could have 
consequences like this.


After contacting the helpdesk (30 minutes waiting ...), I was told that 
I could configure Postfix to use a mail relay of the previous ISP, 
changing my MX record accordingly (smtp.xs4all.nl), but that doesn't 
appear to work properly either. But maybe I did something wrong -- I 
have no experience with relay servers yet.


This is what I added to my main.cfg, based on what I found on the Internet:

relayhost = smtp.xs4all.nl

... [further down]

#Enable Authentication
 smtp_sasl_auth_enable = yes
#Set Username and Password
 smtp_sasl_password_maps = static:Chosen-Username:Chosen-Password
 smtp_sasl_security_options = noanonymous
#Enable TLS Encryption
 smtp_tls_security_level = encrypt
 header_size_limit = 4096000
#Enable CA Certificates
 smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

When restarting Postfix, no mail at all seems to be getting through any 
more -- and how should this solve the reverse DNS problem? Because 
smtp.xs4all.nl has IP address 195.121.65.191, but this IP address again 
does not point back to smtp.xs4all.nl ...


I then tried the same with mx.kpnmail.nl -- which is a mail host of my 
current ISP, which indeed has a valid PTR record, but still no mail 
appears to get through. So in order to post here, I changed things back 
for the time being. Perhaps I made a mistake in main.cf?


Thanks again, best regards,

Richard

Solving reverse DNS problem with Postfix configuration?

[Richard Rasker]

Hello,

I've been using Postfix for many years without significant problems.

However, due to a forced change in ISP, I can no longer have a correct 
PTR record pointing to mail.linetec.nl, causing a lot of ISP's to reject 
e-mail from my server.


Reverse DNS for my IP address now points to the ISP's generic name 
77-172-184-9.fixed.kpn.net


Could I solve this by setting smtp_helo_name in main.cf to 
77-172-184-9.fixed.kpn.net ? Or is this a bad idea?


Thanks for any suggestions,

Best regards,

Richard

Re: Can i run postfix on my home IP

[Richard]

> Date: Thursday, January 13, 2022 11:00:45 +0800
> From: Yamadaえりな 
> 
> I have got a DSL from the ISP, having a static IP.
> Can I run postfix with this IP for accepting email for my own
> domain?
> 

The quick answer is that it depends on whether your ISP has port 25
open (both in an outbound). With consumer-grade connectivity it's
generally not, so the type of connectivity that you have will impact
this. Your terms of service may also legally preclude this, but
that's an issue to be considered elsewhere.

Re: https://www.postfix.org/ in trouble

[Richard]

> Date: Tuesday, January 11, 2022 19:38:05 +0100
> From: "Claus R. Wickinghoff" 
> 
>> Today I find only a directory listing at www.postfix.org or
>> www.postfix.com
> With http it's working.
> 
> With https I get a certificate warning (issued for
> archive.science.uu.nl) and a directory listing.
> 
> So might be a regional problem?
> 

See the list archive for a discussion of this earlier this month,
specifically:
  
   

Nothing is broken, https just isn't supported.

Re: delete from hold queue

[richard lucassen]

On Fri, 5 Nov 2021 21:03:34 -0400
Viktor Dukhovni  wrote:

> > I have run the jq script for a week or so ($days = 5) and it works
> > like a charm :-)
> 
> You're welcome.  Of course if the number of days will never vary in
> your case, it would be simpler to just hard-code the number into the
> jq script:

[..]

I did hardcode the number of days in the script. If ever I want to
change the number of days (probably never): it's a oneliner :-)

Thnx!

-- 
richard lucassen
http://contact.xaq.nl/

Re: delete from hold queue

[richard lucassen]

On Fri, 29 Oct 2021 00:24:36 -0400
Viktor Dukhovni  wrote:

> On Thu, Oct 28, 2021 at 10:14:15PM -0400, Viktor Dukhovni wrote:
> 
> > postqueue -j | jq -nr --argjson $days '
> 
> Correction, that first line should be:
> 
>   postqueue -j | jq -nr --argjson days $days '
> 
> Setting the "jq" variabe "$days" to the shell variable "$days".
> 
> The rest is unchanged:
> 
> >   (now - 86400 * $days) as $too_old
> > | inputs
> > | select(.queue_name == "hold" and .arrival_time  <
> > | $too_old) .queue_id
> > | select(test("^\\w+$")) # permit only valid queue-id
> > | syntax
> > ' |
> > postsuper -d - hold

Viktor,

I have run the jq script for a week or so ($days = 5) and it works like
a charm :-)

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: delete from hold queue

[richard lucassen]

On Fri, 29 Oct 2021 00:24:36 -0400
Viktor Dukhovni  wrote:

> On Thu, Oct 28, 2021 at 10:14:15PM -0400, Viktor Dukhovni wrote:
> 
> > postqueue -j | jq -nr --argjson $days '
> 
> Correction, that first line should be:
> 
>   postqueue -j | jq -nr --argjson days $days '
> 
> Setting the "jq" variabe "$days" to the shell variable "$days".
> 
> The rest is unchanged:
> 
> >   (now - 86400 * $days) as $too_old
> > | inputs
> > | select(.queue_name == "hold" and .arrival_time  <
> > | $too_old) .queue_id
> > | select(test("^\\w+$")) # permit only valid queue-id
> > | syntax
> > ' |
> > postsuper -d - hold

Thnx Viktor! Dominic's shell script already put me on the jq path, as
I did not know the "-j" JSON output either. The jq-only is the way to
handle this IMHO.

Thnx everyone here!

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: delete from hold queue

[richard lucassen]

On Thu, 28 Oct 2021 12:01:35 +0100
Dominic Raferd  wrote:

> I attach a script that can do it.

Thnx, but I did not ask to write one, I'm just too lazy to reinvent the
wheel :)

I will put it to the test anyway :)

-- 
richard lucassen
http://contact.xaq.nl/

Re: delete from hold queue

[richard lucassen]

On Thu, 28 Oct 2021 12:26:31 +0200
Matus UHLAR - fantomas  wrote:

> >Why do you have _any_ messages in the hold queue?  Don't do that!
> 
> kind of quarantine I guess.

Yep. Most of these messages are bank phishing mails BTW, I delete the
hold queue once a day. But never mind, was just wondering if anybody
had written such a script.

-- 
richard lucassen
http://contact.xaq.nl/

delete from hold queue

[richard lucassen]

Hello list,

Anyone here who wrote a shell script that deletes messages older than X
days from the hold queue?

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: I got an email from "myself?" what the heck!

[Richard Salts]

On 25/10/2021 4:11 pm, Thomas Anderson wrote:

The IP it came from was outside my network.

I think it's just a spoofing email. I had not actually seen on, so 
that raised my alarm, but I think it's ok. I need to go through and 
make sure my SFP and DMARC are sound. I just checked my DKIM couple 
days ago, so that's good.


Keep in mind that even with SPF, DKIM and DMARC in place there is still 
the possibility of legitimate emails that your users have sent coming 
back to you and being unable to authenticate them as such.


For example a user is a member of a mailing list that receiving a copy 
of their post where the mailing list has altered the body or a header 
which you've signed (the postfix mailing list takes pains not to damage 
DKIM signatures but does use the longstanding convention of adding a 
"Sender" header with the list address. If you were to sign an existing 
"Sender" header or sign the non-existence of the "Sender" header then 
the original DKIM signature would break even here. Other mailing lists 
are much worse, breaking the body with a footer and/or tagging the 
subject with the list name)


The converse is also true in some cases, that a message can appear as a 
valid DKIM signed message from an authorized source while being 
malicious. There are certain things to watch out for as covered in 
https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html 
which lets an unauthorized 3rd party take a previous email from a 
particular sender and convince many DKIM validators that it's legitimate 
on that basis while also adding their own payload which gets displayed 
to the recipient.





Thanks for the replies.

On 10/25/21 4:59 AM, post...@ptld.com wrote:
My concern is that the email APPEARED to come from me! I was listed 
as the sender.


Any email server can send any email claiming to come from anyone. 
DKIM Signatures and SPF records working together with DMARC provides 
a way to verify if a sending email server is authorized to send an 
email on behalf of the address used. If your server is not using, 
checking and validating DMARC then anyone can easily send you or send 
someone else an email claiming to be from you. Doesn't mean they 
compromised or got inside of your system or account. They just 
slapped your name on the "outside of the envelope".


Was the connecting client server IP your servers IP? The IP of the 
connecting client in the logs is who really sent the message, not the 
arbitrary email address slapped in the Envelope-From, From header or 
Sender header.

Re: Clarify reject_* for smtpd_helo_restrictions

[Richard]

> Date: Wednesday, July 07, 2021 16:54:42 -0400
> From: post...@ptld.com
> 
> I did read the manual which says:
> "Reject the request when the HELO or EHLO hostname has no DNS A or
> MX record."
> 
> Best to my knowledge "DNS A" means IP so the manual does mention IP
> addresses, but then it doesn't say anything about if or what it
> does with that IP so i just wanted to clarify and not assume.


If the "hostname has no DNS A ... record", i.e., the *hostname*
presented on the HELO/EHLO doesn't resolve, then no IPnumber will be
returned [to do anything with].

Re: Search for free MX Backup Service

[Richard Salts]

On 2/07/2021 3:54 pm, Maurizio Caloro wrote:


Hello

Searching any Service that offer free any possible MX Backup?

Why do you need a backup MX? Usually MSAs will queue for a while (4 days 
seems a common default due to language in the smtp RFCs) or the senders 
will get a bounce notice. If you have different policies on your primary 
MX and the backup then the backup will often just become a backdoor for 
spammers looking to bypass any measures you may have in place, 
especially when it's a free one size fits all service where you don't 
control much of anything.




Found kisolabs “dot” com but it seems this service are down

Thanks for possible update or help

Regards

Mauri

Re: Unwanted disclosure of email addresses

[Richard Damon]

On 5/17/21 8:00 AM, Magnus Harlander wrote:
> Hi,
>
> have you ever got an email containing lots of email addresses
> including your
> own in the TO or CC field or somewhere else in the mail body?
>
> I think, this happens for different reasons:
>
> - people sending emails to many recipients don't know or don't care
> how to do that
>   properly
> - people dont' know abount BCC
> - people forgot to use BCC instead of CC
> - email/calendar programs like outlook/exchange send invitations without
>   the senders interaction including all invitees in the to/cc as well
>   as in the text/calendar mime-body part containung an icalendar event
> - people replying to all header recipients after receiving such mails
>
> I don't like that and have thought about a solution:
> ...
> Is this really a good idea?
>
> \Magnus

I think the biggest problem with your solution is that sometimes it
really isn't a 'problem' and is the right answer. It might be desirable
to let the group be able to 'Reply-All' to the message to discuss some
things related to it.

This means breaking it at the server level has REALLY broken it. You
don't want to prohibit at the server level things that you might want to
allow in some cases. This might make a great feature at the MDA level,
where it pops up a warning that the visable recipient list is long, and
ask if you want to make it a BCC: list instead, but enforcing this
breaks some workflows.

Unless you really want to prohibit that activity, you can't do it at the
server level.

-- 
Richard Damon

Re: Certificate Postfix.org missing?

[Richard Damon]

On 4/23/21 9:26 AM, Jaroslaw Rafa wrote:
>
> All these emails can - and usually do - perfectly pass SPF/DMARC check. So
> it is a huge mistake to treat SPF/DMARC as an anti-spam measure and a
> positive SPF/DMARC check as an indicator that the message is not spam. It
> has nothing to do with the message being spam/non-spam.

My comment to this is that yes, if they setup their system to pass
SPF/DMARC, then it will pass that test. But then you can use classic
reputation of domain to decide that this is likely some unknown spammer,
and maybe even after a bit (since it has SOME cost to setup the domains,
they will tend to reuse them) you can be sure those messages are spam.
It also says that user side 'block' lists become usable again, as every
message won't have a totally new domain.

Yes, positive SPF/DMARC check by itself doesn't mean a lot, just that it
allows other tests to means something.

-- 
Richard Damon

Re: Certificate Postfix.org missing?

[Richard]

> Date: Thursday, April 22, 2021 19:26:57 +0200
> From: Claus Assmann 
>
> On Thu, Apr 22, 2021, John Levine wrote:
>> Nope, vanilla install on MacOS.
> Not sure what your "vanilla install" is...
> 
> Firefox 88.0 on MacOS:
> www.postfix.org
> and
> http://www.postfix.org/
> show the web page just fine without a problem.
> 
> It would be nice if the people who write browsers don't try to force
> their kind of "standards" on others... ("but you can get a free
> cert" -- what happens when those browsers do not "accept" those
> free certs anymore?)

The interaction one gets with firefox with a non-https site depends
on how one has set the "HTTPS-Only Mode" options at the bottom of the
privacy & security preferences. With it enabled I get a warning, but
can select to continue to the HTTP site. With it off I connect
without any warnings, but the lock in the URL bar has a line through
it.

Re: openssl error [solved]

[richard lucassen]

On Tue, 13 Apr 2021 20:36:45 +1200
Peter  wrote:

> > Yes, but why 1 minute ok, 1 minute errors, 1 minute ok, etc etc?
> 
> What's the TTL on the dkim TXT DNS record?

Got it: the signing server consists of two servers and the keypair
for one of the domains was not in sync. I think I created the keypair
using clusterssh instead of creating the keypair on the master server
and run an rsync. The round robin TTL of these two servers is 60
seconds which explains everything.

And I was mislead by the logs complaining about "invalid padding"
instead of "bad signature".

Sorry for the noise...

R.

-- 
richard lucassen
http://contact.xaq.nl/

Re: openssl error

[richard lucassen]

On Tue, 13 Apr 2021 20:36:45 +1200
Peter  wrote:

> > Yes, but why 1 minute ok, 1 minute errors, 1 minute ok, etc etc?
> 
> What's the TTL on the dkim TXT DNS record?

As I said: 3600 sec...

-- 
richard lucassen
http://contact.xaq.nl/

Re: openssl error

[richard lucassen]

On Tue, 13 Apr 2021 00:16:42 -0400
Viktor Dukhovni  wrote:

> On Mon, Apr 12, 2021 at 07:23:50PM +0200, richard lucassen wrote:
> 
> > mail.info: Apr 12 18:01:16 opendkim[13977]: 828FE7F581: s=202103
> > d=example.com SSL error:0407008A:rsa
> > routines:RSA_padding_check_PKCS1_type_1:invalid padding; error:
> > 04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed
> 
> An RSA signature is either slightly garbled, or is being verified with
> the wrong key (not the one that did the signing).  The validator
> detects a PKCS#1 padding error after decrypting with the public key.
> 
> I'm inclined to guess wrong key, but minor corruption in the signature
> value that preserves the overall length is also possible.

Yes, but why 1 minute ok, 1 minute errors, 1 minute ok, etc etc?

-- 
richard lucassen
http://contact.xaq.nl/

openssl error

[richard lucassen]

Probably OT here, but sometimes I get this error (Debian Buster,
original packages):

mail.info: Apr 12 18:01:16 opendkim[13977]: 828FE7F581: s=202103
d=example.com SSL error:0407008A:rsa
routines:RSA_padding_check_PKCS1_type_1:invalid padding; error:
04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed

I noticed that sometimes the DKIM was ok and sometimes it ended up
in the above mentioned error. After some testing I created a loop to
send 2000 mails each second:

for i in $(seq 1 2000) ; do echo -e "this is a test" | \
  mail -s "test ${i}" u...@example.com; sleep 1 ; done

minute 1: the DKIM is OK
minute 2: errors,
minute 3: the DKIM is OK
minute 4: errors,
minute 5: the DKIM is OK
minute 6: errors,
minute 7: the DKIM is OK
minute 8: errors,
etc etc

I have really no idea where to start searching. It is perhaps a opendkim
or an openssl issue. Or maybe some cache somewhere? DNS is ok, TTL of
DKIM record is 3600. Haystack, needle, but I need to find the haystack
first.

Anyone a hint?

R. 

-- 
richard lucassen
http://contact.xaq.nl/

Re: Port 25 Throttling?

[Richard James Salts]

On Monday, 29 March 2021 9:34:13 AM AEDT Wietse Venema wrote:
...
> Third, look with mtr at the latency pattern. If part of your traffic
> goes over a satellite, of if it is tunneled to some far-away country,
> then you will see a big jump. Unfortunately, mtr does not support
> tcp so you can't do 'mtr for port 25'.
mtr supports tcp syn based probes these days.

mtr --tcp -P 25 destination_host

should do the trick

> 
> That's just a few off the top of my head.
> 
>   Wietse

Re: What is the right way to update a postfix sqlite database?

[Richard Damon]

On 2/23/21 2:18 PM, Wietse Venema wrote:
> Ron Garret:
>>> If we take this route, then there needs to be a new field in the
>>> Postfix sqlite config file that controls the time limit.
>> Not necessarily.  You could just hard-code a reasonable value (like
>> 1 second), or make it a #define so you need a recompile to change
>> it.  That?s sub-optimal, obviously, but still a major improvement
>> over the current situation for very little effort and no down-side
>> that I can see.
> The limit should be configurable. It takes:
>
> - one line of code to define a C variable, 
>
> - one line of code to read its value from an sqlite_table configuration
>   file (or to use a documented default value),
>
> - a few lines of text to document the new field in the sqlite_table manpage.
>
>   Wietse

One thng to look at is WAL mode. WAL mode increases the cost of writes
to the database, as all writes become two stage, first to the WAL
journal, and then flushed to the main database (called A checkpoint),
and reads reads can get a bit more expensive if the second stage of the
write gets delayed by long accesses (but that may not be an issue with
postfix).

In exchange, the database allows for simultaneous reads and writes,
except possibly for the period when the second phase of the writes are
occurring, and it will try to allow as much overlap there as possible,
and try to find a time when no readers are active to do this operation.

Without a busy timeout being set, the reader should only get a busy in
fairly rare conditions, the main one being if the last connection to the
database is closing, then SQLite does some cleanup that locks the
database for just a little bit, or if the last connection 'crashes' than
the next connection will do some cleanup. Even a fairly short busy wait
should handle these cases most of the time.

-- 
Richard Damon

Re: spamassassin & bayes

[Richard]

> Date: Wednesday, January 27, 2021 19:17:48 -0300
> From: Daniel Armando Rodriguez 
>
> Hi
> 
> Suddenly I'm facing tons of this messages
> 
> ... bayes: cannot open bayes databases
> /home/spamd/.spamassassin/bayes_* R/W: lock failed: File exists
> 
> A 'solution' found on the web says disable bayes, reload SA, delete
> such files and enable bayes again.
> 
> Increased values in
> 
> default_process_limit
> 
> smtpd_recipient_limit
> 
> qmgr_message_active_limit
> qmgr_message_recipient_limit
> 
> Add
> 
> disable_dns_lookups = yes
> 
> However messages got delivered only if I disable bayes, after a
> while
> 

This issue has been a discussion thread on the spamassassin mailing
list of late. You may want to look at that mailing list's archive:

  

to see if that helps. You may also want to take your question there
where it's more relevant (not that people on this list can't help
too).

Re: Spam relay problems - need some config assistance

[Richard]

> Date: Sunday, January 24, 2021 15:57:18 -0600
> From: "P. Ik." 
>
>> On Sun, Jan 24, 2021 at 9:05 AM Matus UHLAR - fantomas
>>  wrote:
>> 
>> 
>> example could explain much.
>> 
>> > postconf -n returns:
>> 
>> > mynetworks_style = subnet
>> 
>> > smtpd_relay_restrictions = permit_mynetworks,
>> > reject_unauth_destination
>> 
>> this says you only relay mail from your network.
>> something on your network (or machine) may inject mail to postfix,
>> which then relays it.
>> 
>
> Thanks for the reply Matus, another user also asked for similar. As
> I told them as well, I wasn't sure if based on what I was trying to
> accomplish someone would see a clear error in my config.
> 
> I have the mail server shut down until I fix this, I dug out some
> examples here, I appreciate your assistance!
>
> Dec 26 00:48:30 mail postfix/qmgr[108]: E25E85DA:
> from=, size=341, nrcpt=1 (queue active)
> Dec 26 00:48:30 mail postfix/smtpd[2146]: disconnect from
> unknown[172.17.0.1] ehlo=1 mail=1 rcpt=1 data=1 rset=1 quit=1
> commands=6 

What is at 172.17.0.1. That is where all your examples seem to
originate from, and as that's part of a non-routable range it's going
to be local to your network. 

[please don't top post as it makes things hard to follow.]

Re: refused mail/host not found -- confusion about error source

[Richard]

> Date: Thursday, January 21, 2021 15:24:10 +0100
> From: "Herbert J. Skuhra" 
>
> On Thu, Jan 21, 2021 at 03:15:24PM +0100, Jeff Abrahamson wrote:
>> I've been seeing this error for this one host.  My first reaction
>> was that the host was incorrectly configured, but the IP
>> (92.103.176.37) reverse resolves to mail.mairie-carquefou.fr,
>> which in turn resolves to that IP.  In addition, the MX for
>> mairie-carquefou.fr is mail.mairie-carquefou.fr (and
>> mx3.mail.ovh.net).  So I'm not really sure what the "host not
>> found" is complaining about.
>> 
>> Jan 21 15:05:28 nantes-1 postfix/smtpd[6367]: connect from
>> mail.mairie-carquefou.fr[92.103.176.37]
>> Jan 21 15:05:29 nantes-1 postfix/smtpd[6367]: Anonymous TLS
>> connection established from
>> mail.mairie-carquefou.fr[92.103.176.37]: TLSv1 with cipher
>> ECDHE-RSA-AES256-SHA (256/256 bits)
>> Jan 21 15:05:29 nantes-1 postfix/smtpd[6367]: NOQUEUE: reject:
>> RCPT from mail.mairie-carquefou.fr[92.103.176.37]: 450 4.7.1
>> : Helo command rejected: Host not
>> found; from=
>> to= proto=ESMTP
>> helo=
>> Jan 21 15:05:29 nantes-1 postfix/smtpd[6367]: disconnect from
>> mail.mairie-carquefou.fr[92.103.176.37] ehlo=2 starttls=1 mail=1
>> rcpt=0/1 quit=1 commands=5/6
>> 
>> (I'm a bit confused about the SERVDMZMAIL in the helo.  That host
>> does appear not to exist.)
>> 
>> Any suggestions what to look at / if I've likely misconfigured
>> something?
> 
> http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions
> 
> reject_unknown_helo_hostname (with Postfix < 2.3:
> reject_unknown_hostname) Reject the request when the HELO or
> EHLO hostname has no DNS A or MX record.

... and your HELO is from:

   450 4.7.1 : 
   Helo command rejected: Host not found;

which doesn't appear to resolve.

Re: adding AV scanning to working Postfix/SA system

[Richard Siddall]

michael Schumacher wrote:

Joe,


Due to some recent malware (in attachments, obvious stuff) wanted to add AV scanning.   I 
gather "Amavis-new" is the hot ticket these days,
I deal with Sophos products and would like to use their linux product to do the 
scanning.   Seems to be precious little on how to do that.


I am using amavis with clamav. Sorry, no additional commercial virus scanners, 
but I noticed that amavis.conf contains setups for a lot of commercial virus 
scanners. May be worth a look.

Michael




FWIW, I was going to say my impression is amavis-new was the hot ticket 
several years ago, but is losing market share to rspamd. 
https://rspamd.com/doc/modules/external_services.html says rspamd has 
been tested with Sophos (via SAVDI).  My amavisd.conf says it works with 
Sophie (unmaintained since 2004), Sophos SAVE via SAVI-Perl 
(https://metacpan.org/release/SAVI-Perl from 2005), and as a last resort 
Sophos sweep.

Re: empty message-ID

[Richard Damon]

On 11/24/20 1:51 AM, Bob Proulx wrote:
> @lbutlr wrote:
>> On 23 Nov 2020, at 15:27, Jaroslaw Rafa  wrote:
>>> Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
>>>> If someone replies to a mailing list and copies the sender then that
>>>> person gets two copies.  The above recipe avoids that.
>>> Moreover, it breaks the continuity of threads on mailing lists, because it's
>>> unpredictable which copy will arrive first, and if only the direct copy is
>>> left, the reply will go only to the sender and not to the mailing list. Thus
>>> some messages are missing from lists.
>> This is not accurate. First, the direct message almost certainly
>> arrives first. Second of all, that message still has headers
>> indicating it was sent to the mailing list.
> That is not accurate.  The direct message never went through the
> mailing list.  The direct copy is missing the mailing list headers.
> For this list the direct copy is missing these headers.
>  
> Sender: owner-postfix-us...@postfix.org
> Precedence: bulk
> List-Id: Postfix users 
> List-Post: <mailto:postfix-users@postfix.org>
> List-Help: <http://www.postfix.org/lists.html>
> List-Unsubscribe: <mailto:majord...@postfix.org>
> List-Subscribe: <mailto:majord...@postfix.org>
>
> The most important of those are List-Id and List-Post without which
> the message will not be filed correctly and most mailers will not be
> able to list reply correctly.  This puts the onus upon the receiver to
> manually take corrective action with the message.  That is something
> that I and probably most readers of this list can do.  But for most
> random people today they do not understand email and most people today
> do not have the skill to do this correctly.  For them it is simply
> completely broken.

Slight details, those headers indicate that it is FROM the mailing list,
the direct message will still have the To: or Cc: header indicating that
it was TO the mailing list.

That says that a Reply-All will still go to the list (and send a direct
copy back to the person who sent this to you, which might be what they
want).

How the message get filed will depend on how you have your filters setup
for the messages, and the difference is perhaps useful. After all, a
reply to your posting might be considered of higher importance than just
a run of the mill posting to the list, so not filing it the same might
be correct.

One way to make a personal reply less likely would be for you to add a
Reply-To: header pointing to the list submission address, that way if
someone is using a MUA that doesn't support the 'Reply-To-List' function
and does a Reply-All, it is likely that it will redirect the reply to
the list. (More broken MUAs might still send you a copy, if the ignore
or mishandle Reply-All.)

-- 
Richard Damon

Re: empty message-ID

[Richard Damon]

On 11/23/20 5:27 PM, Jaroslaw Rafa wrote:
> Dnia 23.11.2020 o godz. 11:49:39 D'Arcy Cain pisze:
>> If someone replies to a mailing list and copies the sender then that
>> person gets two copies.  The above recipe avoids that.
> If someone gets two copies - a direct one and the mailing list one - then
> he/she knows that the sender has replied both to author and to the list and
> can instruct the sender not to do it. With the above recipe, the recipient
> doesn't even know about that.
>
> Moreover, it breaks the continuity of threads on mailing lists, because it's
> unpredictable which copy will arrive first, and if only the direct copy is
> left, the reply will go only to the sender and not to the mailing list. Thus
> some messages are missing from lists.

You CAN still reply to the list from the private copy, you won't have a
'Reply-to-List' opiton, because of the lack of list headers, but
'Reply-All' will still work.

It just becomes a bit harder to reply back JUST to the list. Your need
Reply-All and then editing the list of recipients.



-- 
Richard Damon

Re: empty message-ID

[Richard Damon]

On 11/23/20 3:34 PM, Erwan David wrote:
> Le 23/11/2020 à 20:16, @lbutlr a écrit :
>> On 23 Nov 2020, at 06:49, maciejm  wrote:
>>> "RFC 822 Message-ID is not required"
>> RFC 822 has been obsoleted several times. 
>>
>> RFC 5322 states:
>>
>>Though listed as optional in the table in section 3.6, every message
>>SHOULD have a "Message-ID:" field.  Furthermore, reply messages
>>SHOULD have "In-Reply-To:" and "References:" fields as appropriate
>>and as described below.
>>
>> And:
>>
>> RFC 2119
>> SHOULD   This word, or the adjective "RECOMMENDED", mean that there
>>  may exist valid reasons in particular circumstances to ignore a
>>  particular item, but the full implications must be understood and
>>  carefully weighed before choosing a different course.
>>
>> So SHOULD is much stronger than "it's a good idea" and much more like "You 
>> better have a really good reason for ignoring this".
>>
>> I would feel comfortable rejecting messages without a Message-ID.
>>
> Maybe on smtp, but not on submission. FOr me policy there is completeley
> different

I thought one strategy to handle this was that submission would detect
lack of the message-id header and add one with a proper message-id.

-- 
Richard Damon

Re: Can a more useful bounce message be provided - correction

[Richard Siddall]

Phil Stracchino wrote:

On 11/13/20 1:22 PM, John Fawcett wrote:

On 13/11/2020 07:38, li...@lazygranch.com wrote:

My server bounced a message. Here is the server log (sanitized).
-
Nov 13 02:07:52 myserver postfix/smtpd[27706]: NOQUEUE: reject: RCPT
from sonic302-23.consmr.mail.gq1.yahoo.com[98.137.68.149]: 554 5.7.1
Service unavailable; Client host [98.137.68.149] blocked using
cbl.abuseat.org; Blocked - see
http://www.abuseat.org/lookup.cgi?ip=98.137.68.149;
from= to= proto=ESMTP
helo=
---
Here is what the sender received:



From: mailer-dae...@yahoo.com
Date: November 12, 2020 at 6:07:55 PM PST
To: per...@sbcglobal.net
Subject: Failure Notice

Sorry, we were unable to deliver your message to the following address.

:
554: 5.7.1 Service unavailable

--- Below this line is a copy of the message.

---

So did the Oath server swallow the useful link to abuseat.org? Can this
be improved?

missing NOT makes all the difference:


Your server rejected that message, so your server was NOT responsible for

generating the bounce message. That was generated by yahoo.


I think what the OP is asking here is, can Yahoo/Oath be compelled to
provide a more useful failure message relaying the informative response
provided by OP's Postfix instance.

And the answer to that, unfortunately, is no.




The meta-question is whether there's any benefit to blocking mail from 
one of Yahoo!'s outgoing mail servers because it was listed in a DNSBL. 
DNSBLs are useful where the majority of mail coming from an IP is spam. 
The majority of mail received through that server is not spam.

Re: Is changing "Hostname" mandatory?

[Richard]

> Date: Wednesday, October 21, 2020 05:26:38 +
> From: Jason Long 
>
> For configuration Postfix, is changing "hostname" to something like
> "Mail.example.net" mandatory? For example, my server running Apache
> and I don't like to change its name.

No, but the forward and reverse DNS records need to match.

>From a security perspective, I would run these services under
different VMs.

Re: Host not found?

[Richard]

> Date: Sunday, October 18, 2020 16:07:24 -0400
> From: Joey J 
>
> Hello all,
> 
> I'm trying to understand why this is telling me host not found.
> On that same server if I nslookup the ip it does resolve.
> 
> Oct 18 16:00:51 mgw postfix/smtpd[24119]: NOQUEUE: reject: RCPT from
> unknown[199.5.50.180]: 450 4.7.1 : Helo command
> rejected: Host not found; from=
> to= proto=ESMTP helo=


There doesn't appear to be an A or MX record for "br2.vw.com".

Re: Mail server without MX record.

[Richard]

> Date: Friday, October 16, 2020 08:02:30 +
> From: Jason Long 

>> On Friday, October 16, 2020, 01:13:45 AM GMT+3:30, Richard
>> wrote: 
>> 
>> 
>>> Date: Thursday, October 15, 2020 18:57:29 +
>>> From: Jason Long 
>>> 
>>> If the DNS administrator give me an A record then can I sending 
>>> and receiving emails from the Internet by the current 
>>> configuration?  
>> 
>> Assuming no MX, if an A-record is set up to point to a  machine
>> (properly configured, including with postfix or some other MTA)
>> reachable on port 25 at the IPnumber, then it should be able to
>> receive mail inbound.
>> 
>> To be able to send mail directly to target mail servers you'll need
>> to be able to connect outbound on port 25. To successfully deliver
>> it, including to correspondents' inboxes, you'll need a matching
>> Rdns record as well as the following: 
>> 
>> (this list is taken from an earlier message from Ahsan Khan
>> responding to one of your questions):
>> 
>>   1. SPF
>>   2. DKIM records
>>   3. DMARC records
>>   4. IP Warmup
>>   5. Check the scores at mail-tester.com.
>>   6. Domain reputation
>> 
>>  There are a range of nitty things underlying all this which you 
>>  will need to read up on so that you understand how mail, DNS,
>>  etc. work.
>> 
>> You may be better off sending your mail outbound by way of a
>> smarthost at your provider.
>
> Thank you.
> Thus, in Postfix or Dovecot configuration file I can't change the
> standard record?
> 

Asked and already answered, multiple times, by various people.

It's also not clear how that question follows on from the q/a that it
is in reply to.

To run a mail server successfully takes a base-level knowledge of the
underlying protocols (and interoperability), not something gotten
from scattershot questions. Try looking at some of the references
previously mentioned.

Re: Mail server without MX record.

[Richard]

> Date: Thursday, October 15, 2020 18:57:29 +
> From: Jason Long 
>
> If the DNS administrator give me an A record then can I sending and
> receiving emails from the Internet by the current configuration?
> 

Assuming no MX, if an A-record is set up to point to a  machine
(properly configured, including with postfix or some other MTA)
reachable on port 25 at the IPnumber, then it should be able to
receive mail inbound.

To be able to send mail directly to target mail servers you'll need
to be able to connect outbound on port 25. To successfully deliver
it, including to correspondents' inboxes, you'll need a matching Rdns
record as well as the following: 

(this list is taken from an earlier message from Ahsan Khan
responding to one of your questions):

  1. SPF
  2. DKIM records
  3. DMARC records
  4. IP Warmup
  5. Check the scores at mail-tester.com.
  6. Domain reputation

There are a range of nitty things underlying all this which you will
need to read up on so that you understand how mail, DNS, etc. work.

You may be better off sending your mail outbound by way of a
smarthost at your provider.

Re: Mail server without MX record.

[Richard]

> Date: Tuesday, October 13, 2020 15:52:41 +
> From: Jason Long 
>
> I can't have MX record because the DNS server have another MX
> record for other mail server. I'm thankful if anyone tell me how
> can I solve my problem without MX record. Is t possible with A
> record?

Either you misstated the issue or someone has a poor understanding of
DNS.

You might want to step back and get a more complete understanding of
the workings of mail and DNS. Without that, simply following
"cookbooks" will likely not get you where you want to be.

[by the way, while I don't think that this list is hardcore on
posting order, most technical lists frown on top posting.]

Re: Mail server without MX record.

[Richard]

> Date: Tuesday, October 13, 2020 12:09:28 +
> From: Jason Long 
>
> Hello,
> Can I use Postfix without MX record? I installed Postfix
> and Dovecot via "https://wiki.centos.org/HowTos/postfix; tutorial
> and I want to know can I use it without MX record?

Yes. Some mail sites, incorrectly, think that one has to have an
MX-record for a site to be legit, but major ones know better. An
MX-record is related to inbound routing/deliverability, and not
specific to the MTA one is using.

You do need an A-, and for successful outbound deliverability, a
matching Rdns record. As noted in an earlier message chain, there is
a list of other things, e.g., SPF, DKIM, DMARC records, etc., that
will help in deliverability.

By the way, the documentation that you pointed to specifies that it
is written for Centos-5. As Centos-6 is EOL next month, C5 and
earlier are already EOL. So you should be using at least Centos-7,
and relevant documentation. Something in one of your messages
yesterday indicated that you were likely using Centos-6 or earlier.

Re: Sender restriction to reject message with multiple from addresses

[Richard James Salts]

On Saturday, 10 October 2020 1:59:33 PM AEDT Demi M. Obenour wrote:
> On 10/9/20 9:48 PM, Viktor Dukhovni wrote:
> >> What are the semantics of a From: header with multiple addresses?
> > 
> > The message purports to be the work of multiple authors.  Such a message
> > is required to have a "Sender" header, but in most cases that constraint
> > is unlikely to be enforced.
> 
> I love DKIM, but it should have been on the Sender header and not
> the From header.  However, for that to work, MUAs would have had to
> display something like "f...@example.com claims that this message
> is from f...@example.com and b...@example.com", and they do not.
> That lead to the current design.
With multiple authors in the From field you could sign with DKIM headers which 
align with each of the authors' sending domains and it would align for the 
purposes of DMARC, however the RFCs for DMARC punt on this situation and leave 
it up to the policy at the receiving MTA, which probably doesn't account for 
it given the rarity of such messages in the wild.

> 
> Demi

Re: Meaning of a blank "mydestination" value

[Richard Laysell]

On Fri, 2020-09-25 at 16:37 +0200, Erik Thuning wrote:
> Hi!
> 
> I've inherited a server environment where all the servers have local 
> postfix agents installed, relaying mail to our central email server.
> I'm 
> trying to understand the main.cf settings shared by all our servers,
> but 
> there is one setting that I can't understand:
> 
> mydestination =
> 
> Aka nothing assigned to the mydestination value. To me the
> documentation 
> makes it sound like this is an error, but I'm unclear as to the
> exact 
> consequences of forcing this setting to be blank. Mail delivery works
> as 
> expected (mostly).



> Thanks,
> Erik Thuning

Hello Erik,

A blank entry for mydestination means 'do not deliver mail to the local
machine' and all mail will be sent to the relayhost.  This is known as
a 'null client'

See 
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client
for details.

Regards,

Richard

On Fri, 2020-09-25 at 16:37 +0200, Erik Thuning wrote:> Hi!> > I've inherited a server environment where all the servers have local > postfix agents installed, relaying mail to our central email server.> I'm > trying to understand the main.cf settings shared by all our servers,> but > there is one setting that I can't understand:> > mydestination => > Aka nothing assigned to the mydestination value. To me the> documentation > makes it sound like this is an error, but I'm unclear as to the> exact > consequences of forcing this setting to be blank. Mail delivery works> as > expected (mostly).> > If it makes any difference, here is the complete main.cf file that> we > deploy:> > mydomain = dsv.su.se> myorigin = $mydomain> mydestination => relayhost = [smtp.su.se]> mynetworks = 127.0.0.0/8 [::1]/128> inet_interfaces = loopback-only> biff = no> append_dot_mydomain = no> > > Thanks,> Erik ThuningHello Erik,A blank entry for mydestination means 'do not deliver mail to the local machine' and all mail will be sent to the relayhost.See http://www.postfix.org/STANDARD_CONFIGURATION_README.html#null_client for details.Regards,Richard

Re: [RFE] - Resolving of SRV records

[Richard Salts]

On 30/07/2020 12:47 am, Wietse Venema wrote:


Henry Miller:

Asking user to type in ?_submission._tcp? seems like a poor
workaround. This being Autodiscovery it?d be logical for Postfix
to automagically derive SRV lookup address based on relayhost
setting.

?relayhost = example.com? is an obvious candidate for SRV autodiscovery
if an MX lookup fails or if SRV is prefered over MX. With an
optional switch to disable ?relayhost_autodiscovery?.

Except that a) the SMTP client does not know whether a destination is
derived from the relayhost parameter and b) it's entirely legitimate
to specify the up-stream relay with transport_maps or default_transport.

That would be an argument against making the relayhost parameter
special, and in favor of using special destination syntax.

A challenge with special destination syntax (see below) is that
we want to allow these in main.cf and transport maps, but not in
user-specified email addresses.

syntax  |lookups
==
example.com |MX (SMTP client only) then A/
[example.com]   |A/ (all programs)
_submission._tcp.example.com|SRV (SMTP client only) then A/
   |SRV then A/ (invalid outside the SMTP client)
SRV:example.com |SRV then A/ (invalid outside the SMTP client)

The fourth example uses angle brackets instead of [].

The _submission._tcp.example.com would require extra code to block
this in user-specified email addresses; the forms SRV:example.com,
 and [example.com] are rejected by Postfix's syntax
checks for email address domains.


Also where does _submissions._tcp.example.com for TLS on connect rather 
than STARTTLS services fit in? I assume the client autoconfig 
advertising should allow this since submissions has been put back on the 
table by the IETF. Would that be another reason to not use the 
_submission._tcp.example.com in config? Would it maybe be better for an 
option in main/overridden in master for specific transports to specify 
methods of host discovery with default being current behaviour of MX 
then A/ but with the options of SRV-SMTP, SRV-SUBMISSION, 
SRV-SUBMISSIONS being options in a list that's tried in order?




In any case, autoconfiguration is no good without the part that
validates the hostnames in SRV responses. That part needs to be
configurable, and needs a good default value.

Wietse

Re: Gmail and spam, a request

[Richard Damon]

On 4/26/20 11:47 PM, Peter wrote:
> On 27/04/20 2:02 am, Richard Damon wrote:
>> On 4/26/20 8:15 AM, Peter wrote:
>>> On 27/04/20 12:00 am, Richard Damon wrote:
>>>> Except that if the sender is sending from a domain with an email
>>>> policy
>>>> that effectively says, "This domain is intended to send sensitive
>>>> information, please do not accept messages that do not come directly
>>>> from us", then it is reasonable to tell the sender that they are
>>>> sending
>>>> messages outside their domains (implied) terms of service, and either
>>>> they need to use a different service that is compatible with a mailing
>>>> list, or have the domain fix its implied declaration of usage.
>>>
>>> But that's not what DMARC does.
>>
>> It is EXACTLY what DMARC does.
>
> You claim that DMARC is supposed to control sensitive information.  It
> does nothing of the sort and cannot do anything of the sort.  DNS
> records cannot stop someone unauthorized from accessing sensitive
> information in an email message.
It is for something like an alert that there is a suspecious use of your
credit card, so please check with your bank. The sort of thing many of
us get a phish attacks.
>
>>> Ummm, no it's not.  DMARC is intended to stop mail From: header
>>> spoofing.
>>
>> And re-mailing the original message is classified as From: header
>> spoofing.
>
> Since when?  If you leave the From: header intact how is that
> spoofing? Exactly what are you misrepresenting?  That's like saying
> that if I make a copy of a document then I am misrepresenting the
> original.  In fact changing the From: header which we must do to work
> around the issues that DMARC poses is much closer to spoofing (but
> still is not, imo) than simply forwarding the message with the headers
> intact.
If I take a measage that has been protected by just DMARC/SPF, and
forward it, it will fail DMARC and be considered a spoof. Yes, in our
personal understanding, taking an email message in on a mailing list and
resending it out, maybe with some minor administrative changes isn't a
spoof, but to DMARC is it. THAT is part of the issue with DMARC.
>
>> A properly setup DMARC/DKIM (but not just DMARC/SPF) does
>> allow remailing if the message is kept identical in the signed respects,
>> so DMARC with a broken (or not setup) DKIM can't use re-mailiers at all,
>> and one with DMARC/DKIM can only use remailers that don't modify the
>> message, including the common adding of a subject 'wart' to identify
>> messages from the list or a message footer (or sometimes header) with
>> instructions about the list, included out of policy or sometimes even to
>> be compliant with local legal requirements.
>
> DKIM is not required for DMARC.
Yes, and DMARC without DKIM will break EVERY email list (without careful
updates by the domain manager), as the list will not be one of the
approved IP that mail from that domain is allowed to come from.
>
>>>> Configuring a domain
>>>> with DMARC says that it is intended that message only be accepted if
>>>> they come directly from the sender.
>>>
>>> I call BS on that, and in fact ARC was created specifically to allow
>>> third parties to forward DMARC policy messages on without having them
>>> flagged as Spam.
>>
>> ARC is a late to the party attempt to fix the misuse of DMARC. To my
>> knowledge it isn't even an accepted standard yet, and it asks for the
>> impacted 3rd party to add to its processing to allow it to become an
>> 'approved' re-resender. It also starts with the list with being a
>> violator until the system 'learns' that it is ok.
>
> Google recognizes it, and in the case of the above mentioned messages
> it is likely that ARC would have fixed it so that the message would
> not have ended up in my Spam folder.  That said, I already did point
> out that there will be servers that enforce DMARC which do not
> recognize ARC and as such I would prefer to see other mitigations done
> that do not require ARC.  But I simply pointed it out as an official
> attempt to fix a shortcoming with DMARC.

ARC is a sign that DMARC is broken, that it wasn't intended for the uses
that it is now being used on. It was NOT a part of the initial DMARC
proposal, there is no sign at all of it in the design. It is a patch fix
to handle a problem that came up when DMARC was misused. we are now 6
years after DMARC was misused, it took 3 years from that to have initial
proposals, 5 years to get an 'experimental' RFC, which is our current
state. It basically says, hey, all you mailing list out there, here is
an idea we have,

Re: Gmail and spam, a request

[Richard Damon]

On 4/26/20 10:25 PM, Peter wrote:
>
> I prefer to be able to see a full conversation rather than having to
> hunt through my Spam folder for pieces of it.
>
>
> Peter
>
The solution for the GMail user is to just add a filter for messages
from the list and set the filter to bypass the spam filter, no more
problems with the messages in the spam filter. At the same time you can
put the message into a tag, to keep things organized.

-- 
Richard Damon

Re: Gmail and spam, a request

[Richard Damon]

On 4/26/20 6:41 PM, Jaroslaw Rafa wrote:
> Dnia 26.04.2020 o godz. 17:00:31 Richard Damon pisze:
>> I have never had GMail ask me to setup DMARC, they will ask you to setup
>> SPF or DKIM as a first step for delivery problems, as letting them
> Did you read https://support.google.com/mail/answer/81126 ? (That's the page
> their "sender troubleshooter" form is referring to)

That looks like it got added since the last time I needed to deal with
them, just having SPF has done well enough for most of my needs. My
major issue has been running a mailing list, so most of my outgoing mail
doesn't have my domain in it so DMARC isn't as important for my domain.

> "To minimize the chance that your messages are marked as spam, set up these
> authentication methods:
>
> *Publish an SPF record for your domain. SPF prevents spammers from
> sending unauthorized messages that appear to be from your domain.
> *Turn on DKIM signing for your messages. Receiving servers use DKIM to
> verify that the domain owner actually sent the message. Important: Gmail
> requires a DKIM key of 1024 bits or longer.
> *Publish a DMARC record for your domain. DMARC helps senders protect
> their domain against email spoofing."
>
> When you fill in the sender troubleshooter form, it asks you explicitly if
> you have done all this.
>
>> As to Disposition-Notification-To: headers, the RFC for those clearly
>> state that it is just a polite request to the receiving system, and they
>> are well within bounds to ignore it. I personally always disable the
>> automatic reply off those headers (and won't use a system that won't let
>> me do so if I have any choice about it).
> With Gmail - at least with Gmail's web interface (and that's what the
> majority of their users use) - you have no choice. It simply doesn't support
> that header at all.

In my opinion, totally ignoring the header is not that bad of an option.

-- 
Richard Damon

Re: Gmail and spam, a request

[Richard Damon]

On 4/26/20 3:23 PM, Jaroslaw Rafa wrote:
> Dnia 26.04.2020 o godz. 08:00:56 Richard Damon pisze:
>> This is exactly what DMARC is intended to indicate. Configuring a domain
>> with DMARC says that it is intended that message only be accepted if
>> they come directly from the sender. It was designed for things like
>> Banks to be able to send out messages that the recipients can trust came
>> from them and not a scammer.
> But email providers like Google are ignoring the fact that DMARC was
> intended for such purposes, and consider it an universal anti-spam measure.
> Google, as a recipient, clearly indicates in their sender guidelines
> (targeted at senders who have trouble with deliverability of their messages
> to Gmail users - among other cases, messages being placed in Spam folder)
> that the sender has to have DMARC, DKIM and SPF configured. That's the first
> thing they require from you if you have any deliverability problems with
> them. However, having all this set up doesn't provide any guarantee that
> your email won't be qualified as spam (so why require it at all?).
> BTW, with regard to messages being marked spam, DMARC reports are pretty
> useless because they don't give you any information about that. And that
> would be actually the most interesting thing in those reports. They only
> give me information whether the message passed or failed DMARC/DKIM/SPF
> check, but this tells me nothing in terms of knowing if the recipient
> actually got my message or not.
> What's worse, Gmail does not honor Disposition-Notification-To: header,
> which could be used to determine if the recipienta ctually read my message
> or not.
> So sending mail to someone at Gmail is actually sending it into the
> unknown...

I have never had GMail ask me to setup DMARC, they will ask you to setup
SPF or DKIM as a first step for delivery problems, as letting them
confirm SENDER (not From) is the first step to them being able to do
something about you. With SPF enabled, then they can verify that any
message that claims you are the sender of the message, is actually
coming from a machine under you control, so they can reject forged senders.

Note, there is a MAJOR difference between SPF and DKIM as stand alone
protocols, and on how they are used within DMARC. Plain SPF/DKIM are
tied to the sender of the message, which should be a reference to the
machine that actually sending the message (or the organizations that
control it). For instance, all messages from this mailing list have a
sender address that is in the postfix.org domain. If a machine receives
a message, and then sends it along anew (like a mailing list) then it is
supposed to reset the sender to itself (as that is where deliver errors
should go) in the process. That means that messages from this list will
be checked against the postfix.org SPF and DKIM rules, so it can
validate that this transmission was initiated by something at postfix.org

When DMARC comes into play, rather than using the sender, you check the
From: header, which a re-sender is NOT supposed to change. This means
that messages from this list are likely going to fail DMARC/SPF, unless
the domain that originated the message specifically added the
postfix.org outgoing email servers to its allowed host list. (and ARC
when it is working might allow that domain to say that it trust
postfix.org to verify and re-transmit its messages). IF the originating
server has a properly configured DMARC/DKIM setup, then the message will
be signed, and because the postfix.org mailing lists don't touch the
parts of the message normally signed by DKIM, the relayed message will
pass DMARC/DKIM and thus pass DMARC (since only one needs to pass). More
commonly, many email list systems will do minor administrative changes
to the message (adding a subject wart or a list footer) which will break
DKIM and thus the fail DMARC/DKIM abd DMARC/SPF.

GMail isn't really out of line in using broken DMARC as a spam
indicator. Domains with DMARC enabled have indicated that they what
people to be careful about their messages, and broken DMARC is a sign of
problems. It could be argued that if the DMARC uses p=none then it
shouldn't count against delivery, but by a reasonable interpretation of
the RFC, delivery to the GMail spam folder does qualify as delivery, and
there aren't any hard rules about spam detection.

Yes, DMARC replies won't let you know if the user every actually saw the
message, that isn't there purpose. There purpose is to help you know how
bad your spoofing problem is, or to help you diagnose your own outgoing
DMARC issues.

As to Disposition-Notification-To: headers, the RFC for those clearly
state that it is just a polite request to the receiving system, and they
are well within bounds to ignore it. I personally always disable the
automatic reply off those headers (and won't use a system that won't let
me do so if I have any choice about it).

-- 
Richard Damon

Re: Gmail and spam, a request

[Richard Damon]

On 4/26/20 8:15 AM, Peter wrote:
> On 27/04/20 12:00 am, Richard Damon wrote:
>> Except that if the sender is sending from a domain with an email policy
>> that effectively says, "This domain is intended to send sensitive
>> information, please do not accept messages that do not come directly
>> from us", then it is reasonable to tell the sender that they are sending
>> messages outside their domains (implied) terms of service, and either
>> they need to use a different service that is compatible with a mailing
>> list, or have the domain fix its implied declaration of usage.
>
> But that's not what DMARC does.

It is EXACTLY what DMARC does. DMARC/SPF says that if you get a message
with my domain in the From line, then it should come from only the
servers that I list in my SPF record. DMARC/DKIM says that if you get a
message with my domain in the From line, that it must be properly signed
by the source domain and unchanged thereafter. A domain with both needs
to pass one or the other.

>
>> This is exactly what DMARC is intended to indicate.
>
> Ummm, no it's not.  DMARC is intended to stop mail From: header spoofing.

And re-mailing the original message is classified as From: header
spoofing. A properly setup DMARC/DKIM (but not just DMARC/SPF) does
allow remailing if the message is kept identical in the signed respects,
so DMARC with a broken (or not setup) DKIM can't use re-mailiers at all,
and one with DMARC/DKIM can only use remailers that don't modify the
message, including the common adding of a subject 'wart' to identify
messages from the list or a message footer (or sometimes header) with
instructions about the list, included out of policy or sometimes even to
be compliant with local legal requirements.

>
>> Configuring a domain
>> with DMARC says that it is intended that message only be accepted if
>> they come directly from the sender.
>
> I call BS on that, and in fact ARC was created specifically to allow
> third parties to forward DMARC policy messages on without having them
> flagged as Spam.

ARC is a late to the party attempt to fix the misuse of DMARC. To my
knowledge it isn't even an accepted standard yet, and it asks for the
impacted 3rd party to add to its processing to allow it to become an
'approved' re-resender. It also starts with the list with being a
violator until the system 'learns' that it is ok.

>
>> It was designed for things like
>> Banks to be able to send out messages that the recipients can trust came
>> from them and not a scammer. (A scammer could fake this out with a
>> 'look-alike' domain, but that leaves a strong back trail to the scammer,
>> who tend to want to hid in the darkness of the web.
>
> Exactly, it's designed to prevent spoofing.
>
> And here's my rant:
>
> This is a *public mailing list* for Christ's sake!  If you are going
> to post to it then you should expect your message to be seen by the
> public!  DMARC will not stop or prevent this, all that DMARC does is
> send the message to Spam.  It will still be seen in the mailing list
> archives and it will still land in some folder on nearly every member
> of this list's mailbox.  If you have sensitive info DMARC will not
> stop that and you should not be posting sensitive info to a public
> mailing list!
>
>
> Peter

DMARC's purpose is to stop phishing, people pretending to be you when
they aren't. Mailing list send messages out on Behalf of you, but the
DMARC protocal wasn't built to handle this case (ARC is trying to fix
it, but is late to the game). Now, if DMARC had a level below
quarantine, that said to accept the messages even if they don't pass the
DMARC validation, and to not treat this violation as likely spam, but
maybe and a remailer warning, but it doesn't, as it wasn't intended in
its design to handle this case. Domains using DMARC and allowing users
to use mailing list are working outside the original design parameters
of DMARC.

If a mailing list gets a message from a DMARC enabled host it has just a
few possible mitigations:

1) If the sending domain has a proper DMARC/DKIM setup, the list can
just forward the message without making any modifications that would
break DKIM, provided that this falls within the policy and laws the list
run, IF DMARC/DKIM isn't setup properly, this option can't be used.

2) The list can violate the EMail RFCs, change the From header to be the
list (thus claiming authorship of the message) and distribute the
message this way. This makes if hard to identify the real author of the
message, as it no longer is in the from header, so doesn't show in many
MUA. This is the common DMARC mitigation.

3) The list can just not allow people from DMARC enable domains to post
(which is ultimately respecting the implied wishes of the domain
publishing a DMARC record). When Y

Re: Gmail and spam, a request

[Richard Damon]

On 4/26/20 7:07 AM, Peter wrote:
> On 26/04/20 10:47 pm, Benny Pedersen wrote:
>> talk to postmas...@almogavers.net ask for aspf not being set to
>> strict, also possible make fo tag on dmarc more relaxed
>
> Except that this is a thread about what messages coming from the
> *list* go to spam and what the *list* can do about it.  It is not
> reasonable for the mailing list owner to ask every person who's
> messages go to spam because of a bad DMARC policy to change the policy.

Except that if the sender is sending from a domain with an email policy
that effectively says, "This domain is intended to send sensitive
information, please do not accept messages that do not come directly
from us", then it is reasonable to tell the sender that they are sending
messages outside their domains (implied) terms of service, and either
they need to use a different service that is compatible with a mailing
list, or have the domain fix its implied declaration of usage.

This is exactly what DMARC is intended to indicate. Configuring a domain
with DMARC says that it is intended that message only be accepted if
they come directly from the sender. It was designed for things like
Banks to be able to send out messages that the recipients can trust came
from them and not a scammer. (A scammer could fake this out with a
'look-alike' domain, but that leaves a strong back trail to the scammer,
who tend to want to hid in the darkness of the web.

-- 
Richard Damon

Re: Gmail and spam, a request

[Richard Salts]

On 23/03/2020 8:55 am, Viktor Dukhovni wrote:

It is best to not modify the message headers at all, which iseffectively what 
the Postfix list does (it adds a Sender: header which should not be covered by 
the upstream DKIM signature).


I know the Sender header has traditionally been used by mailing lists, 
but would the Resent-Sender from rfc5322 be better in case people send 
to the postfix mailing list with a DKIM signature for an existing Sender 
header

Re: should we use plaintext for message?

[Richard Damon]

On 3/20/20 11:48 AM, Gerard E. Seibert wrote:
>
> Honestly, I fail to see why receivers of HTML based emails seem to
> feel they have a right to get themselves into a hissy fit and dictate
> what type or form of email is permissible? Who made them GODS?
>
> When I receive an email, I have two immediate choices to make; either
> read it or don't read it. From there, I can choose to save or archive
> the message, delete it or potentially forward or reply to it. I have
> yet to understand this hatred of HTML email. Perhaps the recipient has
> Autophobia. Maybe it is related to Trypophobia. Perhaps it is something
> entirely different. In any case, who cares?
>
> Personally, I prefer basic plain text. However, working for a
> municipality has caused me to use HTML quite frequently. The adage "A
> picture is worth a thousand words" is certainly relevant to this.
>
> In any case, I have so many more meaningful and useful things to
> accomplish, that I just do not have the time to waste on such a
> frivolous and doomed from the start attempt at convincing others that
> there is only one acceptable way to do things and it is mine.
>
> Don't like HTML; then don't use it. However, you don't have the right
> to tell others what then can do. The last time I checked, there was no
> RFC against it. Simply blacklist the sender, the site or whatever and
> get on with your life.
>
But, when you are using a mailing list, the list owner has the right to
decide what gets sent on THEIR mailing list.

-- 
Richard Damon

Re: Postfix Maildir problems - SOLVED(?)

[Richard Rasker]

Op 29-12-19 om 16:29 schreef Wietse Venema:

Richard Rasker:

So here is a striking difference between the old and the new machine
that I don't understand. Is there a way to figure out which process is
actually dumping the mail in /var/spool/mail? Because if it is still
maildrop, it isn't logging anything as it should.

Postfix logs all deliveries. Here is an example that you posted earlier:

 Dec 28 21:54:08 mail postfix/local[2755]: 26F111E0377:
 to=, relay=local, delay=0.01, delays=0/0.01/0/0.01,
 dsn=2.0.0, status=sent (delivered to command: /usr/bin/maildrop)

Look for "status=sent" lines in your log. That will show whether
/usr/bin/maildrop is involved.


All logged mail events (sending, receiving) have "status=sent" in the 
second-last logged line in mail.log (the last line saying that it's 
removed from the queue).


But some progress happened, even though I don't really understand how. 
Up until two hours ago, mail *always* ended up in /var/spool/mail, even 
when I deleted "/usr/bin/maildrop" after mailbox_command = in main.cf, 
and the log entries also confirming that it was delivered to the maildir:


   ... status=sent (delivered to maildir)

(I can match these entries with messages in /var/spool/mail, not with 
any messages in any Maildir directory as I would expect).


Yet now, all of a sudden, new test messages show up in the correct 
Maildir folders. The one thing I did apart from changing the 
mailbox_command parameter back and forth was making the file 
/var/spool/mail/[username] read-only (chmod 400). This never resulted in 
any error messages BTW. (And yes, main.cf specified home_mailbox = 
Maildir/ all the time -- as already stated in my very first message here.)


So I have no idea what fixed at least the behaviour of postfix, and 
maildrop still refuses to work properly (i.e. it still sends mail to 
/var/spool/mail, and refuses to log anything), but at least I have a 
functional maildir system -- also after completely rebooting the box 
just to make sure. I'll try and sort out the maildrop conundrum later -- 
and as I never actually used its filtering capabilities in the first 
place, I might even leave it at this.


Thank you once again for your hints and support!

Best regards,

Richard

Re: Postfix Maildir problems

[Richard Rasker]

Hello,

Op 29-12-19 om 05:18 schreef @lbutlr:

On 28 Dec 2019, at 14:54, Richard Rasker  wrote:

Everything went very smooth, and everything works (sending mail, receiving 
mail, authentication, certificates, IMAP folders showing in the mail client 
(Thunderbird)) -- except for the very last thing: received mail ends up in 
/var/spool/mail/[username] instead of the users' Maildir folders.

Postfix logs what happens to the message, and postfix says the message was 
delivered. Postfix its at that point out of the picture, and it is your courier 
setup that is not correct.

This may well be the case.


Also you say “identical setup” but obviously it cannot be actually identical. 
Why do you think it is identical?


I checked the following configuration files on both the old and the new 
server, and they are literally identical:


/etc/default/courier:

   # This file is automatically generated by maintainer scripts.
   # You may modifiy this file, but additional values and format
   # modifications will not be preserved.
   MAILDIR="Maildir"

/etc/default/maildroprc:

   logfile "/var/log/maildrop"
   VERBOSE="5"
   log "=="

/etc/courier/authdaemonrc:

   ##VERSION: $Id: authdaemonrc.in,v 1.13 2005/10/05 00:07:32 mrsam Exp $
   [etc.]

/etc/courier/imapd:

   ##VERSION: $Id: imapd.dist.in,v 1.41 2008/06/21 16:01:23 mrsam Exp $
   [etc.]

Postfix' main.cf file has some minor differences with regard to tls and 
smtpd_client_restrictions, but those should not have any bearing on the 
final delivery of mail.


I could not locate any other configuration files -- and if there are any 
more, I never touched them on either machine.



It’s been a long time since I used Courier, but commenting out the mail drop 
line in main.cf and reloading postfix should disable mail drop. That is not 
going to fix your problem, but postfix will deliver the mail to your 
home_mailbox, assuming your users have a $HOME.


At one point, I had the entry

   mailbox_command=/usr/bin/maildrop

in main.cf, and when I executed

   # postconf -e "home_mailbox = Maildir/"

both mail.log and syslog threw this warning (and in multiple instances 
from several active processes):


   syslog.1:Dec 28 21:07:05 mail configure-instance.sh[5021]: postconf:
   warning: /etc/postfix/main.cf, line 81: overriding earlier entry:
   mailbox_command=/usr/bin/maildrop
   syslog.1:Dec 28 21:07:05 mail postmulti[5087]: warning:
   /etc/postfix/main.cf, line 81: overriding earlier entry:
   mailbox_command=/usr/bin/maildrop
   syslog.1:Dec 28 21:07:05 mail postmulti[5087]: postsuper: warning:
   /etc/postfix/main.cf, line 81: overriding earlier entry:
   mailbox_command=/usr/bin/maildrop
   [etc]

At the moment, these warnings no longer appear when restarting postfix, 
regardless of the main.cf entry wrt. home_mailbox -- I don't know why.



When you say no *significant* difference in conf files, that implies there is 
some difference. Your problem likely lies in those differences.
I haven't been able to identify any differences so far, except the ones 
in main.cf that I mentioned already.

Does maildrop log its actions?


It should -- but here I find a strange difference: the maildrop log on 
the new machine stays empty.


Receiving a message on the old machine results in the following maildrop 
log entry:


   ==
   Date: Sun Dec 29 14:44:11 2019
   From: r...@linetec.nl
   Subj:
   File: /home/rr/./Maildir (806)

Yet nothing is logged at all in /var/log/maildrop on the new machine -- 
suggesting that maildrop isn't working properly there. Still, combing 
through syslog and other logs for 'maildrop' or even 'mail' does not 
reveal any relevant errors or warnings that may relate to this.


So here is a striking difference between the old and the new machine 
that I don't understand. Is there a way to figure out which process is 
actually dumping the mail in /var/spool/mail? Because if it is still 
maildrop, it isn't logging anything as it should.


Would it be safe to (temporarily) change something about /var/spool/mail 
(e.g. write permissions) to force an error message?



I could provide all configuration files (main.cf, master.cf), but I'm not sure 
which ones may be relevant, so I won't dump it all here right away.


Postfix configuration files are unlikely to help as the log line you posted 
shows postfix delivers the message to maildrop.

More likely you need help from a courier list?


That may be a very good idea. Thank you (and the others here) for your 
suggestions and support.


I'll try to find out what is happening -- although after almost two days 
of fruitless searching and tinkering, I am tempted to make a back-up of 
the current situation, totally purge postfix, courier, amavisd-new etc. 
from the machine, and start with a fresh installation of those packages.


I must have done something wrong early on, messing up or overlooking one 
tiny setting or so that I haven't fou

Re: Postfix Maildir problems

[Richard Rasker]

Hello Wietse,

Op 28-12-19 om 23:54 schreef Wietse Venema:

Richard Rasker:

Yes, I have specified the use of Maildir in main.cf:

 home_mailbox = Maildir/

That Postfix setting has no effect on /usr/bin/maildrop, because
/usr/bin/maildrop is NOT part of Postfix.


I figured that much already. However, I still haven't found a way to 
disable it, and the man page doesn't say anything about configuring the 
destination. So I decided to ask around here to see if more people are 
using it with Postfix.


But maybe I should simply try and remove courier-maildrop, and see what 
happens.


Thank you for your comment,

Best regards,

Richard

Re: Postfix Maildir problems

[Richard Rasker]

Hell John,

Package versions:

# apt list postfix
Listing... Done
postfix/oldstable,now 3.1.12-0+deb9u1 i386 [installed]

#apt list courier-imap
Listing... Done
courier-imap/oldstable,now 4.17.2+0.76.3-5+deb9u1 i386 [installed]

# apt list courier-imap-ssl
Listing... Done
courier-imap-ssl/oldstable,now 4.17.2+0.76.3-5+deb9u1 all [installed]

# apt list amavisd-new
Listing... Done
amavisd-new/oldstable,now 1:2.10.1-4 all [installed]

And yes, I want to have the mail for user richard delivered to 
/home/richard/Maildir , and for user mary to /home/mary/Maildir and so 
forth. It should NOT go into /var/spool/mail/[username]


And this is what I had working just fine for years on my old server with 
older versions of postfix, courier etcetera. In fact, I even literally 
copied the old configuration files to the new system to see if that 
would fix things, but it didn't.



But since you say that people can get emails, I'm not sure what the
real problem is.  Does the old system drop email into the Maildir as
well?


No, people cannot receive e-mail because of this (as the courier IMAP 
server uses Maildir folders). Postfix does send and receive e-mail, it's 
just that the mail doesn't end up in the right place. The old server 
still works fine, but the hardware is old (been running almost 8 years 
non-stop) and the Linux system requires a distribution upgrade as well.


Anyway, thanks for your response, best regards,

Richard

Re: Postfix Maildir problems

[Richard Rasker]

Hello Max-Julian,

Yes, main.cf features this line:

   mailbox_command = /usr/bin/maildrop

However, it makes no difference if I leave out the executable (in effect 
specifying no mailbox command), as follows:


   mailbox_command =

I also tried this command:

   postconf -e "home_mailbox = Maildir/"

But that doesn't work either.

But thank you for your input, I shall take another good look at the 
documentation.


Best regards,

Richard Rasker

Postfix Maildir problems

[Richard Rasker]

Hello,

I just installed a new mail server on Debian 9 (Stretch) with the 
following setup:


- postfix

- courier-imap + courier-imap-ssl

- amavis + spamassassin

- courier-maildrop for delivery to Maildir folders

NOTE: I copied the Maildir folders' content from my older mailserver 
with an identical setup, one that has been running without problems for 
years, but that I now want to retire.


Everything went very smooth, and everything works (sending mail, 
receiving mail, authentication, certificates, IMAP folders showing in 
the mail client (Thunderbird)) -- except for the very last thing: 
received mail ends up in /var/spool/mail/[username] instead of the 
users' Maildir folders.


I haven't been able to solve this problem after several hours of 
searching and trying, so I turned to this mailing list.


Yes, I have specified the use of Maildir in main.cf:

   home_mailbox = Maildir/

But when a message is handed off to maildrop, it doesn't end up in the 
user's Maildir, but is added to the user file in /var/spool/mail. The 
log file doesn't show any warning or error message (final lines showing 
delivery of a test message, passed clean by amavis):


   Dec 28 21:54:08 mail postfix/local[2755]: 26F111E0377:
   to=, relay=local, delay=0.01, delays=0/0.01/0/0.01,
   dsn=2.0.0, status=sent (delivered to command: /usr/bin/maildrop)
   Dec 28 21:54:08 mail postfix/qmgr[2510]: 26F111E0377: removed

Is there a way to disable maildrop to see if that changes anything? 
Strange enough I have a hard time finding information about maildrop and 
maildroprc.


Also, there are no significant differences with the old server's 
postfix, courier and maildrop configuration files (the server I'm using 
right now). I also double-checked permissions, and there's no difference 
there either.


Does anyone have a clue? I could provide all configuration files 
(main.cf, master.cf), but I'm not sure which ones may be relevant, so I 
won't dump it all here right away.


Thanks already for any clues,

Richard

Re: Forwarding mail without breaking SPF?

[Richard Damon]

On 11/26/19 2:07 PM, Benny Pedersen wrote:
> Den 26-11-2019 kl. 17:59 skrev Marek Kozlowski:
>
>> OK. I do not insist on postsrsd. I'd really appreciate any
>> suggestion: what can I use instaed of it - what do you recommend?
>
> no one uses spf anymore since it breaks mailling lists very badly ?,
> postfix maillist have not even spf helo pass :)
>
> spf works only on direkt mail, not mailling lists since envelope
> sender changes on maillists
>
> so if you add spf to your domain it would not make bad things ever
>
> dmarc is another storry not to try
>
SPF does NOT break from a properly configured mailinglist, as SPF
doesn't check just from, but can also use sender/envelope-from, which a
proper mailing-list should set to itself, so SPF will pass.

DMARC/SPF, which only validates to the From: header will break.

-- 
Richard Damon

Re: Validation DMARC

[Richard Damon]

On 11/24/19 6:21 PM, Wesley Peng wrote:
> Why it doesn’t break From: header SPF? Just curious 
>
> On Mon, Nov 25, 2019, at 4:12 AM, Chris Wedgwood wrote:
>> > Or in short: DMARC intentionally breaks every mailinglist and every
>> > mail-forwarding.  So, if a mail-provider uses a strict DMARC-policy,
>> > it effectively says: "Our mail-addresses may not be used for
>> > mailinglists."
>>
>> this message (i am replying to) from you on this mailing list is not
>> broken
>>
It DOES break DMARC/SPF, as the IP address the message comes from
doesn't match the From of the message, but with DMARC if EITHER SPF or
DKIM pass, the message is to be considered to pass.

A Domain with strict DMARC, and which doesn't DKIM sign messages, will
fail with any form of remailer, so would fail for this application.

-- 
Richard Damon

Re: Validation DMARC

[Richard Damon]

On 11/24/19 3:12 PM, Chris Wedgwood wrote:
>> Or in short: DMARC intentionally breaks every mailinglist and every
>> mail-forwarding.  So, if a mail-provider uses a strict DMARC-policy,
>> it effectively says: "Our mail-addresses may not be used for
>> mailinglists."
> this message (i am replying to) from you on this mailing list is not
> broken
>
This list is somewhat unusual in that it doesn't include a footer with
list instructions, nor does it add a subject identifier to quickly
identify that the message comes from this list.

My guess is that two things are likely true:

1) This list is not run in a locality that requires obvious
unsubscription instructions, or that it has been decided that the
List-Unsubscribe header is good enough to meet that requirement

2) It is presumed that subscribers to this list are competent enough to
not need to be reminded about operating instructions. (This list's
subject matter is fairly technical, so not apt to draw less technically
adept subscribers).

-- 
Richard Damon

Re: Validation DMARC

[Richard Damon]

On 11/23/19 12:30 PM, Ralph Seichter wrote:
> * Roland Köbler:
>
>> Or in short: DMARC intentionally breaks every mailinglist and every
>> mail-forwarding.
> I doubt that it is broken "intentionally". ;-)
>
>   "[Ich habe] gefunden, daß Mißverständnisse und Trägheit vielleicht
>   mehr Irrungen in der Welt machen als List und Bosheit. Wenigstens sind
>   die beiden letzteren gewiß seltener." (J.W.v.Goethe, Die Leiden des
>   jungen Werther, 1771)
>
> -Ralph
>
They likely didn't go in with the thought that they needed something
that broke mailing lists, (and full DMARC doesn't break simple
forwarding, as thd DKIM signature should survive still matching), but in
the development of it, they did realize that DMARC would break emails
from many standardly run mailing lists. Initially this was ok, as the
initial types of messages that they were trying to protect wouldn't go
though such systems. There were attempts to figure out how to improve
the system so that it would work more generally and be usable for the
wider usage, but that didn't pan out.

It was only the adoption of the system by Yahoo and AOL (without
informing their users of the consequences), and then them telling
mailing list operators that the mailing lists had to deal with the
damage, as they needed to adopt this for 'reasons'.

-- 
Richard Damon

Re: Validation DMARC

[Richard Damon]

On 11/23/19 4:13 AM, Roland Köbler wrote:
> Hi,
>
>> when validating DMARC, it use the envelop address, or use from address from 
>> the header?
> it unfortunately uses the from-header.
> (If it would use the envelope address, it would not cause that much
> problems.)
>
> Or in short: DMARC intentionally breaks every mailinglist and every 
> mail-forwarding.
> So, if a mail-provider uses a strict DMARC-policy, it effectively
> says: "Our mail-addresses may not be used for mailinglists."
>
> The cleanest solution for mailinglists would be to reject mails from
> such adresses. (Spoofing the From-header by removing the authors address
> and replacing it by the lists address, and so hiding the original author,
> could of course also be done, but is not really a good solution.)
>
> Roland
>
When Yahoo first implemented this many years ago, and caused massive
disruption to the mailing list community, that WAS one of the proposed
solutions, put yahoo.com on the 'can not post' list, but it realized
that it wouldn't really hurt yahoo, only some of its subscribers. It
might cause some members to leave Yahoo, but unlikely enough to really
matter to them, and might drive more traffic to Yahoo Groups (which at
the time was making them money, and got around the problem because it
was part of Yahoo).

-- 
Richard Damon

Re: Validation DMARC

[Richard Damon]

On 11/23/19 4:26 AM, Dominic Raferd wrote:
>
>
> On Sat, 23 Nov 2019 at 09:14, Roland Köbler
> mailto:rk-l...@simple-is-better.org>>
> wrote:
>
> Hi,
>
> > when validating DMARC, it use the envelop address, or use from
> address from the header?
> it unfortunately uses the from-header.
> (If it would use the envelope address, it would not cause that much
> problems.)
>
> Or in short: DMARC intentionally breaks every mailinglist and
> every mail-forwarding.
> So, if a mail-provider uses a strict DMARC-policy, it effectively
> says: "Our mail-addresses may not be used for mailinglists."
>
>
> DMARC's focus on the From header is absolutely correct because it is
> about stopping forging. And it is simply untrue that DMARC breaks all
> mailing lists nor that it breaks all mail forwarding.
>
> I realise a lot of people on mailing lists about email have a downer
> on DMARC because depending on (a) the implementation of DKIM by the
> sender's domain controller and (b) on the setup of the mailing list it
> can - but often doesn't - cause problems. But it is a very powerful
> tool for preventing forging of emails. Domain controllers who are not
> bothered about forging of emails from their domain are not obliged to
> use it.

Many Mailinglist will break under DMARC as in many jurisdictions they
appear to fall under regulations that are designed for commercial
mailings, which include a requirement that all messages have a clearly
spelled out method to unsubscribe from that list. The standard solution
is to add a footer to the message with that information, which thus
break the DKIM signature, since under DMARC both SPF and DKIM are based
on the From: header of the message, the list is unable to distribute
messages from domains with strict DMARC as their From, even though that
is what a plain reading of the EMail RFC would require (The mailing list
has NOT become the author by a mechanical editing of the message).

The DMARC group admits that this is a problem, but their main solution
is to just tell all mailing list that they need to change the From of
messages to be the list so their method can be used. This causes lots of
problems, the real answer is that DMARC is not suitable for general mail
providers. It is really intended to be used by Institutions that do
transactional email, and those users don't need to use mailing lists.

Note, the problem is that DMARC for general email has an incredably high
false positive rate, what would you think if your mail provider adopted
a spam filter that declared 20% of your legitimate email as spam and
just discarded it. This is not a bad equivalent to the providers using a
method that declares mailinglist using the traditional methods that have
been used for decades as 'forgers'.

-- 
Richard Damon

Re: Question about DMARC

[Richard Damon]

On 11/22/19 6:25 AM, Wesley Peng wrote:
> Would this list break SPF then? Thanks 
>
This list sends with an envelope sender in the lists domain, so it
doesn't break general SPF, it will break DMARC SPF, since that check SPF
only to the From: domain.

This list doesn't modify messages in a way to break DKIM, so messages
that were DKIM signed to the From: Domain will still pass DMARC DKIM, so
will pass DMARC (unless the domain doesn't DKIM sign messages, which
would be very unusual for highly restricted DMARC).

-- 
Richard Damon

Re: Validation DMARC

[Richard Damon]

On 11/22/19 7:12 PM, Wesley Peng wrote:
> Hi
>
> when validating DMARC, it use the envelop address, or use from address
> from the header? Thanks 
>
DMARC specifically says that validation is to be based on the From:
Header of the message (which is different than how SPF and DKIM work by
themselves).

This is what gives DMARC issues with some uses of emails when messages
pass through relays which do things that break the message in route to
their final destination. The email RFCs say that the From: header is
suppose to indicate the author of the message, and the minor
modifications along the way done by the relays does not invalidate who
the author is, so the From should be retain.

Basically, this means that those domains that use DMARC, especially at
the higher levels, should not use those types of relays, which makes
some sense for the original intent of DMARC.

-- 
Richard Damon

Re: Question about DMARC

[Richard Damon]

On 11/22/19 6:25 AM, Jaroslaw Rafa wrote:
> Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze:
>> So mailing list makes DKIM or SPF failed?
>>
>> Thank you for your helps.
> My opinion is that the actual problem is that people who invented SPF and/or
> DMARC had wrong assumptions about how email works/should work.
>
> They assumed email is a straight and simple one-to-one communication like
> HTTP. If you send a mail from user1@xxx to user2@yyy, it goes straight from
> sending server for domain xxx to receiving server for domain yyy. So the
> receiving server can check if the email is coming from a "valid",
> "authorized" server for domain xxx (despite the fact that there isn't - and
> never was - such thing as "valid sending server" for any domain).
>
> This concept puts mailing lists, email forwarding and similar things
> completely out of scope. I would dare to say that these things simply did not
> exist for inventors of SPF/DMARC. That means, they obviously knew these
> things exist, but assumed they are completely unimportant and shouldn't (in
> their approach) be used.
>
> Big email providers started adopting SPF/DMARC etc. also without much
> thinking about these seemingly "unimportant" use cases, and then suddenly it
> turned out that we have quite a problem.
>
> You may disagree of course, but that's just how I see it. There is a quite
> old article about why SPF is wrong, but in my opinion this article didn't
> date a bit: http://david.woodhou.se/why-not-spf.html

Base SPF works through a traditional forwarder, because the base rules
for SPF allow the message to pass based on the domain of the Sender:
header, not just the From:. A proper forwarder will add a Sender: header
for itself, to indicate that while it was not the originator of the
message, it was the last one to send it. DMARC changes the rules for
SPF, and says that the message must align with the From: header, based
on the idea that most mail readers don't show you that sender does not
equal from.

SPF works just fine as designed, because it was designed as a HELPER for
receivers, not intending to be an all encompassing solution. If I, the
receiver of the message see that the message passed SPF, AND I trust the
domain that sent the message, then I can be fairly sure that the message
is legitimate. If there is a problem with the message, because I trust
the domain, I feel I can report the issue and it will be dealt with. SPF
is designed to help with 'white-listing'. SPF helps fight spam, as I can
white list the major mail agents that do a good job filtering spam, and
then have more bandwidth to look at those for sources I don't know.

DMARC adds nothing to that ability. Anyone can create a domain with a
strict DMARC policy and send spam from it. Just passing DMARC means
nothing in regards to the spamyness of a message. What DMARC is designed
to fight is forgeries. If you setup DMARC for your domain, then people
can trust that a message that says it is from you is from you (it still
could be spam though). The 'cost' of using DMARC is that you limit what
users of that domain can do, as they can't use external re-mailers that
don't follow very specific guidelines. This works for domains that deal
with transactional emails, where forgeries can be important, it doesn't
work for more casual usage.

I would actually say that an email provider using strict DMARC is
actually a sign of a email provider with a problem. I have heard that
the reason that Yahoo at least adopted it was that they had so many
security breaches that leaked out their users address books, that a very
real problem was yahoo members getting emails claiming to be from
friends that were actually attack vectors, that they couldn't keep up
with other measures to try and block it. The adoption of DMARC for a
general email provider is basically an acknowledgement that they have
problems maintaining a safe and secure email system. IF they advertise
it as a feature, and explain what it means you can't do, then maybe it
isn't, but if they don't inform you that they are not suitable for many
mailing lists and the like, then likely THEY are the one with a problem.

-- 
Richard Damon

Re: Question about DMARC

[Richard Damon]

On 11/21/19 11:47 PM, Wesley Peng wrote:
> Richard Damon wrote:
>> That is a question to ask them. Basically the strict DMARC policy is
>> designed for transactional email, where spoofing is a real danger. The
>> side effect of it is that addresses on such a domain really shouldn't be
>> used on mailing lists, or any other 3rd party senders not specifically
>> set up for that by the domain owner. For the proper usages of this, it
>> really isn't much of a problem, as the sorts of institutions that deal
>> with this sort of transactional mail, probably shouldn't be using that
>> same domain for less formal usages that tends to go with a mailing list.
>>
>> The problems arise when a domain that doesn't really need that level of
>> protection adopts it for some reason, especially if they don't inform
>> their users of the implications of that decision.
>
> Hello Richard,
>
> If I am wrong, please forgive me.
>
> Many ISP/Registrars provide email forwarding, I even had a pobox.com
> account which I used for 10+ years with just forwarding feature.
>
> When a mail like mail.ru was relayed by those providers, it sounds
> easy to break SPF/DKIM, so the recepients may reject the message. This
> is not good practice for the sender, even for mail.ru itself.
>
> Am I right?
>
> regards.
>
Normal forwarding will break SPF, but not DKIM (one reason DMARC uses
both). A mail provider that uses strict settings but doesn't DKIM sign
the messages would be considered seriously broken in my experience. The
issue is that many mailing list will break DKIM by slightly modifing the
message, like adding a signal word to the subject or a footer with
information like unsubscribing instructions (this can be a legal
requirement in some jurisdictions). Note, this list does NOT do this
sort of modification, so doesn't cause that sort of problem.

-- 
Richard Damon

Re: Question about DMARC

[Richard Damon]

On 11/21/19 11:21 PM, Wesley Peng wrote:
> Richard Damon wrote:
>> The typical options for the mailing list are
>>
>> 1) Just not allow people from such domains to post to the list (the
>> reject option you mention)
>>
>> 2) Rewrite the from address from people from such a domain to be from
>> the domain of the list (often the list address). This is arguably
>> discouraged by the email RFCs, as the from address should indicate the
>> AUTHOR of the message, which is the original sender. It also can cause
>> problems with identifying who sent the message, and can corrupt peoples
>> address books if their program records that address as being associated
>> with the sender. It can also make it harder to reply just to the sender.
>>
>> 3) Rewrite the message by wrapping it as an attachment, with the outer
>> message being from the list. This has the problem that many clients
>> won't handle the message in a useful manner.
>
> Thank you Richard.
>
> The email I am using is with domain of mail.ru, which has the
> strictest DMARC policy setting.
>
> So mailing list like postfix-users doesn't deliver my message to
> myself on this domain. And google groups rewrite the sender address to
> their own address.
>
> I don't know why mail.ru has this setup, this seems unfriendly.
>
> Thanks.
>
That is a question to ask them. Basically the strict DMARC policy is
designed for transactional email, where spoofing is a real danger. The
side effect of it is that addresses on such a domain really shouldn't be
used on mailing lists, or any other 3rd party senders not specifically
set up for that by the domain owner. For the proper usages of this, it
really isn't much of a problem, as the sorts of institutions that deal
with this sort of transactional mail, probably shouldn't be using that
same domain for less formal usages that tends to go with a mailing list.

The problems arise when a domain that doesn't really need that level of
protection adopts it for some reason, especially if they don't inform
their users of the implications of that decision.

-- 
Richard Damon

Re: Question about DMARC

[Richard Damon]

On 11/21/19 9:45 PM, Wesley Peng wrote:
> Greetings,
>
> When mail is relayed through mailing list, why the DMARC policy is
> possible to reject?
>
> For example, I sent mail from x...@mail.ru to y...@googlegroups.com
>
> Since mail.ru has the strictest DMARC policy, the recepients may
> choose to reject this mail which is relayed by googlegroups, the
> reason is due to DKIM or SPF fails.
>
> So mailing list makes DKIM or SPF failed?
>
> Thank you for your helps.
>
> Regards.
>
The issue is that the way many mailing list work, if a person from a
domain with strict DMARC policy sends a message to the mailing list, and
it is altered in a way that makes it fail DKIM, (and it will fail SPF),
so any attempted recipient from a domain that honors the DMARC policy
will send a reject DSN to the mailing list, which may cause those
recipients to get unsubscribed due to undeliverable mail.

It would seem unfair to punish the recipient for something they didn't
do wrong, sending the reject DSN is the appropriate result. The real
error is arguably the sending of an email to a mailing list from a
domain that by its policies doesn't allow the use of that type of
mailing list.

The typical options for the mailing list are

1) Just not allow people from such domains to post to the list (the
reject option you mention)

2) Rewrite the from address from people from such a domain to be from
the domain of the list (often the list address). This is arguably
discouraged by the email RFCs, as the from address should indicate the
AUTHOR of the message, which is the original sender. It also can cause
problems with identifying who sent the message, and can corrupt peoples
address books if their program records that address as being associated
with the sender. It can also make it harder to reply just to the sender.

3) Rewrite the message by wrapping it as an attachment, with the outer
message being from the list. This has the problem that many clients
won't handle the message in a useful manner.

-- 
Richard Damon

Re: IP addresses in helo

[Richard Damon]

On 11/18/19 8:55 AM, Gregory Heytings wrote:
>
> Hi,
>
>>
>> I know it’s an RFC violation, but I see no email that is delivered
>> with a bare IP helo that is legitimate.
>>
>
> That might be your experience, but RFC 2821 (3.6) and RFC 5321 (2.3.5
> and 4.1.4) explicitly state that an address literal can be used after
> HELO/EHLO.  So it's a RFC violation to reject mail for that sole reason.
I don't believe the RFC has any MUST about the receiver having to accept
any specific message of this kind, thus it isn't an RFC violation to
reject it. (See your next comment quoting the RFC which admit that it is
allowed (if discouraged) for a site to be selective on what mail it accepts.
>
>>
>> How much legitimate mail do you get with an IP helo?
>>
>
> Two other users replied to your question.  For real-world mail
> servers, my experience is that the only safe restriction (safe = no
> false positives) is "reject_unknown_reverse_client_hostname".  With
> other restrictions, your users will never receive emails from
> administrations, schools, hospitals, etc., not even in their spam
> box.  Rejecting mail is an extreme measure, see RFC 5321 (7.9):
> "considerable care should be taken and balance maintained if a site
> decides to be selective about the traffic it will accept and process."
>
> Gregory


-- 
Richard Damon

Re: Postfix with DKIM for a mail relay

[Richard James Salts]

On Thursday, 7 November 2019 4:23:20 AM AEDT Dominic Raferd wrote:
> ...
> The main problem with DMARC is that some mailing lists (not this one,
> I believe) mess it up, so I would suggest not to use it with
> p=quarantine or p=reject on any domain where users are likely to post
> to mailing lists. One such is (or was) the opendmarc mailing list -
> something of an own goal.

Although Wietse has taken steps to minimize the impact of the mailing list on 
DKIM signatures it will depend on the headers that were signed in the original 
message, and this is the best you can expect from a mailing list as most will 
alter the subject or add a footer to the message body. Many other lists have 
taken the decision to work around the damage of poorly considered DMARC 
policies by rewriting the From header and putting the original author's 
address in Reply-to (which isn't without it's downsides given there were 
existing practices about Reply-to and mailing lists). I would highly recommend 
stopping at quarantine for DMARC policy if your domain is anything other than 
a source of transactional emails (e.g. password resets, promotional offers, 
etc). Once real humans have mailboxes on the domain and use the corresponding 
email address in their outgoing mail you're going to have some collateral 
damage from p=reject.

Re: base64 encoded emails

[Richard Damon]

On 10/17/19 4:48 AM, Fourhundred Thecat wrote:
> Hello,
>
> I would like to ask what the Postfix community thinks about base64
> encoded emails.
>
> What is the legitimate reason to use base64 encoded emails ?
>
> Seems to me, it is only being used by spammers to complicate body_checks
>
> Would it be crazy to want to configure Postfix to not accept base64 ?
>
> I believe email should be plaintext. I don't like HTML emails either. If
> somebody feels that his message needs fancy formatting, he should send
> it as pdf attachment. But emails should stay plaintext.
>
> Hypothetically, If I wanted to block base64 and HTML, what would be the
> best way to do it ?
> At what stage in the mail delivery pipeline ?
> for 
> thanks,
>
Email Transport is not always 8 bit clean, so message that use
characters besides ASCII, (like most languages other than English will
need some extra characters) so some method needs to be used to encode
the other characters in a 7 bit way.

There are two basic encoding choices to do this, Quoted-Printable and
Base64. In Quoted-Printable every byte outside of ASCII (and the
character =) is encode as =XX (so with UTF-8 character encoding, every
no-ASCII character becomes 2-4 sets of =XX) where XX is the hex value
for the byte. This leaves the message mostly readable undecoded, but can
greatly expand the size of the message if there are a lot of non-ASCII
characters.

The other encoding is Base64 where every character in the message
encodes 6 bits of the message, so for every 3 byte of content, you
encode it with 4 ASCII characters. This makes the message always longer,
but has a much less worse case expansion.

The use of these transfer encoding can occur even for 'plain text', all
that it requires is that the character set not be ASCII, and HTML
Messages actually have their own ways to avoid needing this sort of
encoding by using HTML entities for the extended characters.

It is also quite possible that the sender didn't chose the encoding
method, and sent out the message as 8-bit (because their mail system
accepts 8-bit messages) and in the transport pipeline it got converted
to being 7 bit clean with Base64 or Quoted-Printable encoding, with the
choice being made in the pipeline.

Optimally, the encoder would chose the best encoding for a given
message, and if that as done Quoted-Printable would likely be chosen for
most message using a Latin Character language, but many encoders will
just fall back to base64 as it is simpler, and Quoted-Printable can be
very bad for some messages.

I would say that for me, I would say that a significant (maybe 10-20%)
of ordinary messages that look to be plain text, are base64 encoded, so
reject them if you are willing to lose that much legitimate email. (And
those messages are full according to the RFCs)

-- 
Richard Damon

Re: Prevent sender address spoofing

[Richard Damon]

On 9/29/19 8:04 PM, Hugo Florentino wrote:
> El vie, 27-09-2019 a las 12:22 -0400, Viktor Dukhovni escribió:
>> [...]
>>
>> This makes no sense.  Portable devices use ports 587 or 465 with all
>> the other providers.  And there's no "change ports constantly", they
>> just use the same submission port.
>>
>> Remote MTAs connect to port 25, submission clients (MUAs) connect
>> to port 587.
>>
> Suppose ISP imposes restrictions so the only port open either for SMTP
> or submission must be TCP 25. What then?
>
>
If an ISP allows you to run a mail server but won't allow access to
587/465 then you need a new ISP with a clue.

Some ISPs will block OUTGOING port 25 to prevent you from being a
spammer, requiring you to use their SMTP server for outgoing SMTP
transport, but I haven't heard of one that blocks 587 or 465 unless they
don't allow you to run servers and just block most server ports.

-- 
Richard Damon

Re: Format of ip address in /etc/postfix/access

[Richard Damon]

On 8/11/19 3:49 AM, Rich Wales wrote:
> The best English phrase to use here would be "unnecessary leading zeroes".
>
> Rich Wales
> ri...@richw.org
>
I suspect that it also doesn't allow embedded spaces or other extraneous
characters (leading 0s and blanks likely being the most common)

-- 
Richard Damon

Re: How to tell my ISP there's a problem

[Richard James Salts]

On Monday, 17 June 2019 7:48:05 PM AEST Chris Pollock wrote:
> Apologies if the subject is vague however I'll attempt to explain
> further. I run a cron job once a day that updates my Spamassassin
> rules. Up until a couple of weeks ago I would get the output of that
> cron job mailed to me. For some reason this is the only cron job output
> that's not coming back. I've determined that size it not a factor since
> some of my hourly logcheck messages are up to 400k if a restart has
> taken place. Below is the output when it was working and the output
> since them. I can't see a difference so it has to be something at my
> ISP with just this one cron job but I can't see it.
> 
> https://pastebin.com/v0rMErQh
> 
> Thanks for any suggestions
Maybe it's going to a spam folder. I notice that the reply from your isp says 
250 SPF validation soft failure in both cases, but if they stopped forwarding 
"potentially forged" emails that might be a possible cause. It is definitely 
the behaviour on smtp.embarqmail.com that has changed though, so you need to 
ask the administrators of that server. Is this direct to MX or is it a fixed 
relay intended to be a smarthost?

Re: Regexp Postfix query doesn't stop at the first matching rule

[Richard Damon]

But if in the message Subject is before From, then the Subject will be
tested before the From header is tested.

The rules process the message, starting from the first header IN THE
MESSAGE, and that gets checked against the rules.
THEN the second header in the message is tested, then the third.
The order of the headers in the message determines the order the rules
are checked.

It does NOT happen that the first rule is tested, sees that it wants a
>From header, and the message is searched for a matching From header. To
do that, you need them to be totally separate passes, not rules within a
single pass.

Your 'first' rule isn't 'skipped', it is that the Subject rule gets
matched first because that is the first header that is being found (from
that sender) that matches a rule, so you never got to the From header
line to test it.

On 6/8/19 11:06 PM, Webmaster wrote:
> Thank you so much for your input, Richard. Appreciate.
>
> Hmm.. Right, this is the way I understand it too. However, my first
> rule that matches the header (from field) is skipped for some reason.
> Then the second rule that matches the header (subject field) is
> applied, not skipped. Now these two rules work fine if they go one by
> one, but they do not work if they go together in combination (tested).
> I am lost..
>
> It looks like REJECT triggers this query match and stops there
> accordingly. However, REPLACE doesn't trigger the query match and the
> search goes on until it "meets" REJECT. In my opinion that's exactly
> what's going on here in my case.. . Is that not right? Am I wrong?
>
>
> -Original Message-
> From: Richard Damon 
> To: postfix-users@postfix.org
> Sent: Sun, 09 Jun 2019 3:57
> Subject: Re: Regexp Postfix query doesn't stop at the first matching rule
>
> I think the sequence (and Wietse can correct me if I am wrong) is that
> the first header in the message is taken, and searched to see if any
> rule matches, if so, that rule is used. If that header doesn't match any
> rule, the next header is gotten and checked against the rules, and so
> on. The first header in the message that matches a rule is the one that
> dominates.
>
> The order the rules are written doesn't matter that much (unless two of
> them might match the same header). It is the order the headers are in
> the message (which you really can't control).

-- 
Richard Damon

Re: Regexp Postfix query doesn't stop at the first matching rule

[Richard Damon]

I think the sequence (and Wietse can correct me if I am wrong) is that
the first header in the message is taken, and searched to see if any
rule matches, if so, that rule is used. If that header doesn't match any
rule, the next header is gotten and checked against the rules, and so
on. The first header in the message that matches a rule is the one that
dominates.

The order the rules are written doesn't matter that much (unless two of
them might match the same header). It is the order the headers are in
the message (which you really can't control).

On 6/8/19 8:16 PM, Webmaster wrote:
> Thank you for replying but I still do not understand it. Are you
> saying that I should swap rules' places? I have already tried that
> before posting my quesion but it doesn't help. The matter is that
> these rules work OK one by one, but when put together the REPLACE rule
> is skipped wheather it comes before or after the other rule.
>
> 1.  REPLACE doesn't work.
> /^From:\s*assistant\@gmail\.com$/ REPLACE Subject: New Report.
> /^Subject:\s*$/  REJECT Empty subjects fields are rejected.
>
> 2. REPLACE doesn't work either.
> /^Subject:\s*$/  REJECT Empty subjects fields are rejected.
> /^From:\s*assistant\@gmail\.com$/ REPLACE Subject: New Report.
>  
> Does it perhaps mean that each email' to, from, subject, and body
> fields are treated as just one single rule, and the query is stopped
> whenever all of these 4 per 1 message are matched?
>
> Any more pointers, please? Many thanks!
>
> Den
>
> -Original Message-
> From: Wietse Venema 
> To: Postfix users 
> Sent: Sat, 08 Jun 2019 19:16
> Subject: Re: Regexp Postfix query doesn't stop at the first matching rule
>
> Den1:
> > Hello,
> >
> > I would be really thankful if someone could clarify it, please. It
> says the
> > following, "Postfix works as documented in regexp_table(5) and
> > pcre_table(5), i.e. each query stops at the first matching rule. Now
> the
> > following two rules are in conflict:
> >
> > /^From:\s*assistant\@gmail\.com$/ REPLACE Subject: New Report.
> > /^Subject:\s*$/  REJECT Empty subjects fields are rejected.
> >
> > I doesn't stop at the first matching rule where the subject is
> replaced.
>
> man header_checks:
>
> DESCRIPTION
>
>    Each message header or message body line is compared against a
> list  of
>    patterns.   When a match is found the corresponding action is
> executed,
>    and the matching process is repeated for the  next  message 
> header  or
>    message body line.
>
> Thus, it stops at the first match. If the Subject line matches first,
> then that rule determines the result.
>
> Wietse


-- 
Richard Damon

Re: How to reject mails where from address and to address is myself.

[Richard James Salts]

On Tuesday, 28 May 2019 9:19:09 PM AEST an...@ursc.gov.in wrote:
> Dear List,
> 
> Lot of SPAM mails are being received where from and to address is
> myself and the mail has contents which are dirty/bad.
> 
> The original sender id will be different.
> 
> How to handle such mails.
The best way is probably a milter of some description.
There are a number that have been mentioned in the past on the postfix mailing 
list that would be suitable (e.g. https://mimedefang.org/, https://
www.amavis.org )

http://www.postfix.org/MILTER_README.html describes the process of plumbing the 
milter into postfix.

Re: Big problem with this mailing list and Majordomo regarding DMARC

[Richard Damon]

On 4/20/19 8:08 AM, Reto wrote:
> On Sat, Apr 20, 2019 at 07:31:06AM -0400, Richard Damon wrote:
>> Where the issue comes is with DMARC, which restricts the DKIM protocol
>> to be aligned with the From line of the message, and thus the MLM can't
>> make the message pass the DMARC settings of the sending domain. It is
>> DMARC which breaks the traditional operation of a MLM, and the use of
>> which implies that the sender should not be using such tools.
> Now that's a bit dramatic isn't it?
> A mailing list *can* work with dmarc just fine if it doesn't modify the 
> protected headers.
> That doesn't seem to be particularely complicated assuming Headers like 
> List-Unsubscribe et al can still be added.
>
> Just don't modify the subject and the body and you should be fine.
>
One issue is that some legal advisors will state that List-Unsubscribe
might not be good enough to meet the requirements of clearly visible
unsubscription instructions since it is NOT required that a MUA handle
that header in any particular manner if at all. That means that to
clearly meet the legal requirement in those those jurisdiction must
break the DKIM signature.

Mailing list also have traditionally modified other headers, like
Reply-To to make replies by default to go to the list, and frequently
the subject to allow for easy filtering of the messages from the list on
MUAs that may be somewhat limited in their filtering capability. This
was common existing practice, which DKIM acknowledged and provided for
by allowing resigning aligned to the Sender, but DMARC broke.

To meet the Mail RFCs the Mailing list should modify the Sender: field,
so if that was signed (as was pointed out is recommended by DKIM) the
signatures will be broken, and since DMARC requires alignment to From:
(which the RFCs says should be the Author of the message, so should be
the original sender), a MLM manager can be forced to break some RFC to
be able to deliver the message.

DMARC by itself isn't that bad, as the original intent was, at least in
part, to protect transactional emails, and those should generally not go
through the sort of system that have issues with it. The issue with
DMARC was its adoption by mailing services that did not meet that model,
and who did not inform their users of the implied restrictions on their
users of the use of those services (and some [yahoo] even ran their own
competing MLM service that for their users could 'cheat' and sign the
modified messages).

When the issue first came up, there was a move to ask the operators of
mailing lists to just tell their subscribers from the domains that
adopted the abusive settings that caused the issues that they were no
longer allowed to post through the list (since that IS the real meaning
of a strict DMARC setting), but it was decided that such a move would
just be a punishment on the innocent and less technically competent
user, and not those that ran the domains.

There are still people who propose that to demonstrate the issue, that
all MLM should be setup to automatically reject any message, and not use
a RFC-incompliant workaround (like munging From:) that would create a
DMARC exception, and some go as far as suggest that the rejection
message should also be copied to the DMARC team to show them the extent
of their breakage of the Mail System.

-- 
Richard Damon

Re: Big problem with this mailing list and Majordomo regarding DMARC

[Richard Damon]

On 4/19/19 11:22 PM, Bill Cole wrote:
> On 19 Apr 2019, at 22:50, Richard Damon wrote:
>
>> Note also, these RFCs are just Standards Track, which says that they are
>> not yet 'full standards' but still evolving, and I believe that one of
>> the issues that needs to be worked out is to figure out how to improve
>> their interoperability for general emails with traditional mailing lists.
> Sadly, no. See https://www.rfc-editor.org/info/std76
>
Remembering more clearly, it isn't DKIM itself that causes problems, as
the system with the MLM could easily resign the messages using the
sender domain which is specifically allowed.

Where the issue comes is with DMARC, which restricts the DKIM protocol
to be aligned with the From line of the message, and thus the MLM can't
make the message pass the DMARC settings of the sending domain. It is
DMARC which breaks the traditional operation of a MLM, and the use of
which implies that the sender should not be using such tools.

-- 
Richard Damon

Re: Big problem with this mailing list and Majordomo regarding DMARC

[Richard Damon]

On 4/19/19 10:04 PM, Peter wrote:
> On 19/04/19 11:16 PM, Nick wrote:
>> You might want to consider reducing the list of headers in your DKIM
>> signatures.  E.g. your signed-headers list includes 'sender' but the
>> mailing list adds its own 'sender', which is enough to invalidate your
>> signature.
>
> This is going to be an ongoing problem because RFC6376 actually
> recommends including the Sender header:
>
> From 5.4 INFORMATIVE OPERATIONS NOTE:
>
> "For this reason, signing fields present in the message such as Date,
> Subject, Reply-To, *Sender*, and all MIME header fields are highly
> advised." (emphasis mine)
>
If you look at the background behind DKIM, one of the major impetuses
was protecting transactional emails, and protection from attacks like
phishing. For these sorts of emails, that stricter protection makes
sense. These sorts of emails also aren't sent through mailing lists.

Effectively, if you decide to use DKIM to protect your domain's outgoing
email, then you really need to tell your users about the issue with
mailing lists, as the choice to use DKIM basically says that most
mailing list should be off limits to your users, as it is very common
for mailing lists to break the DKIM signature, so it really is YOUR
problem to adjust your DKIM settings and Authorized Usage Policy to make
your system work for your users. I have to regularly tell users of a
mailing list that I run that the reason the list removes their email
address out of the From: field is that they are using a broken email
system that isn't compatible with the use of mailing list.

Note also, these RFCs are just Standards Track, which says that they are
not yet 'full standards' but still evolving, and I believe that one of
the issues that needs to be worked out is to figure out how to improve
their interoperability for general emails with traditional mailing lists.

-- 
Richard Damon

Re: Big problem with this mailing list and Majordomo regarding DMARC

[Richard Damon]

On 4/19/19 12:00 PM, Benny Pedersen wrote:
> Scott Kitterman skrev den 2019-04-19 17:48:
>
>> I'd suggest reading RFC 6376, Section 5.4 (Determine the Header
>> Fields to
>> Sign) [1] directly.  I think it's advice holds up reasonably well.
>
> thanks for link, its just that mailman breaks that rfc then, if
> changing reply-to
>
Or that RFC break Mailman, and many other long established methods of
operation for mailing list.

>From what I have seen from DKIM is that domains that implement it really
should be required to tell their users that they should not be using any
remailing service (like most mailing list) that don't adhere to some new
DKIM rules,  needed to avoid breaking the DKIM signature, even though
following these rules will break some traditionally provided features,
and may even force the list to break some laws (laws on mass mailings
that REQUIRE instructions on how to unsubscribe be included in the message)

-- 
Richard Damon

Re: Forwarded mail problem

[Richard Damon]

On 2/1/19 9:41 AM, Enrico Morelli wrote:
> Dear all,
>
> I having some problem forwarding some emails to Gmail addresses.
> Sometime the emails are bounced cause:
>
> This message does not have authentication information or fails to pass
> 550-5.7.1 authentication checks. To best protect our users from spam,
> the 550-5.7.1 message has been blocked. Please visit 550-5.7.1
> https://support.google.com/mail/answer/81126#authentication for more
> 550 5.7.1 information. k11si3359248wrp.39 - gsmtp (in reply to end of
> DATA command))
>
> I'm sure that these emails aren't spam.
>
> Someone can explain me why? Is there some misconfiguration in my mail
> server? 
>
> Thanks
>
If your forwarding method keeps the From line of the original message,
then if that domain uses SPF, then Google will see that your system
wasn't authorized to send email for that domain. (If they also signed
the message with DKIM, it likely would make it through).

The solution is that when you forward email from domains you don't
control to a domain you don't control, you need to at least re-write the
from address to something you control, otherwise it looks too much like
possible scamming.

-- 
Richard Damon

Re: Rethinking the Postfix release schedule

[Richard Damon]

On 1/30/19 4:45 PM, Viktor Dukhovni wrote:
>> On Jan 30, 2019, at 4:39 PM, Patrick Ben Koetter  wrote:
>>
>> Why wait for a group of features before a release? Why not release per
>> feature?
> Because people want a reasonable period of support for released code.
> And we can only support a small handful of releases.  So increasing the
> release cadence to two per year would limit the bugfix lifetime of each
> release to 2 years instead of four.
>
> I think a compromise is that we should be free to release major features
> at any six month boundary, but June/July releases would be skipped if
> we had nothing major in the pipeline.  That way we'd have up-to 2 releases
> per year, but perhaps still have only one release per year some of the time.
>
Another option would be to designate certain releases as 'LTS', which
would have support for a given number of years, and others have more
limited support (like for only a limited time after any subsequent
release). Make only 1 LTS per year, and then you have 3 years from 3 LTS
releases + 1 most current release.

-- 
Richard Damon

Re: More secure postfix

[Richard Damon]

On 12/22/18 4:26 PM, Philippe - Forums wrote:
>
> Yes, with this option I can't send an email with my smartphone,
> because the smartphone IP have not proper reverse DNS.
>
> And there is my problem: reject all IPs without proper reverse DNS but
> accept my smartphone.
>
And what is special about your phone that postfix should use to allow
it, but not other IPs?

-- 
Richard Damon

Re: Since 3.4 upgrade, no incoming mail to server is allowed in?

[Richard]

> Date: Friday, November 30, 2018 07:54:08 -0700
> From: rachalmers 
>
> Well, I can't see what's happening here. 3.4 isn't presenting me
> with mail.logs on the Mac. Mojave.
> Internally, I can send mail to myself, but I now no longer get mail
> from outside?
> 
> Sending to myself
> /usr/sbin/sendmail -bv  works. It's all internal
> 
> Sending to anything outside kind of works - it gets blocked.
> /usr/sbin/sendmail -v  is being blocked because my ISP has
> the entire net-block in spamhaus.RBL
> I can't yet see a way around that!
> 
> *But more importantly - nothing appears to be getting in from
> outside to me on the server.*
> 
> As i said - no mail logs at all for some reason.
> No incoming mail at all for some reason.
> 

I believe that a likely reason for your logging problem has been
discussed already.

The RBL issue is ISP, not postfix, related (i.e., upgrading your
postfix version wouldn't have changed that).

Regarding no incoming mail ... are you on a static or dynamic IP
assignment?

Have you tried to telnet to port 25 on your server *from outside your
network* to see if/how it responds?


- Richard

Re: Convert quoted-printable headers

[Richard Damon]

On 11/24/18 4:12 PM, Benny Pedersen wrote:
> André Rodier skrev den 2018-11-24 15:41:
>> ---
>> From =?utf-8?q?Andr=C3=A9?= Rodier 
>> To =?utf-8?q?Andr=C3=A9?= Rodier 
>> ---
>
> is unicode done first ?, if so quoted-printable encoding only see 7bit
> content
>
> or is quoted-printable encoding done first so unicode only encode 7bit
>
> both loose then, and many clients fail to do the decode parts of it
>
> same problem exists in html emails, if it just was html we did not
> need unicode or quoted-printable encoding at all
>
> i find unicode a joke :)
>
UTF-8  is not an 'encoding' per the mail RFC, but a character set. UTF-8
is a character set, so the e with accent at the end of André becomes 2
8-bit characters for QP, which is the =C3=A9 in the name. Encodings in
the mail RFC is a method to convert 8 bit messages into something 7 bit
clean.

Yes, if the only characters in the message can all be expressed in an 8
bit character set then you could make the message a bit smaller using
that instead of UTF-8, since the upper characters will only need a
single encoding instead of 2. If you might be using characters beyond an
8-bit character set, then UTF-8 is the best way to go.

Message bodies are a bit simpler, as you use a single content encoding
header for the whole body, and a lot of systems actually are 8-bit clean
so you can just use encoding 8bit, and let a MTA make the translation if
it hits a hop that isn't 8 bit clean.

Unicode isn't prefect, but it is the best we have for a single global
character set. If you mostly just need the basic Latin characters, it is
much more than you need, but once you need things beyond that it shows
its abilities.

-- 
Richard Damon

Re: Convert quoted-printable headers

[Richard Damon]

On 11/24/18 10:24 AM, André Rodier wrote:
> On 2018-11-24 15:16, Richard Damon wrote:
>> On 11/24/18 9:41 AM, André Rodier wrote:
>>> Hello,
>>>
>>> I have a program (SOGo), installed on my mail server, that send emails
>>> using the quoted-printable encoding for From/To headers.
>>>
>>> Unfortunately, none of the email clients I use seems to display them
>>> correctly:
>>>
>>> ---
>>> From =?utf-8?q?Andr=C3=A9?= Rodier 
>>> To =?utf-8?q?Andr=C3=A9?= Rodier 
>>> ---
>>>
>>> Is there any reason for that ?
>>> is a header missing:
>>>
>>> Thanks for your help
>>>
>>> André Rodier
>>>
>> First, are your clients compliant with the RFC that define encoding of
>> headers (which are later/less supported than those that define the
>> encoding of the body)?
>>
>> For example, RFC 2047  (I think the latest RFC that defines this
>> encoding). I don't think you need any header to enable this support,
>> just a compliant MUA.
>
> Thanks for your answer.
>
> I would think it is a bug in the SOGo software, because other emails
> are using quoted-printable too, but are displayed correctly, for
> instance this one:
>
> 
> Return-Path: 
> Received: from osaka.rodier.me
> by osaka.office.pmc with LMTP id 0P2UH/1p+VvAFAAAnYgw/w
> ; Sat, 24 Nov 2018 15:10:53 +
> Received: from osaka.rodier.me (localhost [127.0.0.1])
> by osaka.rodier.me (Postfix) with ESMTP id 6406A2063B
> for ; Sat, 24 Nov 2018 15:10:53 + (GMT)
> Received: by osaka.rodier.me (Postfix, from userid 132)
> id 431B720662; Sat, 24 Nov 2018 15:10:53 + (GMT)
> Content-Type: text/html; charset="utf-8"
> To: =?utf-8?q?Andr=C3=A9_Rodier?= 
> MIME-Version: 1.0
> Date: Sat, 24 Nov 2018 15:10:53 +
> Subject: The event =?utf-8?q?=22Hello=22?= was created
> Message-ID: <1403-5bf96a00-5-79d0b280@98295310>
> From: =?utf-8?q?Andr=C3=A9_Rodier?= 
> X-AV-Checked: ClamSMTP (Client IP: 127.0.0.1)
> 
>
> Fortunately, Thunderbird, Evolution and Roundcube are behaving the same.
>
>
I use Thunderbird myself, and your message displays fine. The one
difference I see is that the character set and encoding in your mail
client is coming in upper case, while the example has it in lower case.
I thought the RFC said that this was case insensitive, but maybe some
implementations are case sensitive.

-- 
Richard Damon

Re: Convert quoted-printable headers

[Richard Damon]

On 11/24/18 9:41 AM, André Rodier wrote:
> Hello,
>
> I have a program (SOGo), installed on my mail server, that send emails
> using the quoted-printable encoding for From/To headers.
>
> Unfortunately, none of the email clients I use seems to display them
> correctly:
>
> ---
> From =?utf-8?q?Andr=C3=A9?= Rodier 
> To =?utf-8?q?Andr=C3=A9?= Rodier 
> ---
>
> Is there any reason for that ?
> is a header missing:
>
> Thanks for your help
>
> André Rodier
>
First, are your clients compliant with the RFC that define encoding of
headers (which are later/less supported than those that define the
encoding of the body)?

For example, RFC 2047  (I think the latest RFC that defines this
encoding). I don't think you need any header to enable this support,
just a compliant MUA.

-- 
Richard Damon

Re: OT: Sender header vs DKIM

[Richard James Salts]

On Friday, 26 October 2018 12:53:48 AM AEDT Scott Kitterman wrote:
> On October 25, 2018 10:56:53 PM UTC, Richard James Salts 
 wrote:
> >Hi all,
> >
> >This is offtopic in regards to postfix but I bring it up because of the
> >last
> >few emails I've sent to the postfix mailing list.
> >
> >I was originally signing all the headers mentioned in rfc6376 section
> >5.4,
> >whether they existed or not and mails to postfix mailing list failed
> >because of
> >the added List-* headers. I fixed that up so that it will only sign
> >those
> >headers when they exist. I now oversign only the From, Sender,
> >Reply-to,
> >Subject, Date, Message-id, To, CC, MIME-Version, Content-Type, Content-
> >Transfer-Encoding, Content-ID, Content-Description,
> >Content-Disposition, In-
> >Reply-To and References.
> >
> >This is still leading to the postfix mailing list failing DKIM once
> >it's added
> >a Sender header for owner-postfix-us...@postfix.org. Should I stop
> >oversigning
> >the Sender header? rfc5322 says the Sender header is unique if it
> >exists so if
> >there was a sender header would the postfix maling list strip it and
> >add it's
> >own? Should majordomo at russian-caravan be adding a Resent-From or
> >Resent-
> >Sender instead of Sender in order to prevent breaking the DKIM
> >signatures for
> >final recipients of people who include a signed Sender header?
> >
> >Your thoughts and opinions on this would be welcomed.
> 
> I think you are making are poor assumption that the RFC 6376 should sign
> header fields are at related to should over sign.
> 
> I've never before heard of anyone over signing anything except From.  I
> wouldn't over sign anything else.  Section 8.15 discusses this.  As you're
> discovering, over application of this mitigation brings it's own pain.

I was basing the oversigning on discussion at https://noxxi.de/research/
breaking-dkim-on-purpose-and-by-chance.html where they reused and manipulated 
existing dkim signed emails to send "valid" bogus emails. It does mention that 
the Sender header should be signed, but I'm not sure how useful it is in 
practise or whether it needs to be oversigned.

> 
> Scott K