Re: [mailop] mailgun anybody? (variable sender address) time
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
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
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
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
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
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
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
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] [EXT] - Re: [EXT] - Dear sympatico.ca
What? I never said they were, I said do what we did with our issue. Please reread my response again. From: f...@dnsbed.com Sent: Saturday, March 25, 2023 6:02 AM To: Salvatore Jr Walter P Cc: mailop@mailop.org Subject: [EXT] - Re: [mailop] [EXT] - Dear sympatico.ca On 2023-03-25 13:54, Salvatore Jr Walter P via mailop wrote: > You could always do what we do with AT&T. We have been blocked for > months with no response and no reason given from AT&T. We are a > government agency, so we simply told our vendors and other entity's we > deal with that if they use AT&T or any ISP associated with them we will > not be able to communicate with them or use their services. After no > response from AT&T, we took the response it is no longer our issue and > let their customers complain that their incoming email is being blocked > and effecting their bottom line. from what I know Bell Canada is not the same as ATT global. they use different systems. if I am wrong please adjust me. Thanks ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [EXT] - Dear sympatico.ca
On 2023-03-25 13:54, Salvatore Jr Walter P via mailop wrote: You could always do what we do with AT&T. We have been blocked for months with no response and no reason given from AT&T. We are a government agency, so we simply told our vendors and other entity's we deal with that if they use AT&T or any ISP associated with them we will not be able to communicate with them or use their services. After no response from AT&T, we took the response it is no longer our issue and let their customers complain that their incoming email is being blocked and effecting their bottom line. from what I know Bell Canada is not the same as ATT global. they use different systems. if I am wrong please adjust me. Thanks ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] mailgun anybody? (variable sender address) time
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
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
