Re: [mailop] "451 Requested action aborted: local error in processing" when submitting email to ionos email services.

[Tobias Herkula via mailop]

This seems to be an issue on your site, I checked the logs and all the times we 
were not able to deliver mails to you the error we had was "temporary mx 
resolver error".

Most likely root cause: "dns.hiskp.uni-bonn.de." does not answer queries via 
UDP, as you also have a couple of more systems answering fine, this would also 
explain why it sometimes works and sometimes not.


/ Tobias Herkula

Senior Product Owner Mail Security
Product Management Mail Transfer & Mail Security

1&1 Mail & Media GmbH

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 7666
Geschäftsführer: Alexander Charles, Dana Kraft, Thomas Ludwig, Dr. Michael 
Hagenau

Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen 
enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail 
irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten 
Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, 
diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise 
auch immer zu verwenden.
This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient of this e-mail, you are hereby notified that saving, 
distribution or use of the content of this e-mail in any way is prohibited. If 
you have received this e-mail in error, please notify the sender and delete the 
e-mail.


-Original Message-
From: mailop  On Behalf Of Michael Lang via mailop
Sent: Tuesday, December 12, 2023 8:50 AM
To: mailop@mailop.org
Subject: [mailop] "451 Requested action aborted: local error in processing" 
when submitting email to ionos email services.

Hi everybody,

for approximately one year, we are receiving regular complaints from remote 
contacts having problems to ship email from a service like gmx.de, gmx.net, 
1und1.de and similar in fact services hosted by ionos to our email domain 
(@hiskp.uni-bonn.de, MX=mx8.hiskp.uni-bonn.de). 
During submission of ionos customers to one of the ionos servers people 
eventually receive an error of type:

451 Requested action aborted: local error in processing

We tried to track this error on our own and found out that this warning 
randomly appears and if a resubmit is tried a few seconds later, submission via 
ionos services works flawlessly. Guessing that this might be caused by the MX 
entry for our destination getting lost in the cache of ionos submission servers 
due to a to short TTL, we tried changing that in our DNS, but this did not 
change the scenario.

We furthermore observed that mail systems obviously receiving heavier load than 
we do seem not to have this problem or it occurs very rarely. 
Anyway that is for now a wild guess from us.
To us this appears as if the timeout checking DNS for the MX + A /  records 
is too short, independant ot the TTL and it furthermore appears to be load 
dependant on the ionos servers.
The same phaenomenon we regularly observe when mail from our site is shipped to 
ionos servers. Here emails regularly get deferred for several seconds with the 
same 451 error but are successfully acepted with code
250 a few seconds later.

As access to intermediate and top layer domain servers is obviously beyond our 
administrational range, does anybody have an idea why this occurs really? Is 
there maybe a contact at ionos to subscribe our email service for flawless 
transport, such as e.g. at t-online.de?  Is this problem known to anybody else 
and what did you do to fight it?

With kind regards

    Michael
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Thoughts on envelope address local-part length limits

[Tobias Herkula via mailop]

Your sentence does sound to me that it's fine for senders to not adhere to 
these limits and be able to complain about receivers who would block those 
messages. I'm on the other side would state that in a more sarcastic way, like 
"You can totally ignore these limits but have no right to complain if others 
reject you because of it." With a stronger emphasis on the "You should not do 
it!", instead of only stating you can do it for your own outbound stuff, 
referencing Postels Law, and therefore implicitly stating that rejecting 
"invalid" message stream is kind of bad behavior.

/ Tobias 

-Original Message-
From: mailop  On Behalf Of Slavko via mailop
Sent: Monday, May 15, 2023 2:39 PM
To: mailop 
Subject: Re: [mailop] Thoughts on envelope address local-part length limits

Dňa 15. mája 2023 7:44:07 UTC používateľ Tobias Herkula via mailop 
 napísal:
>Be careful with references to Postels robustness principle and look 
>into that 
>https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance 
>(formally known as "postel-was-wrong") And if you reference 4.5.3.1, 
>you should not omit
>
>"Objects larger than these sizes SHOULD be avoided when possible."
>And
>"Clients MAY attempt to transmit these, but MUST be prepared for a server to 
>reject them if they cannot be handled by it."
>
>With the substantial critique on the robustness principle and the underlying 
>hierarchy of MUST, SHOULD and MAY from rfc2119, these two paragraphs out of 
>rfc5321#4.5.3.1 will push the minimum/maximum discussion into the obey the 
>limit corner and not the "do as you like" corner, but that's only my humble 
>opinion.

And how this differs from what i wrote:

If you really want, apply mentioned limits to your outgoing messages...

regards


--
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Thoughts on envelope address local-part length limits

[Tobias Herkula via mailop]

Be careful with references to Postels robustness principle and look into that 
https://datatracker.ietf.org/doc/html/draft-iab-protocol-maintenance (formally 
known as "postel-was-wrong")
And if you reference 4.5.3.1, you should not omit

"Objects larger than these sizes SHOULD be avoided when possible."
And
"Clients MAY attempt to transmit these, but MUST be prepared for a server to 
reject them if they cannot be handled by it."

With the substantial critique on the robustness principle and the underlying 
hierarchy of MUST, SHOULD and MAY from rfc2119, these two paragraphs out of 
rfc5321#4.5.3.1 will push the minimum/maximum discussion into the obey the 
limit corner and not the "do as you like" corner, but that's only my humble 
opinion.

/ Tobias

-Original Message-
From: mailop  On Behalf Of Slavko via mailop
Sent: Friday, May 12, 2023 7:54 PM
To: mailop 
Subject: Re: [mailop] Thoughts on envelope address local-part length limits

Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop 
 napísal:

>4.5.3.1.  Size Limits and Minimums

When you read RFC, you MUST read all, not only interesting parts.
Yes, sometime it is hard, but notice the sentence in this section:

Every implementation MUST be able to receive objects of at
least these sizes.

I understand that these limits are not maximum which can be used, but rather 
minimum which have to be supported. That is shown in the same section latter:

To the maximum extent possible, implementation techniques
that impose no limits on the length of these objects should be
used.

It IMO clearly suggests to not limit these things.

IMO, one have to consider, that there was more resorce constrained HW in time 
of that RFC and even nowadays there can be embeded systems with no GBs of RAM 
(and so). If that is not your case, simple do not limit on that, or limit on 
values which can be harmfull for you (eg. file system mailbox name length 
limits, or so).

If you really want, apply mentioned limits to your outgoing messages only. Do 
you know: be strict on what you send, and be liberal on what you receive. But 
if you really not need them, applying these limits is wasting of resorces, for 
checking, for develop rules, for testing, for maintaining, for support 
responses...

When you apply these limits, you will not prevent SPAMs, nor phishings, nor 
scams, only ugly addresses and we have bigger problems than ugly addresses :-)

regards


--
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMX/Mail.com contact?

[Tobias Herkula via mailop]

Feel free to reach out to mailsecur...@gmxnet.de

/ Tobias Herkula

Senior Product Owner Mail Security
Mail Application Security
1&1 Mail & Media

From: mailop  On Behalf Of Mike Hillyer via mailop
Sent: Friday, May 12, 2023 10:29 PM
To: mailop 
Subject: [mailop] GMX/Mail.com contact?

Anyone have a contact? I have someone with an accountant.com address trying to 
run a check scam on me.

Mike Hillyer
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Receivers behavior when seeing a new header

[Tobias Herkula via mailop]

I can not give any hints on if or how we would transport that information to 
the user, YET. But it would not have any negative impact on how we handle the 
message from a Mail Security view at our system 
(Web.de/GMX/Mail.com/1&1/Ionos), Bonus points if the header is signed with a 
5322.From Domain aligned DKIM signature.


/ Tobias Herkula

Senior Product Owner Mail Security
Mail Application Security
1&1 Mail & Media GmbH



-Original Message-
From: mailop  On Behalf Of Benjamin BILLON via mailop
Sent: Thursday, May 4, 2023 3:36 PM
To: mailop@mailop.org
Subject: [mailop] Receivers behavior when seeing a new header

Hello, 

