I've dmarc configured to send out reports to those domains, that have dmarc
configuration too.
A lot of those are misconfigured in one way or another.
Mostly the mailaddress stated in DNS is not accepting my mails or is not
existent at all.
But some have got their mailserver misconfigured
Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users:
measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org
I was able reproduce a crash sending mail to that address, without
needing any smtp_tls_policy_maps plugin stuff.
I was unable to reproduce a segfault. pos
I would like some opinions on how certain RFCs are to be interpreted.
My core question is: Is it possible to send mail RFC-conformly into a
Postfix, such that there are more than 1000 consecutive Non-CRLFs?
I think everybody agrees that this is not possible with DATA. The
BDAT_README seems to
Postfix supports 8bit Data, with lines of 998 between CRLF, as
defined inhttps://datatracker.ietf.org/doc/html/rfc2045#section-2.8
Therefore, Postfix announces 8BITMIME in EHLO.
Postfix does not support Binary Data, as defined in
https://datatracker.ietf.org/doc/html/rfc2045#section-2.9 Binary
Th
Postfix supports 7bit data, with lines of 998 between CRLF, as
defined in https://datatracker.ietf.org/doc/html/rfc2045#section-2.7
This is non-negotiable, and is not announced in EHLO.
Postfix supports 8bit Data, with lines of 998 between CRLF, as
defined in https://datatracker.ietf.org/doc/html
You may have noticed that BDAT and BINARYMIME are distinct features.
For reasonable people, both must be supported if one wants to send
content other than lines with 998 bytes before CRLF.
For other people, BINARYMIME is some kind of mistake, and BDAT alone
is sufficient to send content other tha
Your last two statements are exactly the crux of the matter, and I don't see
them justified, yet.
And yet they are justified. Wishful thinking does not change that. 🙁
Absent BINARYMIME the body time of a BDAT message is 8BITMIME, which is
still line-oriented.
If they are justified, then not by R
On Mon, Feb 17, 2025 at 04:10:30PM +0100, Damian via Postfix-users wrote:
> > Systems that do not announce BINARYMIME in EHLO can receive only
> > content with lines of 998 between CRLF.
> >
> > Only systems that anounce BINARYMIME in EHLO can receive content
> > that is not lines of 998 between
[An updated version of this announcement will be available at
https://www.postfix.org/announcements/postfix-3.10.0.html]
Postfix stable release 3.10.0 is available. Postfix 3.6 - 3.9 were updated
earlier this week; after that, Postfix 3.6 will no longer be updated.
The main changes are below. See
?mer G?ven via Postfix-users:
> At the end, fixing any possible segfault makes the smtp process
> more stable. It re-queued the same mail 6-7 times before the fix,
Given that Andreas and I were unable to reproduce this without some
amount of tweaking, the impact of failure is easily over-stated.
A
Totally agree! Thanks for finding the tiny typo and fixing though!
> Am 17.02.2025 um 20:51 schrieb Wietse Venema via Postfix-users
> :
>
> ?mer G?ven via Postfix-users:
>> At the end, fixing any possible segfault makes the smtp process
>> more stable. It re-queued the same mail 6-7 times befor
On 2/12/2025 11:22, Wietse Venema via Postfix-users wrote:
Jim Garrison via Postfix-users:
I have a Postfix server that does outbound-only relay in a small network
via a smarthost. There is no incoming mail (so no Dovecot), and
outbound is restricted to a very small set of clients.
The relay h
At the end, fixing any possible segfault makes the smtp process more stable. It
re-queued the same mail 6-7 times before the fix, and the crashing process
resulted in delayed sending to the „correct“ recipients (because they were in
Cc/Bcc). As expired certificates do appear in real-world scenar
Well, you could try removing „reject_unknown_recipient_domain“ from the mua
restrictions. This will accept invalid domains during „Reply All“. But
according to Wietse, he was able to reproduce it with no extraordinary
configuration. For me fixing the typo (8 to 0) solved the problem.
> Am 17.02
A. Schulze via Postfix-users:
>
>
> Am 16.02.25 um 19:11 schrieb Wietse Venema via Postfix-users:
> measurem...@mail-mtasts-rn-mult-ivv.measurement.email-security-scans.org
> >
> > I was able reproduce a crash sending mail to that address, without
> > needing any smtp_tls_policy_maps plugin
You may have noticed that BDAT and BINARYMIME are distinct features.
Yes, but I have argued that RFC2045 compliance of mail data is a property of said data, not of the transport, so that BDAT,
BINARYMIME and even SMTP don't actually matter. RFC2045 has references to RFC821 because it was design
16 matches
Mail list logo
