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<mailto: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<mailto: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

Re: [mailop] deactivation of hard bounces

[Tobias Herkula]

They say you could do this and the max is 3, they do not they you have to wait 
until the third one. That’s a big difference!

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)


Von: mailop  im Auftrag von Marco Franceschetti via 
mailop 
Gesendet: Mittwoch, Februar 27, 2019 6:26 PM
An: mailop@mailop.org
Betreff: [mailop] deactivation of hard bounces

Hello,

We at contactlab are considering a change in the deactivation of hard bounces.
Currently, we suppress not existing mailboxes at the first hit.

We are aware of a small percentage of false positives.

Recent admissions criteria for Certified Senders states:
"The CSA sender must take email addresses from mailing lists, if, after sending 
to this address,
the mailbox is identified as non-existent; at the latest, however, this must 
occur after three hard
bounces".

We are evaluating to remove not existing mailboxes from the lists of our 
clients after the second hit instead of the first one.

Do you have any considerations, suggestions about this?

Marco


Marco Franceschetti
Head of Deliverability | ContactLab
marco.francesche...@contactlab.com
Via Natale Battaglia, 12 | Milano
contactlab.com/it

___
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] Microsoft SNDS "Sorry, whois.ripe.net will not let us do any more lookups today. Please come back and try again tomorrow"

[Tobias Herkula]

Do you try to add a Range? I had problems with the same Error a couple of years 
ago, until I figured out that they also look up the Network IP, so for us it 
helped to add PTR-RR to 192.168.0.0 with a Domain that also belonged to us...

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)


From: mailop  on behalf of Benoit Panizzon 

Sent: Tuesday, October 16, 2018 11:22:37 AM
To: Michael Wise
Cc: mailop@mailop.org
Subject: Re: [mailop] Microsoft SNDS "Sorry, whois.ripe.net will not let us do 
any more lookups today. Please come back and try again tomorrow"

Hi Michael

Could you please escalate the case?

Apparently your techs don't even bother to look at the problem on their
side.

Message from the SNDS Website while trying to add IP Ranges:

"Sorry, whois.ripe.net will not let us do any more lookups today.
Please come back and try again tomorrow"

It is absolutely clear, that your tool is not able to query the RIPE
Database, because it apparently is 'over request limit' immediately on
every day since some weeks now.

Reply from your techs:

"Thank you for contacting SNDS support. I recommend reaching out to your
IP’s registrar to make sure the WHOIS records are up to date. The email
address in the WHOIS records is where the authorization form will be
sent."

AAARGH!

Mit freundlichen Grüssen

-Benoît Panizzon-
--
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

Re: [mailop] *Grumble* When is Amazon AWS going to properly inject trace headers..

[Tobias Herkula]

lol, but sure someone will come up with it and does not intent to make a joke

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)


From: Michael Wise 
Sent: Wednesday, September 26, 2018 10:11:10 PM
To: Tobias Herkula; Michael Peddemors; mailop@mailop.org
Subject: RE: [mailop] *Grumble* When is Amazon AWS going to properlyinject  
trace headers..



When will "we" start signing Received: headers?

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool<http://www.microsoft.com/en-us/download/details.aspx?id=18275> ?



-Original Message-
From: mailop  On Behalf Of Tobias Herkula
Sent: Wednesday, September 26, 2018 1:02 PM
To: Michael Peddemors ; mailop@mailop.org
Subject: Re: [mailop] *Grumble* When is Amazon AWS going to properly inject 
trace headers..



* Best practice, don't relay information about internal network structure to 
the public, so no internal trace header

* you can only "trust" headers that are signed and pass validation

* totally legit to generate mails on the outbound server



Kind regards,



/ Tobias Herkula

Manager Detection Anti Spam

Cyren (Berlin)





From: mailop mailto:mailop-boun...@mailop.org>> on 
behalf of Michael Peddemors 
mailto:mich...@linuxmagic.com>>

Sent: Wednesday, September 26, 2018 9:42:56 PM

To: mailop@mailop.org<mailto:mailop@mailop.org>

Subject: [mailop] *Grumble* When is Amazon AWS going to properly inject trace 
headers..



