Re: [mailop] Samsung and SIZE

[Bastian Blank via mailop]

On Sat, Jan 13, 2024 at 07:44:22PM +, Slavko via mailop wrote:
> Dňa 13. januára 2024 19:14:58 UTC používateľ Sebastian Nielsen via mailop 
>  napísal:
> >Then you need to reconfigure server to ignore said parameters.
> IMO, in other words, server (SHOULD reject) is  RFC compliant, client
> is not (MUST NOT send).

Also section 4.5.3.1.7:

| SMTP server systems that must impose restrictions SHOULD implement the
| "SIZE" service extension of RFC 1870

So support for SIZE is kind of mandated since 15 years.

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Bastian Blank via mailop]

Hi Tim

On Thu, Jan 11, 2024 at 05:02:01PM -0600, Tim Starr via mailop wrote:
> The image has to be specified in the DNS, and it has to be certified w/ a
> VMC. The VMC certification process includes checking if it's trademarked.

That's why the process started with: get a trademark.  Also such a check
is manual work, so pretty weak.

I found
https://datatracker.ietf.org/doc/html/draft-fetch-validation-vmc-wchuang,
which seems reasonably okay.  Just the requirement to use HTTPS to fetch
such a document and use CRL stand out.

And to answer my other question:  The VMC certificate actually embeds
the image itself.

Bastian

PS: Please don't send me copies of e-mails.  I explicitly set
Mail-Followup-To in mine.
-- 
Immortality consists largely of boredom.
-- Zefrem Cochrane, "Metamorphosis", stardate 3219.8
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: BIMI boycott? Lookup tool, why we publish BIMI anyway, and intellectual property law considerations

[Bastian Blank via mailop]

On Thu, Jan 11, 2024 at 01:45:19PM -0600, Tim Starr via mailop wrote:
> To elaborate on Marcel's answer, so he doesn't have to waste time
> explaining it all over again, the "different logo" won't be displayed by
> the mailbox providers, because it's not the authenticated one.

What prohibits them from making it authenticated?  A trademark check?

Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ECDSA DKIM validation?

[Bastian Blank via mailop]

On Tue, Dec 19, 2023 at 10:21:55AM +0200, Taavi Eomäe via mailop wrote:
> Considering how Gmail and quite a few widespread DKIM implementations still
> don't support EdDSA DKIM, I wouldn't get my hopes too high.

Please note that ECDSA != EdDSA.  And EdDSA stuff only turned up in FIPS
a short while ago.  Some organizations are really reluctant to implement
stuff not showing up there.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

[Bastian Blank via mailop]

Hi

On Wed, Jul 12, 2023 at 01:00:43AM +0300, Taavi Eomäe via mailop wrote:
> On 11/07/2023 20:43, Bastian Blank via mailop wrote:
> > Given that this host only reacts on port 25 but not on port 587, I
> > assume this is MX.
> Ideally one would offer implicit TLS on port 465 as well (RFC8314).

But this RFC talks about submission of e-mail, exactly not what this
thread is about.

> > You are talking about MX, which is unauthenticated in the absence of DANE.
> There's also MTA-STS, which doesn't rely on DNSSEC and introduce operational
> complexity.

This, the same way as DANE, asks the client to do authentication.  So it
is not included in my statement.  And in that case the client enforces
more strict rules normally.

Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

[Bastian Blank via mailop]

Hi

On Tue, Jul 11, 2023 at 05:47:12PM +0200, Paul Menzel via mailop wrote:
> Testing the mail setup, I was surprised to have the key exchange parameters
> flagged [1]:
> > a1241.mx.srv.dfn.de.DH-2048 insufficient

This test is for web or e-mail?  MX or MSA?

Given that this host only reacts on port 25 but not on port 587, I
assume this is MX.

> Mozilla’s SSL Configuration Generator also suggests for *Intermediate* and
> *Old* [3]:
> # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
> # not actually 1024 bits, this applies to all DHE >= 1024 bits
> smtpd_tls_dh1024_param_file = /path/to/dhparam

This generator is for web and other authenticated use.  You are talking
about MX, which is unauthenticated in the absence of DANE.

