Re: [mailop] mailgun anybody? (variable sender address) time

[Gellner, Oliver via mailop]

> On 28.03.2023 at 12:51 Heiko Schlittermann via mailop wrote:
>
> Which leads to another question.
> *How* can I tell, in case I get a (faked) mail from bsi.de, that they do
> not use the domain for sending?
>
> - I can do "cold" recipient verification by an MX lookup for the sending
>  domain. bsi.de has MX records. I'd expect a null MX record if they do
>  not expect messages messages sent to them (which could be bounces).
>
> - If they would provide DMARC, even for the unused domain, they would help
>  me filtering messages claiming to come from their domain.

Well, I don’t know. Maybe someone should apply for a job as a postmaster there 
and fix all these things :)

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.


smime.p7s
Description: S/MIME cryptographic signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[John Levine via mailop]

It appears that Heiko Schlittermann via mailop  said:
>> Ok, I see your point. However as RFC 8020 mentions:
>> "in most known existing resolvers today, a cached nonexistence for a domain 
>> is not considered "proof" that there can be no child domains underneath."
>
>Oh, that I didn't see. So thanks for the pointer.
>
>But - they talk about resolvers and cache. I'd assume that asking the
>responsible server shouldn't return the NXDOMAIN, unless it doesn't
>follow the RFC?

Correct.  The whole point of RFC 8020 was to highlight buggy DNS servers that 
return NXDOMAIN
rather than NOERROR for empty nonterminals.

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

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Hello Oliver,


Gellner, Oliver via mailop  (Di 28 Mär 2023 12:18:59 CEST):
> > If the query for _domainkey.bsi.de would return a no-data answer, than
> > I can assume that they have someing below that name (most probably
> > selectors I do not know until I get a mail from them.)
> 
> Ok, I see your point. However as RFC 8020 mentions:
> "in most known existing resolvers today, a cached nonexistence for a domain 
> is not considered "proof" that there can be no child domains underneath."

Oh, that I didn't see. So thanks for the pointer.

But - they talk about resolvers and cache. I'd assume that asking the
responsible server shouldn't return the NXDOMAIN, unless it doesn't
follow the RFC?

> $ host _domainkey.rubrik.com.
> Host _domainkey.rubrik.com. not found: 3(NXDOMAIN)
> $ host spk._domainkey.rubrik.com.
> spk._domainkey.rubrik.com. is an alias for 
> spk.domainkey.u6545542.wl043.sendgrid.net.

Hm. Even asking one of the NS for this domain returns NXDOMAIN. That
would extend the RFC8020 statement to the servers too.

> bsi.de is a bad example as it really doesn't have any DKIM selectors, since 
> this domain is not used for sending emails.

Which leads to another question.
*How* can I tell, in case I get a (faked) mail from bsi.de, that they do
not use the domain for sending?

- I can do "cold" recipient verification by an MX lookup for the sending
  domain. bsi.de has MX records. I'd expect a null MX record if they do
  not expect messages messages sent to them (which could be bounces).

- If they would provide DMARC, even for the unused domain, they would help
  me filtering messages claiming to come from their domain.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Gellner, Oliver via mailop]

On 27.03.2023 at 11:08 Heiko Schlittermann via mailop wrote:

> Gellner, Oliver via mailop  (So 26 Mär 2023 10:46:22 CEST):
>>>;; Got answer:
>>>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16687
>>>   
>>>
>>> They have SPF, but no DKIM (NXDOMAIN for the _domainkey.bsi.de) Or
>>> did I miss something?
>>
>> The DKIM keys would be at ._domainkey.bsi.de

> Yes, but as long as the parent of *any* selector does not exist, there
> is a very good chance, that not any selector exists.
>
> If the query for _domainkey.bsi.de would return a no-data answer, than
> I can assume that they have someing below that name (most probably
> selectors I do not know until I get a mail from them.)

Ok, I see your point. However as RFC 8020 mentions:
"in most known existing resolvers today, a cached nonexistence for a domain is 
not considered "proof" that there can be no child domains underneath."

So in practice NXDOMAIN does not necessarily mean that no subkeys exist. Lena 
provided an example of such a case, here is another one:
$ host _domainkey.rubrik.com.
Host _domainkey.rubrik.com. not found: 3(NXDOMAIN)
$ host spk._domainkey.rubrik.com.
spk._domainkey.rubrik.com. is an alias for 
spk.domainkey.u6545542.wl043.sendgrid.net.