We're an ESP, we've been asking our clients to add an Expires: header 
(https://datatracker.ietf.org/doc/draft-billon-expires/) and one of them said 
they had concerns that a new header would confuse the antispam and that there's 
a risk emails would start getting junked or rejected. 

I asked a few mailbox providers and antispam solutions already, they all told 
me there would be no (negative) change. 

For the receivers out here, how would _you_ react upon seeing a new header, and 
this header in particular? 

Of course if major mailbox providers on this list could share their thoughts 
about this, that would help me convince my clients but would also be useful for 
other ESPs and senders. 
Assuming that there's indeed no negative change in deliverability, obviously. 

Cheers, 
--
Benjamin BILLON
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] A guy from GMX at the list?

[Tobias Herkula via mailop]

Hi Florian,

For which DKIM signing Domains you see issues? And what are your IP-Ranges? 
Feel free to answer off list, if you don't want to disclose this information.

-Original Message-
From: mailop  On Behalf Of Postmaster 
florian-pankerl.tk via mailop
Sent: Friday, April 21, 2023 2:12 PM
To: mailop@mailop.org
Cc: florian.pank...@004gmbh.de
Subject: [mailop] A guy from GMX at the list?

Hi!

Is there a guy from GMX.de at the list?

We sent business-related mails (order-confirmation, invoice etc.) for 
onlineshops of our customers. For one of the shops GMX seems to be a black hole 
- the GMX-Servers accepts the mails without any error and then the mails 
disappears.

I wrote via the form at https://postmaster.gmx.net two days ago - but no 
reaction.

Regards,
Florian Pankerl

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Should mailing list messages be DKIM signed? (ARC / DKIM)

[Tobias Herkula via mailop]

You don't need ARC if you are munging the 5322.From, but if you are munging the 
5322.From add a strict aligned DKIM signature, this makes it easy to filter and 
trust your lists traffic.

If you run multiple lists on the same domain, please do strict alignment 
between 5322.From AddrSpec and the 6376.Identifier (DKIM "i").

Only adding ARC without your own DKIM will make it harder for a lot of people, 
that are not yet ready to process ARC signatures.

/ Tobias

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Patrick Ben Koetter via 
mailop
Gesendet: Freitag, 17. Februar 2023 17:08
An: mailop 
Betreff: [mailop] Should mailing list messages be DKIM signed? (ARC / DKIM)

Greetings,

I'm about to setup a new mailing list server. It will use Mailman 3, which is 
able to add ARC signatures to incoming messages. The lists will also rewrite 
the From:-header and to match the lists name and domain. I'm unsure if outbound 
messages should also be DKIM signed or does it suffice to add ARC signatures?

Regards,

p@rick

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Idea for new internet standard: DKIM-QR

[Tobias Herkula via mailop]

Hi Sebastian,

please also be aware of the fact that the people you want to target here, will 
most likely not recognize such an image as QR-Code at all, as the amount of 
data you want to put in it is quite large and needs a lot of error correction 
data to counter the moiré effect, as your use case is scanning the code from an 
active display. So, for most people it will look like an image of "white 
noise", as even the recognizable squares in the corners of a QR-code will be 
relatively small in comparison to the overall size of the image. 

We as GMX & Co, would also consider a DKIM Signature with l=0 as not acceptable.

Besides that, what John said...

/ Tobias Herkula (Web.de|GMX|Mail.com)

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Sebastian Nielsen via 
mailop
Gesendet: Dienstag, 14. Dezember 2021 16:32
An: 'Mailing List' 
Betreff: Re: [mailop] Idea for new internet standard: DKIM-QR

The problem here is that the signer isn't shown prominently in MUA's.
Here is where the QR code comes in.

So yes, a phisher might own a own domain, lets say spammydomain.xyz, and get 
the mail legitimately signed as spammydomain.xyz and get DMARC/DKIM pass.

That’s why I suggest this QR code scheme to make the signature more visible and 
prominent on the email (like a pen and paper signature on a snail-mail 
document) so when someone verifies the signature, it will be very prominent 
that spammydomain.xyz did sign the mail and not yourbank.com.

Gmail already has a user interface to show SPF and DKIM signatures, by pressing 
the little down arrow on "To: me".

That’s whats DKIM really lacking - authentication. Just that the email is 
signed isn't enough. It should be signed by the person that you are expecting 
to send the email, in this case yourbank.com And if some sort of authentication 
is added, it would practically be impossible to create a email that shows up as 
signed by "yourbank.com".