For unauthenticated MX use you want to allow as much encrypted
communication as possible.  So don't disable TLS 1.0 or weak ciphers,
clients will otherwise just downgrade to plaintext and make it worse.

So if you are not ready to also cut off plaintext connections overall,
don't touch it too much.  Clients will often restrict itself to more
modern settings anyway.

> Have most of you moved to ECDHE? If not, are you using the predefined finite
> field groups specified in RFC 7919 [5]?

Every current system supports ECDHE, so sure.  The original DH is dead,
because it's just too slow.

Bastian

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Bastian Blank via mailop]

On Tue, Mar 07, 2023 at 01:29:37PM -0500, David Sovereen via mailop wrote:
> > On Mar 7, 2023, at 12:54 PM, Bastian Blank via mailop  
> > wrote:
> > On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:
> >> I’m trying to reach someone at bell.ca <http://bell.ca/> who can help us 
> >> with two inter-related issues.
> > Why do you link to http://bell.ca/?  Or is that some unhelpful client
> > again?
> Yes, an unhelpful mail client.

And one that ignores the "Mail-Followup-To" header.

Please note that people on mailing lists usually don't want a personal
reply.  It is even considered rude, as this circumvents the filter that
moves mail into a different inbox.

> My apologies.  I was trying to get an email out quickly before running to a 
> meeting and completely mischaracterized the problem.  The problem is that the 
> *client* disconnects before receiving 250 OK.  Here’s a log:

> [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] cmd: DATA
> [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] Performing PTR host name 
> lookup for 204.101.223.59
> [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] PTR host name for 
> 204.101.223.59 resolved as esa2-dor.bell.ca
> [2023.03.06] 13:43:28.763 [204.101.223.59][57867550] rsp: 354 Start mail 
> input; end with .
> [2023.03.06] 13:43:28.810 [204.101.223.59][57867550] senderEmail(2): 
> redac...@bell.ca parsed using: “Redacted” 
> [2023.03.06] 13:43:28.810 [204.101.223.59][57867550] Sender accepted. Weight: 
> 4. Block threshold: 36. Failed checks: _SPF (4,None)
> [2023.03.06] 13:45:33.408 [204.101.223.59][57867550] rsp: 421 Command 
> timeout, closing transmission channel

421 is a hard error.  You must close the connection and abort the
transaction.  The client will not hear anything after that and retry.

> [2023.03.06] 13:45:33.408 [204.101.223.59][57867550] disconnected at 3/6/2023 
> 1:45:33 PM
> [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] rsp: 250 OK

This is bullshit.  After a disconnect, no transaction exists and no 250
reply can happen.

> [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Client socket is 
> disconnected! Disconnect exception encountered: True, IsDisconnected: True, 
> This message will still be accepted.
> [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Received message size: 
> 17588 bytes
> [2023.03.06] 13:48:59.847 [204.101.223.59][57867550] Successfully wrote to 
> the HDR file. (d:\mail\spool\SubSpool9\1391309161820.hdr)
> 
> If we accept delivery as we did here where they disconnect before we send 250 
> OK, the message gets delivered to our end user.  But the end user sometimes 
> gets duplicate messages, sometimes many duplicate messages.  If we don’t 
> accept messages from clients that stay connected until the 250 OK is given, 
> no bell.ca emails get through.

You are running into timeouts.  You have network problems or
synchronization issues.  Now you need to look at a real dump.  Use
wireshark.

Bastian

-- 
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
   stardate 3468.1.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Bastian Blank via mailop]

On Tue, Mar 07, 2023 at 06:54:31PM +0100, Bastian Blank via mailop wrote:
> What are you doing?  Please show a session transcript if you think there
> are SMTP protocol problems.

Okay, he seems to be mercury.net.

| ;; ANSWER SECTION:
| mercury.net. 2975 IN MX 10 mail.mercury.net.
| mercury.net. 2975 IN MX 20 mail.lsol.net.

Let's see what mail.mercury.net is.

| $ nc mail.mercury.net. 25
| 220 mail.mercury.net
| ehlo test


Okay, while correct, it does only accept CRLF.  Almost all servers
accept bare LF.

| $ nc mail.mercury.net. 25 -C
| 220 mail.mercury.net
| ehlo test
| 250-mail.mercury.net Hello [x.x.x.x]
| 250-SIZE 69905066
| 250-AUTH LOGIN CRAM-MD5
| 250-STARTTLS
| 250-8BITMIME
| 250-DSN
| 250 OK
| mail from:<>
| 554 Sending address not accepted due to spam filter
| mail from:


- No ESMTP marker.
- Can anyone point me to the RFC for the SMTP extension "OK"?
- Rejects empty from.
- Yes, t...@test.de is no existing address.

Bastian

-- 
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
   stardate 3468.1.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Bell.ca servers disconnecting before QUIT

[Bastian Blank via mailop]

Hi David

On Tue, Mar 07, 2023 at 12:26:41PM -0500, David Sovereen via mailop wrote:
> I’m trying to reach someone at bell.ca  who can help us with 
> two inter-related issues.

Why do you link to http://bell.ca/?  Or is that some unhelpful client
again?

> 1.  Their SMTP servers send mail without a QUIT.  If we require a QUIT, our 
> users cannot receive any bell.ca  mail.

SMTP servers don't send e-mail, they receive e-mail.  You mean SMTP
client.  However an e-mail transaction ends with ..  So at
the time QUIT would be sent, no e-mail transaction is running.

> 2.  If we accept without a QUIT, our users occasionally get duplicate 
> messages and sometimes LOTS of duplicate messages.

What are you doing?  Please show a session transcript if you think there
are SMTP protocol problems.

Bastian

-- 
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Does gmail accept unicode character in From domain? I don't think so

[Bastian Blank via mailop]

On Thu, Mar 02, 2023 at 04:38:16PM -0700, Alex Burch via mailop wrote:
> I am using unicode in the From: not the MAIL FROM. Do you have to specify
> it SMTPUTF8 in the MAIL FROM to use it in the From header? I don't see
> anything about that here: https://www.rfc-editor.org/rfc/rfc6531

Without SMTPUTF8 no standard allows unicode in the e-mail address in
headers.

> I was under the impression that if the client offered SMTPUTF8 extension
> then you could go ahead and use unicode in the headers like From.

No.

| If the envelope or message being sent requires the capabilities of
| the SMTPUTF8 extension, the SMTPUTF8-aware SMTP client MUST supply
| the SMTPUTF8 parameter with the MAIL command.

Bastian

-- 
You canna change the laws of physics, Captain; I've got to have thirty minutes!
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Not-in-dane/mta-sts mx for tls fallback

[Bastian Blank via mailop]

Hi Jasper

On Tue, Feb 21, 2023 at 08:40:06AM +0100, Jasper Spaans via mailop wrote:
> At StartMail we've recently changed our incoming MXes to only allow
> TLSv1.2 and 1.3 on incoming connections - but because there are still
> some legitimate sources of mail that only support TLSv1 or 1.1 we've set
> up a fallback mx that also supports TLSv1 and TLSv1.1.

Could you explain what you think you gain from restricting TLSv1?  I
don't think you restrict unencrypted connections?  So it can't be
downgrade attacks, as unencrypted is the ultimate downgrade attack.

> The idea here is that an outdated (or misconfigured) server tries to
> connect to our regular MXes, fails to negotiate in the starttls phase
> and then retries with a lower priority server which does allow a
> successful starttls negotiation.

I see four MX, aka at least eight address records (A and ).  This is
more then for example Postfix is willing to use.  The default is set to
five.

I know someone who tried something similar:
- four MX
- only the last two reachable on the public internet

They lost quite some e-mail.

> This fallback MX however is not listed in our MTA-STS thing nor does it
> have DANE records, so sending parties that care about that should not
> connect to it and are not exposed to the dangers of downgrade attacks.

Both DANE and MTA-STS require the enforcement of modern encryption and
authentication on _client side_, so servers are not involved into
enforcing them.

But now you have MX, which look like they don't belong there.  We don't
monitor that, but those who do will now consider your domains insecure,
because someone intercepts stuff.

> Parties that don't care about DANE/MTA-STS but do support modern TLS may
> be tricked into connecting to the backup mx and be at risk of a
> downgrade attack, but if you ask me, that is a small price to pay for
> allowing people with outdated stacks to use any form of TLS instead of
> having to fall back to plaintext.

If an attacker can downgrade, then it can downgrade to plaintext without
anyone noticing.  So again, no gain.

> Did we miss something or should I start chasing down folks to improve
> their tools?

Maybe you should describe where the RFC explicitly tells that you are
allowed to do that.  They are usually written in a way that assumes
equal management through out the fleet.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Verizon's SMS to Email Features.. broken?

[Bastian Blank via mailop]

Hi

On Tue, Dec 27, 2022 at 04:46:31PM -0800, Michael Peddemors via mailop wrote:
> From:ph...@vzwpix.com
> ^^^ Borked, no padding space after from

Where in RFC 5322 does it require that space?

| from=   "From:" mailbox-list CRLF
| mailbox-list=   (mailbox *("," mailbox))
| mailbox =   name-addr / addr-spec
| addr-spec   =   local-part "@" domain
| local-part  =   dot-atom
| dot-atom=   [CFWS] dot-atom-text [CFWS]

> Subject:
> ^^^ Borked, I get that SMS has no subject, but they could at least put a
> default subject in for the reader.. eg [SMS TO EMAIL] Please see message
> body for details

Where in RFC 5322 does it require a non-empty subject?

| subject =   "Subject:" unstructured CRLF
| unstructured=   (*([FWS] VCHAR) *WSP)

> Message-ID: <212537817739177423@-212537817739177424>
> ^^^ Borked, the domain part should not start with a hyphen

Message-ID is specified pretty loose.  The right part should be a
domain, but this is not part of the formal spec.

> Date: Wed, 14 Dec 2022 22:42:19 +
> MIME-Version:1.0
> Content-Type: multipart/mixed;
>  type="application/smil";
>  boundary="__CONTENT_64564_PART_BOUNDARY__33243242__"
> 
> Okay.. interesting choice.. however email clients might not get that
> application type..

multipart/mixed is clear enough.

> Who writes these things? Oh, and you MIGHT consider trying SSL negotiation
> while sending..

This software might be decades old and unmaintained.

Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus DNS issues causing all incoming mail to drop for me

[Bastian Blank via mailop]

On Thu, Nov 03, 2022 at 10:59:22AM -0500, Brian Knight via mailop wrote:
> I'm seeing DNS issues this morning connecting to sbl.spamhaus.org.
> 
> This morning, my Postfix server was rejecting all incoming emails as spam.
> Found that the A record for sbl.spamhaus.org is gone, replaced with SOA and
> NS records that look a bit odd.

You seem to missunderstand RBL.  The correct way to test this RBL is via
a lookup for "2.0.0.127.sbl.spamhaus.org", which is also listed in the
FAQ at https://www.spamhaus.org/faq/section/DNSBL%20Usage.

> Queries direct to the NS servers return the same result. Queries via AWS and
> Comcast return the same result also.

And you always need your own DNS recursor to query RBL.

Bastian

-- 
Vulcans do not approve of violence.
-- Spock, "Journey to Babel", stardate 3842.4
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Office365 blocking non Oauth2 authentication on IMAP and SMTP.

[Bastian Blank via mailop]

On Fri, Aug 19, 2022 at 10:19:55AM -0500, Mike Hammett via mailop wrote:
> Down with big mail! ;-) 