bsi.de is a bad example as it really doesn't have any DKIM selectors, since 
this domain is not used for sending emails.

--
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Bill Cole via mailop]

On 2023-03-27 at 06:46:04 UTC-0400 (Mon, 27 Mar 2023 13:46:04 +0300)
Lena--- via mailop 
is rumored to have said:

[...]
For NS I currently use the registrar. Its web-interface allowed me to 
create

the TXT record for a selector. The parent _domainkey - NXDOMAIN.


So this isn't what you're referring to?

# dig _domainkey.lena.kiev.ua

; <<>> DiG 9.18.12 <<>> _domainkey.lena.kiev.ua
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11967
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Slavko via mailop]

Dňa 27. marca 2023 13:20:06 UTC používateľ Heiko Schlittermann via mailop 
 napísal:

>If the DNS name xxx._domainkey.example.com exists, then
>_domainkey.example.com exists too. It doesn't have any data (no TXT, A,
>AAA, … record). But asking for _domainkey.example.com must not return
>NXDOMAIN then.

I agree, by theory and by RFC, but despite that i meet that
NXDOMAIN (even from payed service) in real word and
it was main reason to change that DNS provider. Now it
works as expected (and as you and RFC describes).

If you want to reproduce that broken behaviour with
PowerDNS you can (i dont use PowerDNS, thus only
from my tests and from head -- can be incomplete):

1. create "some" zone with SQL backend (SQLite is enough)
2. setup DNSSEC with NSEC3 and sign it
3. point your DNS to it (i did it via Unbound, including DNSSEC related things)
4. verify that it works, including DNSSEC, eg. via dig
5. add records, including empty non-terminals (ENT), eg. these DKIM records, 
directly via SQL
6. try to fetch the new records and you will see NXDOMAIN for ENT

One have to run "magic" PowerDNS's command to
fix/regenerate things after direct SQL manipulation
(which i don't remember too). If zone is backed in file,
that is fixed automatically, but not with SQL (at least
was not about 1,5 year ago, when i try it).

BTW, that i was able to do only with help of people
from #DNS IRC channel...

Of course, make sure that you didn't disabled that
"nothing below" (RFC 8020) in resolver, which is AFAIK
enabled by default in Unbound (harden-below-nxdomain)
and was enabled on some public DNSs resolvers too in
that time (i used them to verify, that my resolver is not
wrong in this).

regards


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

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Slavko via mailop  (Mo 27 Mär 2023 14:37:54 CEST):
> That problem is more visible with DNSSEC and
> DNS "nothing under" (sorry i don't remember exact
> name nor RFC). The result is, that when _domainkey
> returns NXDOMAIN, anything under it is considered
> as NXDOMAIN too...

If the DNS name xxx._domainkey.example.com exists, then
_domainkey.example.com exists too. It doesn't have any data (no TXT, A,
AAA, … record). But asking for _domainkey.example.com must not return
NXDOMAIN then.

Compare the output (stripped by me)

dig _domainkey.amazon.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38009
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

dig _domainkey.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44893
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Zero answers in both cases, but the status' differ. That's the key point,
from *my* PoV.

Simple clients will report "not found / not existing" in both cases.
So from that point that's no difference.


Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Slavko via mailop]

Dňa 27. marca 2023 11:10:58 UTC používateľ Heiko Schlittermann via mailop 
 napísal:

>Do you have an example where ._domainkey. exists, but
>_domainkey. returns NXDOMAIN?

Yes, my previous DNS provider had that broken their
DNS server(s). I had to create dummy TXT record for
_.domainkey to get my DKIM keys to work.

The worst part was, that they was not able to fix it,
and blamed PowerDNS. When i prove them, that it
is their misconfiguration (or lack of understanding?),
they stops to respond. I changed DNS provider about
year ago, thus i have no example now.

That problem is more visible with DNSSEC and
DNS "nothing under" (sorry i don't remember exact
name nor RFC). The result is, that when _domainkey
returns NXDOMAIN, anything under it is considered
as NXDOMAIN too...

regards


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

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Lena--- via mailop  (Mo 27 Mär 2023 12:46:04 CEST):
> > > > They have SPF, but no DKIM (NXDOMAIN for the _domainkey.bsi.de)
> > > > Or did I miss something?
> > > 
> > > The DKIM keys would be at ._domainkey.bsi.de
> > 
> > Yes, but as long as the parent of *any* selector does not exist, there
> > is a very good chance, that not any selector exists.
> > 
> > If the query for _domainkey.bsi.de would return a no-data answer, than
> > I can assume that they have someing below that name (most probably
> > selectors I do not know until I get a mail from them.)
> 
> For NS I currently use the registrar. Its web-interface allowed me to create
> the TXT record for a selector. The parent _domainkey - NXDOMAIN.

Do you have an example where ._domainkey. exists, but
_domainkey. returns NXDOMAIN?

-- 
Heiko


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[hg user via mailop]

Yes I do but when the phishing is in italian I know (and use) one
updated sources of patterns but sometimes it is late...

Just as an example, a little bit of one body rule I wrote:

clicca qui per (verificare|confermare|favore|riconvalidare|aggiornare)
(la tua e-mail|il tuo account)

in english it sounds like

click here to (verify|confirm|reconfirm|update) (your email|your account)

The rule has a score of 5.7 (5.6 is spam) but sometimes, when no rbl
is fired and it is a never seen before wording unknown to bayes,
DKIM/DMARC negative score don't flag the message.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Lena--- via mailop]

> > > They have SPF, but no DKIM (NXDOMAIN for the _domainkey.bsi.de)
> > > Or did I miss something?
> > 
> > The DKIM keys would be at ._domainkey.bsi.de
> 
> Yes, but as long as the parent of *any* selector does not exist, there
> is a very good chance, that not any selector exists.
> 
> If the query for _domainkey.bsi.de would return a no-data answer, than
> I can assume that they have someing below that name (most probably
> selectors I do not know until I get a mail from them.)

For NS I currently use the registrar. Its web-interface allowed me to create
the TXT record for a selector. The parent _domainkey - NXDOMAIN.

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

Re: [mailop] mailgun anybody? (variable sender address) time

[Jaroslaw Rafa via mailop]

Dnia 26.03.2023 o godz. 17:24:32 Grant Taylor via mailop pisze:
> 
> Or are you referring to IPs that two different names resolve to?

Yes, I do. I have only one server. Of course, I can try to work around this,
for example I can put my friend's server (that I know does not have any mail
service on it) as a first MX, or I can put the address of my home Internet
connection (I happen to have a static one) - also no mail service there. But
these are poor workarounds for me.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Gellner, Oliver via mailop  (So 26 Mär 2023 10:46:22 CEST):
> >;; Got answer:
> >;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16687
> >   
> >
> > They have SPF, but no DKIM (NXDOMAIN for the _domainkey.bsi.de)
> > Or did I miss something?
> 
> The DKIM keys would be at ._domainkey.bsi.de

Yes, but as long as the parent of *any* selector does not exist, there
is a very good chance, that not any selector exists.

If the query for _domainkey.bsi.de would return a no-data answer, than
I can assume that they have someing below that name (most probably
selectors I do not know until I get a mail from them.)

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Grant Taylor via mailop]

On 3/26/23 2:32 PM, Jaroslaw Rafa via mailop wrote:

One big downside: you need to have two MXes.


I don't view multiple MX records as a bad thing.

Or are you referring to IPs that two different names resolve to?  -- 
There are multiple ways around this.


I don't understand ~> appreciate the problem you're talking about.  Will 
you please elaborate so that I hopefully understand?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Jaroslaw Rafa via mailop]

Dnia 26.03.2023 o godz. 01:27:21 hg user via mailop pisze:
> 
> Only RBL (ip, url or hash), bayes from past phishing or some handmade rules
> can detect them, and their score may not sum up to the spam threshold (I
> have to review and rescore these handmade rules).

Nobody really doing any content analysis anymore in spam filtering these
days?
At least the examples from A) group you mentioned should be caught by any
decent content analysis tool (like SpamAssassin for example). Even if they
are coming from otherwise trusted sites, the score from content analysis
should be big enough to mark them as spam.
The B) group, specifically tailored for your website, seem to be something
more sophisticated and may actually require some hand-crafted rules to catch
them.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Jaroslaw Rafa via mailop]

Dnia 24.03.2023 o godz. 17:33:32 Grant Taylor via mailop pisze:
> NoListing works by causing the sending server to cascade through
> multiple MXs.
> 
> First MX either doesn't respond /or/ sends a TCP reset.  Thereby
> causing the sending MTA to try the next MX.
> 
> The next MX responds like normal.

One big downside: you need to have two MXes.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Gellner, Oliver via mailop]

> On 25.03.2023 at 22:26 Heiko Schlittermann via mailop wrote:
>
> hg user via mailop  (Sa 25 Mär 2023 18:39:06 CET):
>> A. extortion messages like "I recorded you doing bad things, pay me". Tons
>> deleted, but some in the inboxes.
>>
>> B. phishing, some generic, some specific for our web mail interface. The
>> latter, sometimes, carry our logo in the fake page...
>
> A good share of such messages use the reciepint's domain as sender.
> Proper protection here can help.
>
> Another share uses generally trusted domains. If you're lucky, these
> trusted domains publish DMARC records.

Hmm, I don’t see many of those anymore. They are easy to block anyway.

> Ok, and the last share uses non-DMARC domains OR From: heaaders like
>
> From: "your-b...@example.com" 
>
> with stupid mailclients only showing the display part of the address.

In the last couple of years, most phishing emails I came across don’t even try 
anymore to forge the From-header address, likely due to the increased adoption 
of DMARC. They are sent from compromised servers or mailboxes and use whatever 
sender address those systems have, eg „Your boss“ 
 or „My Bank “ 
.

Unfortunately as you mentioned some popular email clients don’t show the email 
addresses or try to make smart guesses to „map“ the sender address of the 
phishing email to the real account.


> Yes. We have the bsi.de (governmental agency for security and data
> protection).
>
>$ dig _dmarc.bsi.de txt
>; <<>> DiG 9.16.37-Debian <<>> txt _dmarc.bsi.de
>;; global options: +cmd
>;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16687
>   
>
> They have SPF, but no DKIM (NXDOMAIN for the _domainkey.bsi.de)
>
> Or did I miss something?

The DKIM keys would be at ._domainkey.bsi.de

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Andrew C Aitchison via mailop]

On Sat, 25 Mar 2023, Slavko via mailop wrote:


Dňa 25. marca 2023 17:11:48 UTC používateľ Andrew C Aitchison via mailop 
 napísal:


On Sat, 25 Mar 2023, Grant Taylor via mailop wrote:

I never understood different envelope senders for each attempt of a given 
message.  --  I can see different envelope senders per message, a la. VERP. But 
I would naively expect each message to have a fixed envelope sender and 
recipient from submission time until delivery time.


I guess that having something to trace individual attempts
though the logs is useful if you are working at scale
and the typical user is more likely to report the sender address than the 
message id ?


I believe that here are better ways to track individual attempts
in logs (eg. concantenate sender/MID & time, or custom log entry),
than change sender every time. Thus it is either not this case
or really naive way (with  expose that envelope sender is not real).


I am guessing that the help desk need a key into the logs
and they cannot assume that the customer has provided the headers.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[hg user via mailop]

Sorry, I was not clear.

A lot of phishing that passes the antispam checks comes from *hacked*
accounts from universities and government agencies. So SPF, DKIM, DMARC,
all these pass and give negative score.

Only RBL (ip, url or hash), bayes from past phishing or some handmade rules
can detect them, and their score may not sum up to the spam threshold (I
have to review and rescore these handmade rules).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Grant Taylor via mailop]

On 3/25/23 3:10 PM, Heiko Schlittermann via mailop wrote:
We used MX sandwiching/NoListing on our own MXs and had issues sending 
messages to remote sites which did sender verification via a poorly 
implemented callback.


So, is it fair to say, that you had problems sending to site that used a 
questionable implementation of a questionable practice?


Please note the question mark above, I don't want to blame *any* 
vendor without proof. Time passed since then, maybe they improved 
their callback implementation.


ACK

1st MX: TCP RST (either by open firewall and no listener on port 25, 
OR done by the firewall directly (iptables … -j REJECT --reject-with 
tcp-rst)

2nd MX: listener on port 25
3rd MX: firewall, dropping incoming TCP SYN


The "sandwich" makes more sense when depicted like that.

I was just thinking in terms of a non-answering (at the SMTP level) MX 
/before/ any and all other MXs.


I assume that there is (are) one (or more) functional MX(s) at a lower 
priority / higher number.


Conversely, it seems like the "MX sandwich" is a specific configuration 
that happens to involve No Listing.



That's what I understand as a sandwich ;)


Fair enough.

The configuration I'm using is a bit different:

1st MX:  No Listing
2nd MX:  standard primary
3rd MX:  standard secondary
4th MX:  anti-spam solution looking for bad actors.

Proper sending sites try the 1st one, and fastly move on to the second. 
Poorly implemented senders either give up after the 1st one, or try 
to be clever and use the 3rd one (as this one is often less prepared 
for spam rejection as the primaries), and hopefully give up.


That's why I have the 4th MX.

Same here. Unfortunately Renate from mailgun didn't respond yet. 
I'd like to hear their intentions with this approach.


I don't know if it's the case or not, but I've heard that it might be in 
the same spirit as to why different IPs in the network send subsequent 
attempts instead of the same host ~> IP as the first time.  Namely 
multiple systems sharing a common spool of queued messages waiting to be 
re-tried.


But even that tends to have the same envelope from in the instances that 
I've spent time looking at.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

hg user via mailop  (Sa 25 Mär 2023 18:39:06 CET):
> A. extortion messages like "I recorded you doing bad things, pay me". Tons
> deleted, but some in the inboxes.
> 
> B. phishing, some generic, some specific for our web mail interface. The
> latter, sometimes, carry our logo in the fake page...

A good share of such messages use the reciepint's domain as sender.
Proper protection here can help.

Another share uses generally trusted domains. If you're lucky, these
trusted domains publish DMARC records.

Ok, and the last share uses non-DMARC domains OR From: heaaders like

From: "your-b...@example.com" 

with stupid mailclients only showing the display part of the address.

> Almost 100% of B and most of A comes from hacked mailboxes, from university
> or government agencies, so standard MTAs that won't be blocked by NoListing
> nor greylisting.

Yes. We have the bsi.de (governmental agency for security and data
protection).

$ dig _dmarc.bsi.de txt
; <<>> DiG 9.16.37-Debian <<>> txt _dmarc.bsi.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16687
   

They have SPF, but no DKIM (NXDOMAIN for the _domainkey.bsi.de)

Or did I miss something?

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Grant Taylor via mailop  (Sa 25 Mär 2023 17:07:23 CET):
> Are you indicating that you had problems sending to others who were using
> NoListing / MX sandwiching?  Or are you saying that your equipment had
> problems going through NoListing / MX sandwiching in your outbound
> infrastructure?

We used MX sandwiching/NoListing on our own MXs and had issues sending
messages to remote sites which did sender verification via a poorly
implemented callback.

> > Some appliances (barracuda?) on the remote end implemented sender
…
> Well ... the idea is that a proper / RFC compliant SMTP stack is used ...
> which rules out some vendors.  }:-)
> 
> I've never been a fan of Barracuda for a number of reasons.

Please note the question mark above, I don't want to blame *any* vendor
without proof. Time passed since then, maybe they improved their
callback implementation.

> Would you mind elaborating how you tested NoListing / MX sandwiching? Did
> you 1) timeout connections, 2) send a TCP reset, or 3) send an ICMP error?

1st MX: TCP RST (either by open firewall and no listener on port 25, OR
done by the firewall directly (iptables … -j REJECT
--reject-with tcp-rst)
2nd MX: listener on port 25
3rd MX: firewall, dropping incoming TCP SYN

That's what I understand as a sandwich ;)
Proper sending sites try the 1st one, and fastly move on to the second.
Poorly implemented senders either give up after the 1st one, or try to
be clever and use the 3rd one (as this one is often less prepared for
spam rejection as the primaries), and hopefully give up.

> > With our current greylisting implementation (using MAIL-FROM/RCPT-TO) as
> > key, we didn't have issues so far. Until mailgun started (?) using
> > variable senders for each delivery attempt.
> 
> I never understood different envelope senders for each attempt of a given
> message.  --  I can see different envelope senders per message, a la. VERP.
> But I would naively expect each message to have a fixed envelope sender and
> recipient from submission time until delivery time.

Same here. Unfortunately Renate from mailgun didn't respond yet.
I'd like to hear their intentions with this approach.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Slavko via mailop]

Dňa 25. marca 2023 17:11:48 UTC používateľ Andrew C Aitchison via mailop 
 napísal:
>
>On Sat, 25 Mar 2023, Grant Taylor via mailop wrote:
>> I never understood different envelope senders for each attempt of a given 
>> message.  --  I can see different envelope senders per message, a la. VERP. 
>> But I would naively expect each message to have a fixed envelope sender and 
>> recipient from submission time until delivery time.
>
>I guess that having something to trace individual attempts
>though the logs is useful if you are working at scale
>and the typical user is more likely to report the sender address than the 
>message id ?

I believe that here are better ways to track individual attempts
in logs (eg. concantenate sender/MID & time, or custom log entry),
than change sender every time. Thus it is either not this case
or really naive way (with  expose that envelope sender is not real).

I can only guess, what they try to do, but two things comes into
my mind:

+ pair bounces with exact delivery attempts
+ fool recipient's MTA filtering, eg. per sender (aka customer/campaign) 
reputation

IMO both are questionable...

regards


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

Re: [mailop] mailgun anybody? (variable sender address) time

[hg user via mailop]

Really interesting thread. But like most other threads it seems to me that
the result is always the same: *it depends*.

In the last months my main pains were:

A. extortion messages like "I recorded you doing bad things, pay me". Tons
deleted, but some in the inboxes.

B. phishing, some generic, some specific for our web mail interface. The
latter, sometimes, carry our logo in the fake page...

Almost 100% of B and most of A comes from hacked mailboxes, from university
or government agencies, so standard MTAs that won't be blocked by NoListing
nor greylisting.

Probably I can propose a 1 minute greylisting so that some RBLs can catch
up, but I think it is still not enough.


What is your experience?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Andrew C Aitchison via mailop]

On Sat, 25 Mar 2023, Grant Taylor via mailop wrote:
I never understood different envelope senders for each attempt of a given 
message.  --  I can see different envelope senders per message, a la. VERP. 
But I would naively expect each message to have a fixed envelope sender and 
recipient from submission time until delivery time.


I guess that having something to trace individual attempts
though the logs is useful if you are working at scale
and the typical user is more likely to report the sender address 
than the message id ?


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Grant Taylor via mailop]

On 3/25/23 2:25 AM, Heiko Schlittermann via mailop wrote:

Ah, ok, that's what I know as MX sandwiching.


Interesting.  I'll have to research that phrasing to see if I can learn 
more about it.


Ok, that was your point. Sure. We tried this (NoListing, MX 
sandwiching) for a while and had problems when *sending* messages.


Are you indicating that you had problems sending to others who were 
using NoListing / MX sandwiching?  Or are you saying that your equipment 
had problems going through NoListing / MX sandwiching in your outbound 
infrastructure?


Some appliances (barracuda?) on the remote end implemented sender 
verification as callback, but where stupid enough to contact the 1st 
MX only (the one which did the TCP RST). As a result, they didn't 
accept our mails.


Well ... the idea is that a proper / RFC compliant SMTP stack is used 
... which rules out some vendors.  }:-)


I've never been a fan of Barracuda for a number of reasons.

Would you mind elaborating how you tested NoListing / MX sandwiching? 
Did you 1) timeout connections, 2) send a TCP reset, or 3) send an ICMP 
error?


I've got an IP bound w/o a daemon listening, so the TCP/IP stack 
responds as if the SMTP service isn't currently running.  --  I prefer 
that over a timeout as I think it's a fail hard ~> fail fast ~> move on 
to recover type sequence of events.


It's good to hear about others that have tried No Listing / MX sandwich 
and their experience therewith.


With our current greylisting implementation (using MAIL-FROM/RCPT-TO) 
as key, we didn't have issues so far. Until mailgun started (?) using 
variable senders for each delivery attempt.


I never understood different envelope senders for each attempt of a 
given message.  --  I can see different envelope senders per message, a 
la. VERP.  But I would naively expect each message to have a fixed 
envelope sender and recipient from submission time until delivery time.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Bill Cole via mailop  (Sa 25 Mär 2023 03:55:26 CET):
> > What does this change? From senders PoV it is a temporary error. The
> > sender will retry.
> 
> The point of greylisting and "NoListing" is to eliminate the spammers who do
> not retry. They are harmless (aside from delay) for mail being haqndlked by
> a proper MTA that implements a MX fallback and retry strategy.

Sure. The delay can be eliminated at least for sending sites that are
known to retry. (That's what our greylisting implementation does.)

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Grant Taylor via mailop  (Sa 25 Mär 2023 00:33:32 CET):
> On 3/24/23 4:01 PM, Heiko Schlittermann via mailop wrote:
> 
> NoListing works by causing the sending server to cascade through multiple
> MXs.

> First MX either doesn't respond /or/ sends a TCP reset.  Thereby causing the
> sending MTA to try the next MX.
> 
> The next MX responds like normal.

Ah, ok, that's what I know as MX sandwiching.

> The cascading from one MX to the other MX achieves a very similar result as
> grey listing.  But it does so in a way that is indifferent to the actual
> addresses used.

Ok, that was your point. Sure. We tried this (NoListing, MX sandwiching)
for a while and had problems when *sending* messages.

Some appliances (barracuda?) on the remote end implemented sender
verification as callback, but where stupid enough to contact the 1st MX
only (the one which did the TCP RST). As a result, they didn't accept
our mails.

> With no state to maintain it doesn't matter what the envelope from is,
> variable or static.

With our current greylisting implementation (using MAIL-FROM/RCPT-TO) as
key, we didn't have issues so far. Until mailgun started (?) using
variable senders for each delivery attempt.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Bill Cole via mailop]

On 2023-03-24 at 18:01:50 UTC-0400 (Fri, 24 Mar 2023 23:01:50 +0100)
Heiko Schlittermann via mailop 
is rumored to have said:


What does this change? From senders PoV it is a temporary error. The
sender will retry.


The point of greylisting and "NoListing" is to eliminate the spammers 
who do not retry. They are harmless (aside from delay) for mail being 
haqndlked by a proper MTA that implements a MX fallback and retry 
strategy.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Grant Taylor via mailop]

On 3/24/23 4:01 PM, Heiko Schlittermann via mailop wrote:

Hm. Maybe I'm stupid.


Nope.  I'm sure that's not the case.  We all learn things when exposed 
to new things.  ;-)



What does this change? From senders PoV it is a temporary error. The
sender will retry.


NoListing works by causing the sending server to cascade through 
multiple MXs.


First MX either doesn't respond /or/ sends a TCP reset.  Thereby causing 
the sending MTA to try the next MX.


The next MX responds like normal.

The cascading from one MX to the other MX achieves a very similar result 
as grey listing.  But it does so in a way that is indifferent to the 
actual addresses used.


There is also no state to be maintained by the receiving system.


And on my side I still do not recognise their 2nd attempt, if they use a
variable MAIL-FROM.


With no state to maintain it doesn't matter what the envelope from is, 
variable or static.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Grant Taylor via mailop  (Fr 24 Mär 2023 16:42:07 CET):
> On 3/24/23 1:24 AM, Renaud Allard via mailop wrote:
> > I would say, that's called greylisting. But with a changing envelope,
> > the message has no chances to pass any greylisting process. The
> > behaviour from mailgun would make them unable to pass any kind of
> > greylisting anywhere.
> 
> That's one of the advantages of NoListing (TCP reset or timeout on high
> priority / low numbered MX) in that it would be compatible with this.

Hm. Maybe I'm stupid.

What does this change? From senders PoV it is a temporary error. The
sender will retry.

And on my side I still do not recognise their 2nd attempt, if they use a
variable MAIL-FROM.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Grant Taylor via mailop]

On 3/24/23 1:24 AM, Renaud Allard via mailop wrote:
I would say, that's called greylisting. But with a changing envelope, 
the message has no chances to pass any greylisting process. The 
behaviour from mailgun would make them unable to pass any kind of 
greylisting anywhere.


That's one of the advantages of NoListing (TCP reset or timeout on high 
priority / low numbered MX) in that it would be compatible with this.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Julian Bradfield via mailop]

On 2023-03-24, Heiko Schlittermann via mailop  wrote:
> fh--- via mailop  (Fr 24 Mär 2023 03:56:53 CET):
>> > does anybody from mailgun read here?
>> > Your messages are tmprejected at our systems, w/o any chance to pass
>> > ever.
>> b/c they were sending spams?
>
> I can't tell, because we rejected them with 4xx and they do not pass the
> greylisting with a changing sender address.

I use the following snippets in my greylisting code, which pretty much
deals with the changing sender address problem, and also, partially,
the mail farm problem.

---
# to do greylisting sensibly on mail farms, we want to use 
# the /24 of an IPv4 address, or the /48 of an IPv6 address 
# try with ipv first 
SENDER_HOST_PREFIX = ${if match{$sender_host_address}{:}{${mask:$sender_host_ad\
dress/48}}{${mask:$sender_host_address/24}}} 
 
# also, because of all those sites that put a key into the sender address, 
# if the localpart is longer than, say, 30 charactersm, we'll just replace 
# it with a fixed string 
SENDER_ADDRESS_COMPACTED = ${if >{${strlen:$sender_address_local_part}}{30} {ke\
yedsender@$sender_address_domain}{$sender_address}} 
---
# and this is the normal greylist check 
condition  = ${readsocket{/var/run/greylistd/socket}\ 
 {--grey \ 
  SENDER_HOST_PREFIX \ 
  SENDER_ADDRESS_COMPACTED \ 
  $local_part@$domain}\ 
 {5s}{}{false}} 
---
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

fh--- via mailop  (Fr 24 Mär 2023 03:56:53 CET):
> > does anybody from mailgun read here?
> > Your messages are tmprejected at our systems, w/o any chance to pass
> > ever.
> b/c they were sending spams?

I can't tell, because we rejected them with 4xx and they do not pass the
greylisting with a changing sender address.

But I *think*, it is more ham than spam.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Renaud Allard via mailop  (Fr 24 Mär 2023 08:24:20 CET):
> > > does anybody from mailgun read here?
> > > Your messages are tmprejected at our systems, w/o any chance to pass
> > > ever.
> > 
> > Why are you using tmp rejections for something permanent?

Yes, it *is* greylisting.

https://gitea.schlittermann.de/IUS/libexim-grey-perl

> I would say, that's called greylisting. But with a changing envelope, the
> message has no chances to pass any greylisting process. The behaviour from
> mailgun would make them unable to pass any kind of greylisting anywhere.

Most greylist implementations (IMHO) do the greylisting based on the
sending IP, which would work here, as the delivery attemps are
originiated from the same IP.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Jaroslaw Rafa via mailop]

Dnia 24.03.2023 o godz. 08:24:20 Renaud Allard via mailop pisze:
> 
> I would say, that's called greylisting. But with a changing
> envelope, the message has no chances to pass any greylisting
> process. The behaviour from mailgun would make them unable to pass
> any kind of greylisting anywhere.

There are quite a few senders that do this. Some greylisting software (like
postgrey, which is probably the reference implementation for greylisting) by
default exempt from greylisting a bunch of senders that do this. Among them
are amazon.com, google.com, microsoft.com and orange.fr for example. I have
myself added facebook.com and amazonses.com to my exempt list as I noticed
the same behavior with them. Probably you need to do the same for mailgun.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Renaud Allard via mailop]

On 3/23/23 16:31, Laura Atkins via mailop wrote:



On 23 Mar 2023, at 14:47, Heiko Schlittermann via mailop 
 wrote:


Hi,

does anybody from mailgun read here?
Your messages are tmprejected at our systems, w/o any chance to pass
ever.


Why are you using tmp rejections for something permanent?



I would say, that's called greylisting. But with a changing envelope, 
the message has no chances to pass any greylisting process. The 
behaviour from mailgun would make them unable to pass any kind of 
greylisting anywhere.


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[fh--- via mailop]

On 2023-03-23 22:47, Heiko Schlittermann via mailop wrote:

Hi,

does anybody from mailgun read here?
Your messages are tmprejected at our systems, w/o any chance to pass
ever.



b/c they were sending spams?

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

Re: [mailop] mailgun anybody? (variable sender address) time

[Heiko Schlittermann via mailop]

Laura Atkins via mailop  (Do 23 Mär 2023 16:31:38 CET):
> > does anybody from mailgun read here?
> > Your messages are tmprejected at our systems, w/o any chance to pass
> > ever.
> Why are you using tmp rejections for something permanent?

Depending on the on several conditions the messages would pass at one of
the next delivery attempts.

Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
 SCHLITTERMANN.de  internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --- key ID: F69376CE -


signature.asc
Description: PGP signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailgun anybody? (variable sender address) time

[Renate Burns via mailop]

Hi Heiko,

Feel free to hit me up off list about this and I'll be happy to take a look at 
it!

Thanks,
Renate

From: mailop  on behalf of Heiko Schlittermann via 
mailop 
Sent: Thursday, March 23, 2023 9:47 AM
To: mailop 
Subject: [mailop] mailgun anybody? (variable sender address) time

Hi,

does anybody from mailgun read here?
Your messages are tmprejected at our systems, w/o any chance to pass
ever.

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

Re: [mailop] mailgun anybody? (variable sender address) time

[Laura Atkins via mailop]

> On 23 Mar 2023, at 14:47, Heiko Schlittermann via mailop  
> wrote:
> 
> Hi,
> 
> does anybody from mailgun read here?
> Your messages are tmprejected at our systems, w/o any chance to pass
> ever.

Why are you using tmp rejections for something permanent?

laura 

-- 
The Delivery Experts

Laura Atkins
Word to the Wise
la...@wordtothewise.com 

Email Delivery Blog: http://wordtothewise.com/blog  






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