Just a rant..



Really hard to differentiate the good/bad/ugly ..



I am pretty sure the message is not generated on the outbound relay..

I don't really care HOW the record it, but as long as they record it..





Traffic leaving AWS..

(a14-188.smtp-out.amazonses.com)



Not a single received/trace header to be seen..



DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;

 s=lqlkfglxmkqqaie63ahwxqbtpuibzecv; d=instructure.com;

 t=1537990176;



h=Date:From:Reply-To:To:Message-ID:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding;

 bh=XYPsipG8tQ8ES1Ao8uS1HsWBUYvG8wDJFWyNsnVKghA=;

 b=RDb5aDuHy6D68gQItHw6vPezbfSou69QkfE15pTdTf8zRlYUyQOWlaf/sc1CDcCq

 EWRyC95CrcF7UJhJk1EkAwo7DFKjHidQFmEof7C3OT9LjSlP8ZSGGjcndlF/c0TtxbE

 4ql1nPaaw9bRVVKu7FzcVv5wLjZPL5a/A1WD7n74=

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;

 s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1537990176;



h=Date:From:Reply-To:To:Message-ID:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID;

 bh=XYPsipG8tQ8ES1Ao8uS1HsWBUYvG8wDJFWyNsnVKghA=;

 b=fPRUbKlHPLqj82LVsaAmjq1tpbGD2IPIUosKVyqTjLOXG+WaPp0gg1gymtlVDAEY

 5we+vhzW3s+zAyLsvTh1bJB3iuCBH9DYOPOyLaoxU8ZEiRceFGSOPgYJDcHiMQy+glf

 J5IkKw/ms/9hx2LFA5JR5dHqxsv+829hjwEPS5is=

Date: Wed, 26 Sep 2018 19:29:35 +





--

"Catch the Magic of Linux..."



Michael Peddemors, President/CEO LinuxMagic Inc.

Visit us at 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linuxmagic.comdata=02%7C01%7Cmichael.wise%40microsoft.com%7C1440a760e8f54ae632ca08d623ec0296%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735893896819211sdata=v8pqPRlxqdNOAm3ffVdPXhdcAVZDJN67T3wBtevcLo8%3Dreserved=0
 @linuxmagic A Wizard IT Company - For More Info 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.wizard.cadata=02%7C01%7Cmichael.wise%40microsoft.com%7C1440a760e8f54ae632ca08d623ec0296%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735893896819211sdata=q9RucTvTr6SSNXv8%2B1IuiSFLgk2x1d5SJrzS7CNfe3o%3Dreserved=0

"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.



604-682-0300 Beautiful British Columbia, Canada



This email and any electronic data contained are confidential and intended 
solely for the use of the individual or entity to which they are addressed.

Please note that any views or opinions presented in this email are solely those 
of the author and are not intended to represent those of the company.



___

mailop mailing list

mailop@mailop.org<mailto:mailop@mailop.org>

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7C1440a760e8f54ae632ca08d623ec0296%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735893896829216sdata=PVKRGpLTTAm5PloVXFMIN28O3d88TOpo7vdGVXXq64I%3Dreserved=0



___

mailop mailing list

mailop@mailop.org<mailto:mailop@mailop.org>

https://na01.safelinks.protec

Re: [mailop] *Grumble* When is Amazon AWS going to properly inject trace headers..

[Tobias Herkula]

* Best practice, don't relay information about internal network structure to 
the public, so no internal trace header
* you can only "trust" headers that are signed and pass validation
* totally legit to generate mails on the outbound server

Kind regards,

/ Tobias Herkula
Manager Detection Anti Spam
Cyren (Berlin)


From: mailop  on behalf of Michael Peddemors 

Sent: Wednesday, September 26, 2018 9:42:56 PM
To: mailop@mailop.org
Subject: [mailop] *Grumble* When is Amazon AWS going to properly inject trace 
headers..

Just a rant..

Really hard to differentiate the good/bad/ugly ..

I am pretty sure the message is not generated on the outbound relay..
I don't really care HOW the record it, but as long as they record it..


Traffic leaving AWS..
(a14-188.smtp-out.amazonses.com)

Not a single received/trace header to be seen..

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
 s=lqlkfglxmkqqaie63ahwxqbtpuibzecv; d=instructure.com;
 t=1537990176;

h=Date:From:Reply-To:To:Message-ID:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding;
 bh=XYPsipG8tQ8ES1Ao8uS1HsWBUYvG8wDJFWyNsnVKghA=;
 b=RDb5aDuHy6D68gQItHw6vPezbfSou69QkfE15pTdTf8zRlYUyQOWlaf/sc1CDcCq
 EWRyC95CrcF7UJhJk1EkAwo7DFKjHidQFmEof7C3OT9LjSlP8ZSGGjcndlF/c0TtxbE
 4ql1nPaaw9bRVVKu7FzcVv5wLjZPL5a/A1WD7n74=
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
 s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1537990176;

h=Date:From:Reply-To:To:Message-ID:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID;
 bh=XYPsipG8tQ8ES1Ao8uS1HsWBUYvG8wDJFWyNsnVKghA=;
 b=fPRUbKlHPLqj82LVsaAmjq1tpbGD2IPIUosKVyqTjLOXG+WaPp0gg1gymtlVDAEY
 5we+vhzW3s+zAyLsvTh1bJB3iuCBH9DYOPOyLaoxU8ZEiRceFGSOPgYJDcHiMQy+glf
 J5IkKw/ms/9hx2LFA5JR5dHqxsv+829hjwEPS5is=
Date: Wed, 26 Sep 2018 19:29:35 +


--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
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] Hotmail and 4.5.1 4.7.500 Server Busy with some

[Tobias Herkula]

Hi Emre,

Some thoughts from me, I imagine a lot of people from the sender community are 
lurking on this list, but it seems to me that for most of them the initial 
hiccup of new errors from Microsoft because of the switch from the “old” 
Hotmail infrastructure to the “new” Office365 one got solved.

And then we have this new error code that has a 4.5.x and a 4.7.x in it and we 
also know that Gmails and Yahoos approach to tip somebody, to look at the 
quality of the traffic  is also via sending 4xx errors.

So perhaps the fact that you still getting these errors and the fact that 
Microsoft support does not answer anymore, is based on that quality of your 
traffic?

At least for me, one of the first rules I learned was, always clean your own 
backyard before complaining and never threat someone who can help you.

So even if you are 100% sure, that your traffic is not only legal but also 
appreciated by the recipients with their mailboxes at Microsoft. Would it 
really hurt you to double check again and perhaps be a little more picky then 
last time?


Von: mailop [mailto:mailop-boun...@mailop.org] Im Auftrag von Emre Üst 
|euro.message|
Gesendet: Thursday, November 9, 2017 21:45
An: Michael Wise 
Cc: Maarten Oelering ; Benjamin BILLON 
; mailop@mailop.org
Betreff: Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some

Hello Michael ,

Your support team no longer answers the tickets. We still keep getting the 4xx 
error as server busy.

When will a legal explanation come from Hotmail (or Microsoft)?
Thank you


On Fri, Nov 3, 2017 at 10:21 PM, Michael Wise 
> wrote:

The AS codes are internal IDs, and are not ASNs.
Each one means something different.
Conflating the different codes is pretty much the same as saying, "My Mail Was 
Blocked!"
It's not overly helpful in diagnosing the issue.

Again, open a ticket; it's the only wat to get visibility on general issues.

  https://go.microsoft.com/fwlink/?LinkID=614866

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?

From: Maarten Oelering 
[mailto:maar...@postmastery.net]
Sent: Friday, November 3, 2017 12:22 AM
To: Benjamin BILLON >
Cc: "Emre Üst |euro.message|" 
>; 
mailop@mailop.org; Michael Wise 
>
Subject: Re: [mailop] Hotmail and 4.5.1 4.7.500 Server Busy with some

We are seeing this error on specific sender IPs. So “Server busy” may be 
intentionally and dependent on the sender.
There are also many versions of this error, with at least 6 different AS codes. 
Some occur after MAIL FROM, some occur after RCPT TO, and some occur after DATA.

Previously Hotmail said something like “We have limits for how many messages 
can be sent per hour and per day”. Very useful, you knew that reputation was 
the issue.
Now we just see “Server busy” with an internal code, and we have to guess 
what’s wrong. It would be helpful to know more about these AS codes. Or at 
least which ones are sender issues and which ones receiver issues. This will 
also relieve Microsoft support I guess.

Maarten Oelering
Postmastery

On 3 Nov 2017, at 07:49, Benjamin BILLON via mailop 
> wrote:

Sorry to interrupt, I just have a suggestion that maybe Michael could forward 
internally: there used to have a Status page for various Microsoft services, it 
either moved to some secret place or was removed. There's now a page for 
Office365 clients (however being myself client the page generates an asp error, 
but that's not the purpose of my message).

Could there be such a page somewhere again? If there are issues, just being 
aware of them will already help ESPs and senders to 1) be patient and 2) show 
to their clients or boss that yes, it happens, ISPs can have outages or 
problems too.
I have no idea what format it would take, probably a "working / not working" 
flag wouldn't be very useful, unless it's service by service (but I don't think 
MS would disclose such level of details).
Knowing if it's geographically limited could be interesting to.

Is it a realistic suggestion, or should I put this dream in the shredder?

Cheers,


--


Benjamin

2017-11-03 14:19 GMT+08:00 Emre Üst |euro.message| 
>:
Hi Michael,
Yes we are still seeing same code .

2017-11-03 09:17:02 "451 4.7.500 Server busy. Please try again later from 
[]. (AS3110)" received from 

Re: [mailop] About the Certified Senders Alliance

[Tobias Herkula]

By forcing Domain Alignment you would inevitably sacrifice the ability to send 
marketing mails for a huge amount of mom-and-pop shops. Even destroy the 
business model of a couple of ESPs. I don't argue against it, on my platform 
here, we even go the next step and try to force our customers to even hide the 
used subdomain (5321.From == t.example.com | 5322.From == example.com) signed 
by example.com and our own domain. But we do this out of data protection 
reasoning, we simply don't want to handle "answers" of recipients.

I also think that even if you are a mom-and-pop shop you should get your own 
domain and not using gmail.com or whatever as your primary business contact. 
But we are not there yet and pushing to hard on this change would simply engage 
an even bigger unwillingness to change the status quo.

The CSA requirements are being reevaluated every year and if the ISP 
representatives in the CSA counsel think it's time to tighten the rules it will 
happen. From my personal experience, they lag the ability to do an ongoing 
vetting of their members and it often hurts to see competitors not getting 
punished for obvious violations. But they bring something to the table that 
helps to clean up a lot of communication problems an ESP normally faces on the 
day to day operations.

PS: i will bring the domain alignment issue as topic to the discussion for 
adding that as an requirement for the next iteration of the CSA rules...

Kind regards,

Tobias Herkula
--
optivo GmbH
Product Management (Infrastructure)

From: David Hofstee <opentext.dhofs...@gmail.com>
Sent: Thursday, November 2, 2017 13:33
To: Tobias Herkula
Cc: mailop@mailop.org
Subject: Re: [mailop] About the Certified Senders Alliance

Hi Tobias,

> I'm working for an ESP who is member of the CSA and ECO and I'm one of the 
> biggest contender on the authentication requirements front, I don't think 
> that DMARC is an ESP responsibility, but think that an ESP should provide 
> everything necessary so that a Brand can use DMARC.
So you agree with me? Good.

> By forcing the ESP community of CSA to implement DMARC we would not help our 
> customers, we would simply give them a false feeling of having done 
> something, that does not solves the underlying problem.
I did not say DMARC. I said DMARC-type authentication (SPF and DKIM aligned to 
sender domain). I specifically made that distinction because I agree that 
requiring (a) DMARC (policy) is not our job.

That said: As an ESP you are not required to support DKIM and SPF aligned to 
the sender domain according to the CSA. Therefore an ESP could become a member 
and their customers may not be able to follow the advise to implement DMARC (as 
given in the guidelines, paragraph 3.10).

Yours,


David

On 2 November 2017 at 13:00, Tobias Herkula 
<tobias.herk...@optivo.com<mailto:tobias.herk...@optivo.com>> wrote:
I'm working for an ESP who is member of the CSA and ECO and I'm one of the 
biggest contender on the authentication requirements front, I don't think that 
DMARC is an ESP responsibility, but think that an ESP should provide everything 
necessary so that a Brand can use DMARC. By forcing the ESP community of CSA to 
implement DMARC we would not help our customers, we would simply give them a 
false feeling of having done something, that does not solves the underlying 
problem.

Kind regards,

Tobias Herkula
--
optivo GmbH
Product Management (Infrastructure)

From: mailop <mailop-boun...@mailop.org<mailto:mailop-boun...@mailop.org>> on 
behalf of David Hofstee 
<opentext.dhofs...@gmail.com<mailto:opentext.dhofs...@gmail.com>>
Sent: Thursday, November 2, 2017 11:19
To: Alexander Zeh
Cc: mailop@mailop.org<mailto:mailop@mailop.org>
Subject: Re: [mailop] About the Certified Senders Alliance

Hi Alexander,

Welcome to Mailop. A few somewhat criticising questions on the CSA:
- Complaint policy: What is the complaint policy for recipients? I tried to 
find it, but could not. Is anonymity guaranteed? Also not available in the data 
protection policy as found on the website. Please consider creating one.
- Oversight: Do you have a group of people that monitor compliance of senders 
(and not just complaints)?
- Unsubscribing. I subscribed to a few newsletters but I seem to notice a high 
"does not follow policy"-rate. Two examples (of 3 subscriptions, headers 
provided below):
 - Size of message: Google clips large messages. This is often where the 
unsubscribe link is. I did not see an unsubscribe link in this message.
 - List-Unsubscribe: Missing the required URL (requirement 2.21 of your 
admission criteria, see 
https://certified-senders.org/wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf
 ). Were these not tested at admission?
- Leadership: I think the authentication requirements in your

Re: [mailop] About the Certified Senders Alliance

[Tobias Herkula]

I'm working for an ESP who is member of the CSA and ECO and I'm one of the 
biggest contender on the authentication requirements front, I don't think that 
DMARC is an ESP responsibility, but think that an ESP should provide everything 
necessary so that a Brand can use DMARC. By forcing the ESP community of CSA to 
implement DMARC we would not help our customers, we would simply give them a 
false feeling of having done something, that does not solves the underlying 
problem.

Kind regards,

Tobias Herkula
--
optivo GmbH
Product Management (Infrastructure)

From: mailop <mailop-boun...@mailop.org> on behalf of David Hofstee 
<opentext.dhofs...@gmail.com>
Sent: Thursday, November 2, 2017 11:19
To: Alexander Zeh
Cc: mailop@mailop.org
Subject: Re: [mailop] About the Certified Senders Alliance

Hi Alexander,

Welcome to Mailop. A few somewhat criticising questions on the CSA:
- Complaint policy: What is the complaint policy for recipients? I tried to 
find it, but could not. Is anonymity guaranteed? Also not available in the data 
protection policy as found on the website. Please consider creating one.
- Oversight: Do you have a group of people that monitor compliance of senders 
(and not just complaints)?
- Unsubscribing. I subscribed to a few newsletters but I seem to notice a high 
"does not follow policy"-rate. Two examples (of 3 subscriptions, headers 
provided below):
 - Size of message: Google clips large messages. This is often where the 
unsubscribe link is. I did not see an unsubscribe link in this message.
 - List-Unsubscribe: Missing the required URL (requirement 2.21 of your 
admission criteria, see 
https://certified-senders.org/wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf
 ). Were these not tested at admission?
- Leadership: I think the authentication requirements in your policy are 
outdated. An ESP does not even need to support DMARC-type authentication nor is 
it a requirement for its customers to prove they are the real senders. Do you 
agree? Do you think the CSA should lead in setting requirements on these 
topics? Is the CSA able to change such requirements? Or is the CSA afraid of 
the current customer base (who might protest to adding authentication)? I would 
like to hear CSA's opinion on that.

Yours,


David

Example of message too large; the unsubscribe link is no longer visible in 
Gmail:
X-CSA-Complaints: 
whitelist-complai...@eco.de<mailto:whitelist-complai...@eco.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="msg_border_bwvx"
Date: Thu, 14 Sep 2017 22:01:07 -0700
To: xyz
From: HSE24 TV Programm 
<newslet...@angebote.hse24.de<mailto:newslet...@angebote.hse24.de>>
Reply-To: HSE24 TV Programm <serv...@hse24.de<mailto:serv...@hse24.de>>
Subject: Hui...jetzt wird's richtig stylisch

Example of List-Unsubscribe not having URL:
Date: Wed, 25 Oct 2017 15:01:33 + (GMT)
From: TUI <t...@email.tui.nl<mailto:t...@email.tui.nl>>
Reply-To: t...@email.tui.nl<mailto:t...@email.tui.nl>
To: xyz
Message-ID: <43699742.JavaMail.app@rbg62.f2is>
Subject: Welkom bij TUI
MIME-Version: 1.0
Content-Type: multipart/alternative; 
boundary="=_Part_334583_459599753.150234563453456"
x-mid: 2369485
X-CSA-Complaints: 
whitelist-complai...@eco.de<mailto:whitelist-complai...@eco.de>
x-rpcampaign: sp2375598
Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
x-job: 2375598
x-orgId: 15062
List-Unsubscribe: 
<mailto:v-removed-for-an...@bounce.email.tui.nl<mailto:v-removed-for-an...@bounce.email.tui.nl>?subject=Unsubscribe>


On 1 November 2017 at 17:33, Alexander Zeh 
<alexander@eco.de<mailto:alexander@eco.de>> wrote:
Hello everyone,

a friend informed me about a topic going on about the Certified Senders 
Alliance on this mailing list. That’s why I joined it.
I work for the CSA for many years now.
First and foremost of all:
It is definitely not true that a sender can join the CSA without any vetting. 
That statement bothered me a lot, because it’s a plain lie. Maybe because 
important information was lost in some communication between more than two 
parties, I don’t want to assume ill intent by anybody. In fact from every 
sender who wants to get certified and be whitelisted only about 10% make it 
through the whole process and are approved. Btw: the certification needs to be 
confirmed by the certification committee in which 2 seats out of 4 are major 
ISP partners.
I totally agree that if you have delivery issues it shouldn’t be the first step 
to reach out any certification program to fix it. And this is not how CSA 
works. If a sender has delivery issues, in 99% these problems are justified and 
self made. So what the CSA does is, that in the process we find potential 
issues and help senders to align with current best practices aka. the CSA 
admission criteria.  This whole 

Re: [mailop] About the Certified Senders Alliance

[Tobias Herkula]

I'm working for an ESP who is member of the CSA and ECO and I'm one of the 
biggest contender on the authentication requirements front, I don't think that 
DMARC is an ESP responsibility, but think that an ESP should provide everything 
necessary so that a Brand can use DMARC. By forcing the ESP community of CSA to 
implement DMARC we would not help our customers, we would simply give them a 
false feeling of having done something, that does not solves the underlying 
problem.

Kind regards,

Tobias Herkula
--
optivo GmbH
Product Management (Infrastructure)

From: mailop <mailop-boun...@mailop.org> on behalf of David Hofstee 
<opentext.dhofs...@gmail.com>
Sent: Thursday, November 2, 2017 11:19
To: Alexander Zeh
Cc: mailop@mailop.org
Subject: Re: [mailop] About the Certified Senders Alliance

Hi Alexander,

Welcome to Mailop. A few somewhat criticising questions on the CSA:
- Complaint policy: What is the complaint policy for recipients? I tried to 
find it, but could not. Is anonymity guaranteed? Also not available in the data 
protection policy as found on the website. Please consider creating one.
- Oversight: Do you have a group of people that monitor compliance of senders 
(and not just complaints)?
- Unsubscribing. I subscribed to a few newsletters but I seem to notice a high 
"does not follow policy"-rate. Two examples (of 3 subscriptions, headers 
provided below):
 - Size of message: Google clips large messages. This is often where the 
unsubscribe link is. I did not see an unsubscribe link in this message.
 - List-Unsubscribe: Missing the required URL (requirement 2.21 of your 
admission criteria, see 
https://certified-senders.org/wp-content/uploads/2017/07/CSA_Admission_Criteria.pdf
 ). Were these not tested at admission?
- Leadership: I think the authentication requirements in your policy are 
outdated. An ESP does not even need to support DMARC-type authentication nor is 
it a requirement for its customers to prove they are the real senders. Do you 
agree? Do you think the CSA should lead in setting requirements on these 
topics? Is the CSA able to change such requirements? Or is the CSA afraid of 
the current customer base (who might protest to adding authentication)? I would 
like to hear CSA's opinion on that.

Yours,


David

Example of message too large; the unsubscribe link is no longer visible in 
Gmail:
X-CSA-Complaints: 
whitelist-complai...@eco.de<mailto:whitelist-complai...@eco.de>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="msg_border_bwvx"
Date: Thu, 14 Sep 2017 22:01:07 -0700
To: xyz
From: HSE24 TV Programm 
<newslet...@angebote.hse24.de<mailto:newslet...@angebote.hse24.de>>
Reply-To: HSE24 TV Programm <serv...@hse24.de<mailto:serv...@hse24.de>>
Subject: Hui...jetzt wird's richtig stylisch

Example of List-Unsubscribe not having URL:
Date: Wed, 25 Oct 2017 15:01:33 + (GMT)
From: TUI <t...@email.tui.nl<mailto:t...@email.tui.nl>>
Reply-To: t...@email.tui.nl<mailto:t...@email.tui.nl>
To: xyz
Message-ID: <43699742.JavaMail.app@rbg62.f2is>
Subject: Welkom bij TUI
MIME-Version: 1.0
Content-Type: multipart/alternative; 
boundary="=_Part_334583_459599753.150234563453456"
x-mid: 2369485
X-CSA-Complaints: 
whitelist-complai...@eco.de<mailto:whitelist-complai...@eco.de>
x-rpcampaign: sp2375598
Feedback-ID: pod6_15062_2375598_891291414:pod6_15062:ibmsilverpop
x-job: 2375598
x-orgId: 15062
List-Unsubscribe: 
<mailto:v-removed-for-an...@bounce.email.tui.nl<mailto:v-removed-for-an...@bounce.email.tui.nl>?subject=Unsubscribe>


On 1 November 2017 at 17:33, Alexander Zeh 
<alexander@eco.de<mailto:alexander@eco.de>> wrote:
Hello everyone,

a friend informed me about a topic going on about the Certified Senders 
Alliance on this mailing list. That’s why I joined it.
I work for the CSA for many years now.
First and foremost of all:
It is definitely not true that a sender can join the CSA without any vetting. 
That statement bothered me a lot, because it’s a plain lie. Maybe because 
important information was lost in some communication between more than two 
parties, I don’t want to assume ill intent by anybody. In fact from every 
sender who wants to get certified and be whitelisted only about 10% make it 
through the whole process and are approved. Btw: the certification needs to be 
confirmed by the certification committee in which 2 seats out of 4 are major 
ISP partners.
I totally agree that if you have delivery issues it shouldn’t be the first step 
to reach out any certification program to fix it. And this is not how CSA 
works. If a sender has delivery issues, in 99% these problems are justified and 
self made. So what the CSA does is, that in the process we find potential 
issues and help senders to align with current best practices aka. the CSA 
admission criteria.  This whole 

Re: [mailop] T-Mobile Abuse Contact

[Tobias Herkula]

US or DE?


Kind regards,


/ Tobias Herkula


--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany


Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499


Email:    mailto:t.herk...@optivo.com
Website:  http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula


Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618


optivo A company of Deutsche Post DHL Group



 From:   Jaren Angerbauer <jarenangerba...@gmail.com> 
 To:   mailop <mailop@mailop.org> 
 Sent:   2017.01.27 22:43 
 Subject:   [mailop] T-Mobile Abuse Contact 


Hi,


Looking for a T-Mobile abuse contact I can work with -- we are seeing targeted 
W2 phishing to our executives.


Any assistance appreciated.


Thanks,






--Jaren Angerbauer

Proofpoint Postmaster



 

___
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