As you seem to be unable to properly quote e-mails, but write them
without showing what you refer to?

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bastian Blank via mailop]

Moin

On Thu, Aug 04, 2022 at 12:51:29AM +0100, Stuart Henderson via mailop wrote:
> I think when acting as SMTP-over-TLS clients, most MTAs out there are
> not checking the server's certificate in any really meaningful way; they
> can usually be configured to do so but, last time I looked, there were
> plenty of expired certs, mismatching host names, and self-signed certs,
> and based on what I've seen with web servers I'd expect to see more than
> a few with valid CA-signed certs, but with no chain cert presented.
> Turning this on for general use (rather than for specific destinations)
> would seem likely to result in a lot of failures.

And even if you had verifiable certificates: which ID would you use to
verify it?  The name of the MX is not secure, as it is resolved using
unsecured DNS.  The only secure value you have on the mail is the remote
domain.  However, who lists the domains in the certificate?

MTA-STS is supposed to fix that, by providing a secure way to translate
from domain to MX via a medium break.

So is DANE, which requires DNSSEC on the whole thing and translates from
domain -> MX -> key via DNSSEC validated DNS.

> Without cert verification, there seems little point in requiring stronger
> TLS versions. Rather than trying to break a weaker encryption protocol
> (usually still relatively hard) an attacker could MITM with their own
> cert.

But MITM is way harder then just passive extraction of the cleartext.

Bastian

-- 
The joys of love made her human and the agonies of love destroyed her.
-- Spock, "Requiem for Methuselah", stardate 5842.8
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bastian Blank via mailop]

On Wed, Aug 03, 2022 at 03:05:43PM -0500, Jarland Donnell via mailop wrote:
> > You clearly see what TLS version and what ciphers were used. So you know
> > if
> > it was "secure" in your opinion or not.
> I don't understand why Firefox did this:
> https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/

Firefox does not speak MTA, so you are talking about a completely
different problem.  MTA is oportunistic TLS, web is required TLS.

Bastian

-- 
Phasers locked on target, Captain.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bastian Blank via mailop]

On Wed, Aug 03, 2022 at 02:46:06PM -0500, Jarland Donnell via mailop wrote:
> You have SSL because you want to not only know that the server you are
> connecting to is who they say they are, but also to secure the packets as
> they transmit to your ISP, to their upstream, to the next upstream, etc. If
> you are using an insecure SSL protocol/cipher, the transactions cannot be
> called secure. Period.

Secure is not the correct term, verified would be it.  But to establish
a verified connection in the context of SMTP you need DANE.  And with
DANE you can enforce proper current protocols.

However you still did not show how plaintext would be more secure then
old TLS.

But anyway:
Plaintext is easily defeated by passive eavesdropping.

Old TLS even without verification requires at least active MITM.  Aka it
is more secure.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Spamhaus "open resolver" errors

[Bastian Blank via mailop]

On Fri, May 13, 2022 at 10:57:21AM -0600, Grant Taylor via mailop wrote:
> Spamhaus has stated that they were going to disable access via high -- my
> words -- open public recursive resolvers since the very first message they
> published about this 3-6 months ago.

I'm pretty sure I've read that error code in the Spamhaus documentation
several years ago.  So people should know.  And I hear a lot of calls to
only block on specified result codes, not on all.

> I suspect that their $BLOCKING method has progressed to false positives as a
> way to get email administrator's attention.

Why do you think those are "false positives"?  Can you please show that
those systems use dedicated resolvers?

Bastian

-- 
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] suggested max received headers/hop limit

[Bastian Blank via mailop]

On Sat, Mar 12, 2022 at 02:31:14AM +0100, Ángel via mailop wrote:
> E.g. your email arrives to the on-premises MTA, which not finding a
> local user passes it to Office 365 who doesn't have that either so it
> is sent again to on-pre

But this is a real mail loop.  One system needs to be authoritative for
the question of available users.

Bastian

-- 
"Get back to your stations!"
"We're beaming down to the planet, sir."
-- Kirk and Mr. Leslie, "This Side of Paradise",
   stardate 3417.3
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Auto Unsubscribing Behavior

[Bastian Blank via mailop]

Hi Brian

On Tue, Mar 08, 2022 at 03:10:29PM -0500, Brian Toresdahl via mailop wrote:
> What we've seen, corroborated with cases across different sender domains,
> and different recipient domains, is that emails, as soon as they're
> delivered, are being immediately unsubscribed. We've had enough independent
> reports from recipients that they didn't unsubscribe themselves to make me
> believe them. We've had cases where senders and recipients are on the
> phone, together, with the recipient actively trying to resubscribe, but
> each retry is again unsubscribed. So it's like some automated system is
> unsubscribing recipients against their consent.

Did you check the logs of the unsubscribe service?  Where do those
unsubscribe requests come from?

> Am I understanding the issue correctly here?

No, most likely your unsubscribe workflow is flawed, as others pointed
out already.

Bastian

-- 
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail POP3/SMTP and issue with SPF record

[Bastian Blank via mailop]

On Tue, Feb 22, 2022 at 02:38:31PM +, Laura Atkins via mailop wrote:
> Very strange indeed. web-net.gr  is not in any header 
> that I could see. Is there something in the links pointing to that? 

Because "web-net.gr" should be the Name of the Google organization,
which might be different then the domain used.

> The return path for that message is elmetal.gr  and 
> include:_spf.google.com  is in that SPF record and 
> that IP is in there. Looks like Gmail is just confused. Is it one message or 
> many?

Why do you add random links in your text?

Also, why should the GMail authentication (MSA) SMTP service use the
same IP ranges as the direct-to-MX (MTA) SMTP service?  _spf.google.com
would be correct, if the OP would not have configured GMail to send
mail via some other MSA.

Bastian

-- 
No one can guarantee the actions of another.
-- Spock, "Day of the Dove", stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Gmail POP3/SMTP and issue with SPF record

[Bastian Blank via mailop]

Hi

On Tue, Feb 22, 2022 at 03:58:50PM +0200, Christos Chatzaras via mailop wrote:
> https://dpaste.com/8MNNRGMX4.txt
> Looks like 209.85.216.48 which is a Gmail POP3 client is used as "sender IP" 
> and because we don't include include:_spf.google.com in the SPF record it 
> shows this warning:

No, GMail uses it, because it's the _only_ IP in the whole trace and
also the last external one.

You need to either trash the IP in the Received line from the
authenticated sender.  Or make sure a Received line with the IP of an
authorized sender is listed in between, for example by splitting in and
outgoing email traffic (as is custom anyway).

> The issue started today. Any idea why Gmail does this?

Because everyone would do that.

Bastian

-- 
The idea of male and female are universal constants.
-- Kirk, "Metamorphosis", stardate 3219.8
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC Reports to aliexpress.com won't be delivered.

[Bastian Blank via mailop]

On Fri, Jan 28, 2022 at 10:57:08PM +0100, Jan-Pieter Cornet via mailop wrote:
> Oh, and then there are a number of ticket systems or mailinglists behind 
> dmarc reporting addresses that usually reply with something like 'Your email 
> to our support system could not be accepted". Usually in such a way that it's 
> near impossible to get the original destination address out automatically. 
> Whenever I have some time, I tend to go through some of those bounces and 
> plonk the corresponding domains for a whole year.

You don't use VERP or a similar automation to get unique addresses?  If
you write them both in the envelope and header, the remote system won't
have much possibilities to mess that up.

Bastian


-- 
We fight only when there is no other choice.  We prefer the ways of
peaceful contact.
-- Kirk, "Spectre of the Gun", stardate 4385.3
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC verification issues at infomaniak.com

[Bastian Blank via mailop]

On Wed, Jan 26, 2022 at 12:54:50PM +0100, Renaud Allard via mailop wrote:
> I am getting DMARC rejections at infomaniak.com. There seems to be an issue
> in their DMARC verifications. I tested DMARC sending to gmail which confirms
> me DMARC is OK for that domain.

Please provide us with the DKIM header you use.  DMARC has the
brokeness that it considers both SPF and DKIM okay.  So you need to
evaluate both.

Bastian

-- 
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC verification issues at infomaniak.com

[Bastian Blank via mailop]

On Wed, Jan 26, 2022 at 12:54:50PM +0100, Renaud Allard via mailop wrote:
> I am getting DMARC rejections at infomaniak.com. There seems to be an issue
> in their DMARC verifications. I tested DMARC sending to gmail which confirms
> me DMARC is OK for that domain.

The email you sent to this list does not contain an alligned DKIM
signature:

| Reply-To: Renaud Allard 
| DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=default; bh=+XmUCCU2fEMU
|  vKLp3lZ2fc0YxNWXp3p9vFNlEBumO6w=; h=subject:from:to:date;
|  d=arnor.org; 
|  b=gD+aAMh6+qNuDcF47kV1yXRqap+nbpqRy769CSCYOwa2vqThXVawUPJywGeHdTdSzasB
|  SfUBPQFvaj+2pA2Fxvlix0MfUPJc0pdcZyYWrKly3UWUkw4bQeM8p+9DdmBVOckXoafrwr
|  i6DW4c9HbVX6Vp1Q7kAg/PKkihEE+uxKIQdmdvXkrB3LHhxHomykI3b56rN2ShzNOJ2wmG
|  1hECC6Otb3lSJAXei8teW/kj60LKRKdol/4TXJOhLlj1Pmz9uLHbgVlSck2K+Hp1Ok0Ku9
|  JC1wFecDjxP5RMM82lEOyXzLmWvrdz7y/utDL2Hdjtp2IW6/igkTtjyx1yrFY3eA==

The address seems to be @allard.it, but it is signed for arnor.org.  You
need to make sure both domains are alligned.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone else notice that MS Hotmail/o365 might not be following RFC?

[Bastian Blank via mailop]

Moin

On Mon, Nov 29, 2021 at 01:57:54PM -0800, Michael Peddemors via mailop wrote:
> No, Pipeline is not advertised, the RFC's say that when you send a command,
> if you are NOT using pipelining, you need to wait for a response, and that
> includes the QUIT.. wait for the receiving system to send an OK in this
> respect, not only does it satisfy RFC's but also helps differentiate from
> the many spamming systems that terminate as quickly as they can to reduce
> overhead when spamming.

Where did you find a pre-historic SMTP server without PIPELINING?

Also RFC 5321 sounds quite clear to me:

| The sender MUST NOT intentionally close the transmission channel until
| it sends a QUIT command, and it SHOULD wait until it receives the reply
| (even if there was an error response to a previous command).

So the wait for QUIT reply is a SHOULD.

Bastian

-- 
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] spamhaus blocking Linode IPv6 (2a01: 7e01)

[Bastian Blank via mailop]

On Fri, Nov 26, 2021 at 09:34:44AM +0200, Mary via mailop wrote:
> Unlike other providers like OVH and hetzner...

Hetzner does not assign less then a /64 in all their current products.

Bastian

-- 
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] AOL and Message-ID headers?

[Bastian Blank via mailop]

On Wed, Oct 13, 2021 at 03:34:48PM +, Steven Champeon via mailop wrote:
> Seems it was sent from a US Cellular phone. She just sent me another via
> the phone and it also lacks a Message-ID header. So, USC's phone mail
> client is the culprit. 

And that's where it is up to you to stop ranting and providing proof.
Aka provide enough e-mail headers (aka all with only identifying
information removed) so people can identify what you see.

Regards,
Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] m-365 still works like a spammer !

[Bastian Blank via mailop]

On Sat, Jul 24, 2021 at 05:14:17PM +0200, Xavier Beaudouin via mailop wrote:
> I use greylisting...

So there we have the problem.  Microsoft decided to implement a
mailsystem that does not use the same IP for different delivery
attempts.

Not really common, but not forbidden.

Bastian

-- 
First study the enemy.  Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] m-365 still works like a spammer !

[Bastian Blank via mailop]

On Sat, Jul 24, 2021 at 12:38:34PM +0200, Xavier Beaudouin via mailop wrote:
> Well it seems that RFC974 is deprecated and replaced by RFC 5321, section 
> 5.1. "MX
> records contain a preference indication that MUST be used in sorting
> if more than one such record appears (see below).  Lower numbers are
> more preferred than higher ones."
> So now this is not SHOULD, but MUST. So Microsoft violate (once again) a 
> RFC...

Sadly no.  You forgot the last paragraph:

| If records do remain, they SHOULD be tried, best preference first, as
| described above.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] m-365 still works like a spammer !

[Bastian Blank via mailop]

On Fri, Jul 23, 2021 at 09:44:38PM +0200, Thomas Walter via mailop wrote:
> Regarding RFC974
>If the list of MX RRs is not empty, the mailer SHOULD try to deliver
>the message to the MXs in order (lowest preference value tried
>first).  The mailer IS REQUIRED to attempt delivery to the lowest
>valued MX.  Implementors are ENCOURAGED to write mailers so that they
>try the MXs in order until one of the MXs accepts the message, or all
>the MXs have been tried.
> 
> It's been a while since I looked at this, but isn't "SHOULD" a
> recommendation? I understand this collides with the next "IS REQUIRED",
> but...?

No, there is no contradiction.

I could write a mailer that starts from highest preference value to
lowest.  This violates the first "SHOULD", but fulfills the second
"REQUIRED".

Bastian

-- 
The more complex the mind, the greater the need for the simplicity of play.
-- Kirk, "Shore Leave", stardate 3025.8
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone from Google here?

[Bastian Blank via mailop]

On Fri, Jul 16, 2021 at 12:09:10PM -0400, Eric Tykwinski via mailop wrote:
> Just a heads up, I noticed some emails piling up in our spool.
> Common part is McAfee's ad in the signature.

This was already reported.  Kill the ads with fire, Google is (IMHO
correctly) considering them spam.

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] I disabled Spamhaus checking due to false-positives

[Bastian Blank via mailop]

Hi

On Thu, Jul 15, 2021 at 04:29:24AM -0700, Mark Milhollan via mailop wrote:
> Spamhaus has been working fine for me and has been a wonderful resource for
> many years, but I recently decided I had to disable using them on my
> personal, low volume mail server because of a few recent surprises (that's
> right, I don't look at Spamhaus rejects, timestamps are UTC):

Did you check the result of those RBL requests?  Spamhaus also provides
specific codes for errors, so you _must_ explicitely list what codes you
want to accept.  See
https://www.spamhaus.org/faq/section/DNSBL%20Usage#200 what those mean.

Bastian

-- 
"What terrible way to die."
"There are no good ways."
-- Sulu and Kirk, "That Which Survives", stardate unknown
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Feedback Loop in Gmail Postmaster tools does not show anything

[Bastian Blank via mailop]

On Wed, Jun 02, 2021 at 01:22:31PM +0200, Tim Düsterhus, WoltLab GmbH via 
mailop wrote:
> Mail is being sent with a 'MAIL FROM:'
> with the 'From:' containing an email address of the customer's custom
> domain.
> We're DKIM signing the emails using a key in the 'bounce.woltlab.cloud'
> domain and add a 'Feedback-ID: customer_id:WCloud' header to all emails, in
> an attempt to uniquely identify the customer in cases of spam reports.

So you produce third party signatures.  You need to sign also with the
customer's domain if you want to have that in the From header.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Carrierzone - Incorrectly Rewriting From and Return-Path Headers?

[Bastian Blank via mailop]

Hi

On Thu, May 27, 2021 at 02:33:10PM -0500, Chris Adams via mailop wrote:
> Emails leaving our platform have a proper From header. However, when they
> are received by Carrierzone, both the From and Return-Path headers have had
> the domain replaced with  "sparkpostmail.com".   It's almost as if they are
> using the organizational domain from our connecting IP's rDNS lookup and
> rewriting the header using that domain.

It's actually a lot easier.  They are following a CNAME:

| ;; ANSWER SECTION:
| send.osdealerfuel.com.300 IN  CNAME   sparkpostmail.com.

AFAIK only Sendmail ever exhibited this property of rewriting From
header due to CNAME.

> Authentication-Results-Original: mail314c28.carrierzone.com; dkim=pass
>  (1024-bit key) header.d=send.o***l.com 
> header.i=@send.o***l.com 
>  header.b="tBmppuh8"

Is there a reason why you break the example headers you send?  There are
not supposed to be any "*" or "<>" in there.  And they are rewrapped,
kind off.

> Received: from mta-88-193.sparkpostmail.com (mta-88-193.sparkpostmail.com
>  [192.174.88.193])
> by mail314c28.carrierzone.com (8.14.9/8.13.1) with ESMTP id 14MEd3NK026470

Sure, Sendmail.

Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop