My experience with fallback is likely to be the same as others will
encounter/have encountered.
Around two years ago, we also investigated disabling that functionality in our
cloud platform, as we found many outbound emails sitting in the queue to these
fallback entries. These were semi-legit e
According to John Levine via mailop :
>>>It would, but fallback to A has been part of SMTP since RFC 974 in 1986 and
>>>it's
>>>not going away now.
>>
>>I believe it should go away asap.
I asked the guy who wrote 974 who says fallback to A was intended to be
permanent.
And so it is.
There was a
On 2/3/25 3:41 AM, Doug via mailop wrote:
What is The Way™, if any, to deal with backscatter?
Take a look at milter-null from SirWumpus / Anthony Howe / SnertSoft:
Link - SirWumpus / milter-null
- https://github.com/SirWumpus/milter-null
milter-null works by adding a header to outgoing messa
It appears that Matus UHLAR - fantomas via mailop said:
>On 30.01.25 13:28, John Levine via mailop wrote:
>>That would reject all mail from Gmail and every other large provider I know.
>>Seems a bit extreme. It'd even reject mail from my tiny system since the
>>inbound and outbound MTAs are on di
Am 03.02.2025 um 04:41:00 Uhr schrieb Doug via mailop:
> It's backscatter from a phishing campaign. At first, I tried to
> contact the server owner through their abuse@ account. They have us
> blocked for ... "sending spam". (is this characteristic? do
> blocklists not do SPF verification? can som
Folks
Some of you are already aware of this having received rejection messages - I
put a filter on this thread at the weekend because I believe it's better
discussed on fora or lists devoted to it.
Please don't further reply as any more messages will be discarded automatically.
Please remember
On 2025-02-03 19:21:26 (+0800), Niels Dettenbach via mailop wrote:
Am Freitag, 31. Januar 2025, 01:41:58 schrieb Matt Palmer via mailop:
The title of RFC7505 is "A "Null MX" No Service Resource Record for
Domains That ***Accept No Mail***" (emphasis added). Assuming that a
domain that contains
Am Freitag, 31. Januar 2025, 01:41:58 schrieb Matt Palmer via mailop:
> The title of RFC7505 is "A "Null MX" No Service Resource Record for
> Domains That ***Accept No Mail***" (emphasis added). Assuming that a
> domain that contains a null MX record will not send mail seems doomed to
> false pos
I usually report them via Spamcop and add their IPs and/or domain names into
our local blocklist.
If this causes issues with legitimate mail from them, they can use the link
that we give in every SMTP error reply to contact us. I just don't have time to
educate mail ops who didn't request it.
C
Dnia 30.01.2025 o godz. 14:03:51 Matus UHLAR - fantomas via mailop pisze:
Nowadays, we can mark domains that don't send mail using Null MX (rfc 7505).
But this needs explicit record to say "this domain does not send/receive e-mail"
Requiring MX to explicitly state "this domain does send/receive
About 24 hours ago, I started receiving hundreds of "failure notice"
emails from an external mailer daemon.
I was concerned that this was due to some kind of compromise on my
server. It was not - nothing weird with logins or anomalous IPs or
anything that would indicate compromise on our end.
On 31.01.2025 at 14:21 Fehlauer, Norbert via mailop wrote:
> usually there's some kind of "all" mechanism (~all, -all ?all) when using a
> SPF record for a domain. Is a SPF record without an "all" mechanism valid at
> all (implicit +all) or is this an invalid record in this case?
> https://datat
12 matches
Mail list logo