-Ursprungligt meddelande-
Från: John Levine via mailop 
Skickat: den 14 december 2021 15:53
Till: mailop@mailop.org
Kopia: thomasm-mai...@wupper.com
Ämne: Re: [mailop] Idea for new internet standard: DKIM-QR

It appears that Thomas Mechtersheimer via mailop  
said:
>for DKIM/DMARC checking in MUAs and prominently displaying these 
>authentication results, which would get the same level of securtiy with 
>already existing standards.

Please keep in mind that level of security is "none".  People who send phishes 
know how to add DKIM signatures and get DMARC alignment.  They are often better 
at it than some legit senders.

DKIM and DMARC are useful but only as part of an overall mail filtering scheme, 
not as FUSSPs.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone from gmx.ch here?

[Tobias Herkula via mailop]

Answered off list

/ Tobias Herkula (Web.de|GMX|Mail.com)

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Eliot Lear via mailop
Gesendet: Donnerstag, 2. Dezember 2021 18:54
An: mailop 
Betreff: [mailop] Anyone from gmx.ch here?

Seeing please contact offline.

Thanks,

Eliot
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Paging GMX mail admins: issues with automatic mail forwards

[Tobias Herkula via mailop]

Replied off list.

/ Tobias Herkula (Web.de|GMX|Mail.com)

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Carsten Schiefner via 
mailop
Gesendet: Montag, 29. November 2021 16:22
An: mailop@mailop.org
Betreff: [mailop] Paging GMX mail admins: issues with automatic mail forwards

All -

could a GMX mail admin please be in touch with me, please?

Or point me to such a person?

The issue in short: automatic mail forwarding sporadically fails from GMX 
mail-out servers with claims that "multiple delivery attempts failed" since the 
beginning of November.

Yet, grey listing is now switched off for all known GMX mail-out servers, 2nd 
MXer for the zone is also temporary switched off. Last, but not least: no 
traces of any delivery attempts for these fails in the logs.

I'd like to see this erratic behavour tracked down and solved.

Thanks & best,

-C.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mandated emails from notifications.newbalance.com on 1st of December

[Tobias Herkula via mailop]

Which DKIM signing Domains will be used for this send out?

/ Tobias Herkula (Web.de|GMX|Mail.com)

Von: mailop  Im Auftrag von Vytis Marciulionis via 
mailop
Gesendet: Dienstag, 30. November 2021 16:24
An: mailop@mailop.org
Betreff: [mailop] Mandated emails from notifications.newbalance.com on 1st of 
December

To Whom it May Concern,

In accordance with the M3AAWG "Sending Mandated Emails to Large Audiences" 
guidance: This message is to inform you of a high email volume send which is 
likely to contain invalid email addresses and contacts who have opted out of 
email communication.

This send will be performed by New Balance who are contractually required to 
inform their Loyalty members that the program will be turned off by the end of 
the year.

If you are one of the mailbox providers that could help us prepare to contact 
the affected userbase, please reach out with any questions you may have.

Campaign Details to to recognize the risky traffic and make appropriate 
filtering decisions:

From address: 
m...@notifications.newbalance.com
Subject line: An important update about myNB Rewards
Date of Send: December 1st, 2021
Time of Send: Deploying over the course of the day. They will likely start 
12:40 CST / 18:40 UTC - then every hour until last deployment at 23:40 CST / 
05:40 UTC.
Total Volume: 4.2 million (typical domain split)
Sending IPs:
83.68.134.153
83.68.134.154
83.68.134.155
83.68.134.156

We appreciate your attention to this matter.

Thanks,
Emarsys Deliverability Team























___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mail.ru new network range and TLSRPT support

[Tobias Herkula via mailop]

Do you have any changes for the DKIM signing Domains? We currently have 
mail.ru, bk.ru, list.ru, internet.ru, inbox.ru and mail.ua on record for your 
system.

Tobias Herkula
--
Senior Product Owner Mail Security
Product Mail Platform

1&1 Mail & Media GmbH | Mitte | 10115 Berlin | Deutschland
E-Mail: tobias.herk...@1und1.de | Web: www.1und1.de

Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 7666

Geschäftsführer: Alexander Charles, Ralf Hartings, Thomas Ludwig, Jan Oetjen

Member of United Internet

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Vladimir Dubrovin via 
mailop
Gesendet: Mittwoch, 17. November 2021 14:31
An: mailop@mailop.org
Betreff: [mailop] Mail.ru new network range and TLSRPT support


1. Mail.ru starts using 45.84.128.0/23 for webmail traffic, please update your 
ratelimits / rule descriptions

2. We have recently implemented TLS reporting with MTA-STS supported, please 
let me know if you see any issues with it.

--
Vladimir Dubrovin
Technical advisor @ Mail.ru
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)

[Tobias Herkula via mailop]

Hi Stefano,

I can not answer for Florian but can say this: We at 1&1 (Web.de/GMX/Mail.com) 
watched this
experiment with a lot of interest and plan a very similar setting for the 
future under the title
"NO-ALIGNMENT-SLOW-ENTRY" where we plan to start rate limiting large Bulkmail 
Providers
if they do not comply with the Requirements part of the pamphlet that can be 
read here:

https://docs.google.com/document/d/e/2PACX-1vQeodijKJJJPX6fCma3tm00n8m0aJI0VyuO17hKXTy0y7JYUzIxd5Cqh2VSttvJkw-yxWK5fT8NFDcO/pub

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von Stefano Bagnara via 
mailop
Gesendet: Donnerstag, 14. Oktober 2021 11:09
An: mailop 
Betreff: Re: [mailop] DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)

On Fri, 16 Apr 2021 at 11:45, Florian.Kunkel--- via mailop  
wrote:
> the requirements posted before only apply to ESPs (email service providers | 
> mass mailers | ... mailhosters).
> Mailing lists should not be concerned as far as I can tell from our stats.
> []
> that's the reason we didn't start with DMARC policy enforcement so far.
> it's to gamy to adhere the domain policy without regard of the source IP you 
> see the message from.

Hi Florian,

do you have any update about this DMARC enforcement "experiment" @t-online.de ?

--

Tobias Herkula

Senior Product Owner Mail Security
Product Mail Platform

1&1 Mail & Media GmbH | Mitte | 10115 Berlin | Deutschland 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMAIL reject Bounces

[Tobias Herkula via mailop]

Hello Andreas,

Citing RFC 3464 Section 2 Paragraph 4: "The From field of the message header of 
the DSN SHOULD contain the address of a human who is responsible for 
maintaining the mail system at the Reporting MTA site (e.g., Postmaster), so 
that a reply to the DSN will reach that person.  Exception: if a DSN is 
translated from a foreign delivery report, and the gateway performing the 
translation cannot determine the appropriate address, the From field of the DSN 
MAY be the address of a human who is responsible for maintaining the gateway."

https://datatracker.ietf.org/doc/html/rfc3464#section-2

And I can understand Google here, as we do it similar, if a Message does not 
contain a "5322" valid From Header we reject the message. (or sometimes deliver 
to spam folder for analysis) The Amount of Mails with malformed From Headers 
that are SPAM is so much higher compared to DSNs that we think protection oft 
he user against spam is more important than a not arriving DSN... And as there 
is no sane default, perhaps the Postfix Config needs a breaking change fort he 
default that forces mailops to add the right value...

-Ursprüngliche Nachricht-
Von: mailop  Im Auftrag von A. Schulze via mailop
Gesendet: Freitag, 13. August 2021 16:46
An: mailop@mailop.org
Betreff: [mailop] GMAIL reject Bounces

Hello,

Sometimes messages are accepted by an MX but undeliverable in later processing.
Misconfigured forawarding, User broke it's sieve rules, whatever

In this case the LDA send a DSN back to the sender.
But if the sender uses gmail.com, the DSN will never arrive:

Aug 13 16:09:15 mta postfix/smtp[105040]: 4GmQQz2MM8zB08wK: 
to=, relay=gmail-smtp-in.l.google.com[142.251.5.26]:25, 
delay=0.26, delays=0.01/0/0.13/0.12, dsn=5.7.1, status=bounced (host 
gmail-smtp-in.l.google.com[142.251.5.26] said: 550-5.7.1 [redacted_ipv4] 
Messages missing a valid address in From: 550 5.7.1 header, or having no From: 
header, are not accepted. a185si1555216wme.53 - gsmtp (in reply to end of DATA 
command))

well, it's postfix that generated this DSN with this RFC5322.From

From: MAILER-DAEMON (Mail Delivery System)

This wasn't configured by me but is Postfix default since two decades

- 
https://github.com/vdukhovni/postfix/blob/v1.1.0/postfix/src/bounce/bounce_notify_util.c#L268
- https://github.com/vdukhovni/postfix/blob/master/postfix/proto/bounce#L76

Should I really tell my customers "gmail break email" ?
I would like to here your opinions.

Andreas
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Vodafone Germany Mail Infrastructure Change Notification

[Tobias Herkula via mailop]

A Friend of mine is handling SMTP Traffic for Vodafone Germany and wants to 
give a heads up here about a bigger change, he was not able to join Mailop so 
I'm citing him:

>  Hello everyone,
>
>  we are in the process of moving the e-mail service of Vodafone Germany to
>  another platform which will be run in a Vodafone data center (more
>  precisely: e-shelter). We want to gradually increase the
>  SMTP-Submit-Traffic over the next 2 weeks using the new IPs. In total we
>  will send a few million mails daily over the new IPs.
>
>  Therefore, can you give a little bit of trust to the following two /29er
>  networks (or alternatively the 6 IPs of our MTA clusters)?
>
>  ip4:145.253.239.128/29
>- 145.253.239.132
>- 145.253.239.133
>- 145.253.239.134
>
>  ip4:145.253.228.160/29
>- 145.253.228.164
>- 145.253.228.165
>- 145.253.228.166
>
>  These two /29 networks are already configured in the SPF records of the
>  following domains:
>
>- arcor.de
>- arcormail.de
>- germanynet.de
>- gno.de
>- mail.isis.de
>- nexgo.de
>- nvvonline.de
>- online-club.de
>- otelo-online.de
>- otelo-web.de
>- rp-plus.de
>- vodafone.de
>- vodafonemail.de
>
>  See for example the SPF Record of spf.vodafonemail.de
>
>v=spf1 ip4:2.207.150.227/27 ip4:2.207.151.33/27 ip4:145.253.228.160/29 
> ip4:145.253.239.128/29 ip4:31.25.48.0/24 ~all
>
>
>  Merci in advance and best regards from Ahaus/Germany
>
>  Jochen Meyer
>
>  mediaBEAM GmbH
>  Erhardstraße 3
>  D-48683 Ahaus
>
>  Phone +49 2561 695-111
>  Mobile +49 179 1091403
>  Fax +49 2561 695-0111
>  mailto:jochen.me...@mediabeam.com
>  http://www.mediabeam.com
>
>  HRB 3265 Amtsgericht Coesfeld
>  UST-ID DE 204 581 685
>  Geschäftsführer Jochen Meyer, Markus Schulte

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Vodafone Germany Mail Infrastructure Change Notification

[Tobias Herkula via mailop]

A Friend of mine is handling SMTP Traffic for Vodafone Germany and wants to 
give a heads up here about a bigger change, he was not able to join Mailop so 
I'm citing him:

>  Hello everyone,
> 
>  we are in the process of moving the e-mail service of Vodafone Germany to
>  another platform which will be run in a Vodafone data center (more
>  precisely: e-shelter). We want to gradually increase the
>  SMTP-Submit-Traffic over the next 2 weeks using the new IPs. In total we
>  will send a few million mails daily over the new IPs.
> 
>  Therefore, can you give a little bit of trust to the following two /29er
>  networks (or alternatively the 6 IPs of our MTA clusters)?
> 
>  ip4:145.253.239.128/29
>- 145.253.239.132
>- 145.253.239.133
>- 145.253.239.134
> 
>  ip4:145.253.228.160/29
>- 145.253.228.164
>- 145.253.228.165
>- 145.253.228.166
> 
>  These two /29 networks are already configured in the SPF records of the
>  following domains:
> 
>- arcor.de
>- arcormail.de
>- germanynet.de
>- gno.de
>- mail.isis.de
>- nexgo.de
>- nvvonline.de
>- online-club.de
>- otelo-online.de
>- otelo-web.de
>- rp-plus.de
>- vodafone.de
>- vodafonemail.de
> 
>  See for example the SPF Record of spf.vodafonemail.de
>
>v=spf1 ip4:2.207.150.227/27 ip4:2.207.151.33/27 ip4:145.253.228.160/29 
> ip4:145.253.239.128/29 ip4:31.25.48.0/24 ~all
>
>
>  Merci in advance and best regards from Ahaus/Germany
>
>  Jochen Meyer
> 
>  mediaBEAM GmbH
>  Erhardstraße 3
>  D-48683 Ahaus
> 
>  Phone +49 2561 695-111
>  Mobile +49 179 1091403
>  Fax +49 2561 695-0111
>  mailto:jochen.me...@mediabeam.com
>  http://www.mediabeam.com
> 
>  HRB 3265 Amtsgericht Coesfeld
>  UST-ID DE 204 581 685
>  Geschäftsführer Jochen Meyer, Markus Schulte

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Vodafone Germany Mail Infrastructure Change Notification

[Tobias Herkula via mailop]

A Friend of mine is handling SMTP Traffic for Vodafone Germany and wants to 
give a heads up here about a bigger change, he was not able to join Mailop so 
I'm citing him:

>  Hello everyone,
>  
>  we are in the process of moving the e-mail service of Vodafone Germany to
>  another platform which will be run in a Vodafone data center (more
>  precisely: e-shelter). We want to gradually increase the
>  SMTP-Submit-Traffic over the next 2 weeks using the new IPs. In total we
>  will send a few million mails daily over the new IPs.
>  
>  Therefore, can you give a little bit of trust to the following two /29er
>  networks (or alternatively the 6 IPs of our MTA clusters)?
>  
>  ip4:145.253.239.128/29
>- 145.253.239.132
>- 145.253.239.133
>- 145.253.239.134
>  
>  ip4:145.253.228.160/29
>- 145.253.228.164
>- 145.253.228.165
>- 145.253.228.166
>  
>  These two /29 networks are already configured in the SPF records of the
>  following domains:
>  
>- arcor.de
>- arcormail.de
>- germanynet.de
>- gno.de
>- mail.isis.de
>- nexgo.de
>- nvvonline.de
>- online-club.de
>- otelo-online.de
>- otelo-web.de
>- rp-plus.de
>- vodafone.de
>- vodafonemail.de
>  
>  See for example the SPF Record of spf.vodafonemail.de
> 
>v=spf1 ip4:2.207.150.227/27 ip4:2.207.151.33/27 ip4:145.253.228.160/29 
> ip4:145.253.239.128/29 ip4:31.25.48.0/24 ~all
> 
> 
>  Merci in advance and best regards from Ahaus/Germany
> 
>  Jochen Meyer
>  
>  mediaBEAM GmbH
>  Erhardstraße 3
>  D-48683 Ahaus
>  
>  Phone +49 2561 695-111
>  Mobile +49 179 1091403
>  Fax +49 2561 695-0111
>  mailto:jochen.me...@mediabeam.com
>  http://www.mediabeam.com
>  
>  HRB 3265 Amtsgericht Coesfeld
>  UST-ID DE 204 581 685
>  Geschäftsführer Jochen Meyer, Markus Schulte

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Vodafone Germany Mail Infrastructure Change Notification

[Tobias Herkula via mailop]

A Friend of mine is handling SMTP Traffic for Vodafone Germany and wants to 
give a heads up here about a bigger change, he was not able to join Mailop so 
I'm citing him:

>  Hello everyone,
>   
>  we are in the process of moving the e-mail service of Vodafone Germany to
>  another platform which will be run in a Vodafone data center (more
>  precisely: e-shelter). We want to gradually increase the
>  SMTP-Submit-Traffic over the next 2 weeks using the new IPs. In total we
>  will send a few million mails daily over the new IPs.
>   
>  Therefore, can you give a little bit of trust to the following two /29er
>  networks (or alternatively the 6 IPs of our MTA clusters)?
>   
>  ip4:145.253.239.128/29
>- 145.253.239.132
>- 145.253.239.133
>- 145.253.239.134
>   
>  ip4:145.253.228.160/29
>- 145.253.228.164
>- 145.253.228.165
>- 145.253.228.166
>   
>  These two /29 networks are already configured in the SPF records of the
>  following domains:
>   
>- arcor.de
>- arcormail.de
>- germanynet.de
>- gno.de
>- mail.isis.de
>- nexgo.de
>- nvvonline.de
>- online-club.de
>- otelo-online.de
>- otelo-web.de
>- rp-plus.de
>- vodafone.de
>- vodafonemail.de
>   
>  See for example the SPF Record of spf.vodafonemail.de
>  
>v=spf1 ip4:2.207.150.227/27 ip4:2.207.151.33/27 ip4:145.253.228.160/29 
> ip4:145.253.239.128/29 ip4:31.25.48.0/24 ~all
>  
>  
>  Merci in advance and best regards from Ahaus/Germany
>  
>  Jochen Meyer
>   
>  mediaBEAM GmbH
>  Erhardstraße 3
>  D-48683 Ahaus
>   
>  Phone +49 2561 695-111
>  Mobile +49 179 1091403
>  Fax +49 2561 695-0111
>  mailto:jochen.me...@mediabeam.com
>  http://www.mediabeam.com
>   
>  HRB 3265 Amtsgericht Coesfeld
>  UST-ID DE 204 581 685
>  Geschäftsführer Jochen Meyer, Markus Schulte

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] t-online.de refuses to remove an ip from their blacklist

[Tobias Herkula via mailop]

Allow your customers to set an additional PTR.

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)



From: mailop  on behalf of Andreas Bueggeln - NOC - 
Profihost AG via mailop 
Sent: Thursday, June 18, 2020 12:57
To: mailop@mailop.org
Subject: [mailop] t-online.de refuses to remove an ip from their blacklist

Hello,

we host hundreds of dedicated servers on VMs and our customers send
thousands of mail to t-online.de mailboxes every day.

a new customer uses an ip, which has been offline for months or even
years wanted to send mails to t-online.de boxes.

the usual blacklisting happened, but now the helpdesk at t-online.de
refuses because of a new policy:

- the ptr to the server ip hast to resolve to the customer domain and
vice versa
- the mails are not allowed from a cloud vm host
- the web pages of the domain must have an correct imprint

the imprint on the domain is mandatory in germany and not the problem,
but our system use a generic server domain for the ptr and the smtp
connect. this cannot be changed and many VMs host several domains.

does anybody know how to solve this?

--
Mit freundlichen Grüßen
  Andreas Büggeln
Ihr Profihost Team

---
Profihost AG
Expo Plaza 1
30539 Hannover
Deutschland

Tel.: +49 (511) 5151 8181 | Fax.: +49 (511) 5151 8282
URL: http://www.profihost.com | E-Mail: i...@profihost.com

Sitz der Gesellschaft: Hannover, USt-IdNr. DE813460827
Registergericht: Amtsgericht Hannover, Register-Nr.: HRB 202350
Vorstand: Cristoph Bluhm, Sebastian Bluhm, Stefan Priebe
Aufsichtsrat: Prof. Dr. iur. Winfried Huck (Vorsitzender)

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] How to allow different domain in envelope and header from? (Is Gmails DMARC check broken?)

[Tobias Herkula via mailop]

It is possible to do depending on the sacrifices you are willing to take:

5321.MailFrom Domain = imp.ch
5322.From Domain = breitband.ch
5322.Sender Domain = imp.ch

If you run with that you can set DKIM Domain to imp.ch and still send with 
breitband.ch in your From. And alignment should be fine.

But you will get the "via" Tag in compatible MUAs...

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)



From: mailop  on behalf of Benoît Panizzon via 
mailop 
Sent: Thursday, June 4, 2020 12:06
To: mailop@mailop.org
Subject: [mailop] How to allow different domain in envelope and header from? 
(Is Gmails DMARC check broken?)

Hi Gang

Tanks for the various feedback, learning a log :-) I found one issue
caused by domain alignment in DMARC.

We use two domains:

imp.ch (our company)
breitband.ch (our service brand)

Our Support Case System (RT/3) uses a global configured envelope sender:
 but depending on the Queue, a different Header From:
supp...@breitband.ch

Did I get this right? This is not possible anymore when a DMARC
entry is published? The envelope sender domain and From: domain MUST be
aligned and in the case of 'strict' match, be identical and for
'relaxed' match may contain a subdomain?

There is now way to have different envelope and from domains?

I guess many ESP sending newsletters do the same, put their bounce
processor in the envelope from and a customer supplied From: Address
into the header.

--
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop