Am 18.07.2024 um 09:47:03 Uhr schrieb Scott Q. via mailop:
> This user doesn't really want to do anything I suspect. Instead
> of high quality technical/policy posts, this list is consumed with
> personal questions that provide little general value, by this one
> individual.
Although, such
Am 18.07.2024 um 20:36:09 Uhr schrieb Jeff Pang via mailop:
> Can I setup mailserver to accept messages via sdl/tls only from other
> MTA? How to disable peer MTA send me plaintext mail?
Technically, this is possible, but be aware this will break some
systems that don't support TLS or only
Am 15.07.2024 um 14:48:01 Uhr schrieb John Levine via mailop:
> Sendmail is actively maintained and works fine, but configuring it
> is hard and the documentation is a 30 year stream of consciousness.
The m4 macros are a bit tricky, but all possible after reading the
relevant parts of the
Am 15.07.2024 um 11:32:05 Uhr schrieb Anthony Howe via mailop:
> I prefer Sendmail 8.x, because that is what I started with and took
> great efforts to learn (spent money on The Bat book, was given a gold
> shirt :-D ).
I know the bat book (I found the PDF on a Russian ftp server), but
please
Am 15.07.2024 um 22:39:34 Uhr schrieb Jeff Pang via mailop:
> When I deploy a new mailserver, I consider postfix, exim and qmail.
At least when visiting the website, qmail's last release is more than
25 years ago. That is something I entirely don't recommend to use.
> From practical
Am 12.07.2024 um 12:36:10 Uhr schrieb Mark E. Jeftovic:
> On 2024-07-12 2:21 PM, Marco Moock wrote:
> > Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:
> >
> > Implement a policy that if big amounts of spam are going out you can
> > immediately block outgoing port 25.
> Is
Am 12.07.2024 um 10:57:15 Uhr schrieb Mark E Jeftovic via mailop:
> But let’s say they get a VM provisioned - now what?
Block outgoing connections to port 25 by default, tell that the
customers and only enable it for users who intentionally want it.
Implement a policy that if big amounts of spam
Am 05.07.2024 um 19:45:10 Uhr schrieb Jeff Pang via mailop:
> When an user requests to join mailing list, which address should we
> take? The envelope address, or the header From address?
Both should match in that case.
> In the mailop life, I saw many sender addresses in header are
>
Am Fri, 28 Jun 2024 02:35:16 +0100
schrieb Richard Clayton via mailop :
> this is "list bombing" and is done to simply annoy,
And also to attack other services, either by targeting the mailbox
itself (filling it to avoid receiving further mails) or their MX with
many, many messages.
Often, many
Am Thu, 27 Jun 2024 19:43:11 -0500
schrieb Grant Taylor via mailop :
> Is there any value in contacting postmaster@ / abuse@ for senders
> that participated in a mass subscription bomb attack?
Of course. They must be aware of that to implement countermeasures.
Some mailing list software has no
Am 27.06.2024 um 19:16:51 Uhr schrieb Benny Pedersen via mailop:
> Paul Smith via mailop skrev den 2024-06-27 18:17:
> >> That would be an SPF fail, but the sender
> >> domains are ~all
> >>
> >> Why the hard bounce?
> >
> > It's entirely up to the receiver what they do with a message.
> >
>
Am Thu, 27 Jun 2024 11:27:53 -0400
schrieb "Mark E. Jeftovic via mailop" :
> Been debugging an email forwarding problem, it's basically that the
> forwarder doesn't use SRS or ARC
So I assume the MAIL FROM: is u...@original.domain.example.org
> That would be an SPF fail, but the sender domains
Am 24.06.2024 um 16:06:32 Uhr schrieb Benny Pedersen via mailop:
> that sayed We can’t connect to the server at list.mailop.org.
Works for me. Please use traceroute to find out if that is a problem at
your side.
--
Gruß
Marco
___
mailop mailing list
Am 24.06.2024 um 12:03:49 Uhr schrieb Alessandro Vesely via mailop:
> IME, large sending times are often caused by IMAP. Most clients
> operate by first sending the message and then saving it in the Sent
> IMAP folder. Just changing that method to Bcc: halves the time
> required.
Why should
Am 22.06.2024 um 15:45:36 Uhr schrieb Jeff Pang:
> that's b/c the attachment can be sent as 100MB between users.
> some users said they are hard sending large mail, so I am asking the
> question.
Is that a latency or bandwidth issue?
TCP is affected by high latency and will slow down.
To make
Am Sat, 22 Jun 2024 07:01:00 +0800
schrieb Jeff Pang via mailop :
> do you know if there is a reverse proxy for submission?
> for instance, my server is in the US, while some customers are in EU,
> so I consider to deploy a reverse proxy in EU for speeding up their
> access.
Then you need a real
Am 21.06.2024 um 10:46:02 Uhr schrieb L. Mark Stone via mailop:
> It's not uncommon for us to be blocking 30K-50K IP addresses, with no
> performance issues. Reboots do take about a minute or two longer
> however; Fail2Ban rewrites the route table on service start/stop to
> populate/depopulate
Am 21.06.2024 um 16:55:53 Uhr schrieb Jeff Pang via mailop:
> Here is the drop list by iptables,
> https://cloud.hostcache.com/drop.list
>
> can you help take a look?
You can create a small script that parses the addresses to the
application rblcheck in linux. IIRC ipset also offers a way to
Am 21.06.2024 um 07:20:17 Uhr schrieb Jeff Pang via mailop:
> postfix/smtps/smtpd[451948]: warning: unknown[211.184.190.87]: SASL
> LOGIN authentication failed: UGFzc3dvcmQ6
>
> I am afraid too many iptables will slow down the performance of
> systems. do you have any suggestion for handling
Am Sat, 8 Jun 2024 10:24:41 +0800
schrieb Jeff P via mailop :
> Can cloudflare (or others) deliver messages correctly to this IPv6 MX?
If they support IPv6, this will work.
The interesting things is how is you priority set?
Is the IPv6 MX the highest?
Is it known that some MTAs have problems
Am Wed, 05 Jun 2024 10:36:58 +1000
schrieb Michelle Sullivan via mailop :
> For those that haven't heard. Proofpoint is retiring SORBS effective
> immediately(ish).
Is there a reason that this is not mentioned on the homepage?
___
mailop mailing list
Am Tue, 21 May 2024 15:25:22 -0400
schrieb "Mark E. Jeftovic via mailop" :
> we've tried it from domains with no SPF enabled (and no SRS) as well
> as domains with SPF + SRS
Do they have DMARC?
___
mailop mailing list
mailop@mailop.org
Am 20.05.2024 um 13:09:25 Uhr schrieb Brotman, Alex via mailop:
> However, keep in mind that if you're not already using those newer
> versions, you'll now revert to clear-text.
This depends on the MTA's settings.
With sendmail I experienced that the default is to try STARTTLS many
times - even
Am Fri, 17 May 2024 16:04:56 +0100 (BST)
schrieb Andrew C Aitchison via mailop :
> If the mail system uses a DKIM pass to show the *other pieces*
> of the message as trusted, then bad things can happen.
I don't know any end users system that shows those results to the user.
I only know MTA's
Am 17.05.2024 um 17:51:33 Uhr schrieb Andre van Eyssen via mailop:
> Turns out *some* mail platforms cope with having binaries just
> stuffed into the mail and some silently fail.
The postmasters who allow non-standard e-mail are the problem here. If
every MTA rejected such messages, the origin
Am 07.05.2024 um 20:58:29 Uhr schrieb Benny Pedersen via mailop:
> ah now i remember it, its just dnswiz that see that problem, as i
> remember its a route problem, but outside of dnswiz its works
Can you specify that more precisely, please?
--
Gruß
Marco
Send unsolicited bulk mail to
Am 07.05.2024 um 20:12:24 Uhr schrieb Benny Pedersen via mailop:
> eu zone: The server(s) were not responsive to queries over UDP.
> (2001:978:2:1::93:2)
>
> why is it not resolved ?
Works for me, via TCP and UDP.
Maybe was a temporary issue.
--
kind regards
Marco
Am 06.05.2024 um 15:56:31 Uhr schrieb Laura Atkins:
> 205.183.255.162
Have a look in the whois database (whois in terminal):
Comment:For abuse issues, please email ab...@aup.lumen.com
Comment:All abuse reports MUST include:
Comment:* src IP
Comment:* dest IP
Am 06.05.2024 um 12:59:46 Uhr schrieb Laura Atkins via mailop:
> Looking for an abuse contact there or at messagereach.
T-Mobile is a name used by many (sub)companies.
Can you specify the IP address?
--
kind regards
Marco
Send unsolicited bulk mail to 1714993186mu...@cartoonies.org
Am 30.04.2024 um 14:18:17 Uhr schrieb Jaroslaw Rafa via mailop:
> That's why nobody should treat UCEPROTECT seriously (also due to
> highly suspicious behavior of the people who run this blacklist -
> their de-listing practices are de facto a money extortion scheme),
They delist IP addresses 7
Am 30.04.2024 um 14:05:00 Uhr schrieb Stefan Bauer:
> Wow. Indeed. Thank you. The ip is 217.160.0.245 and yes, the complete
> ASN is blocked.
I recommend choosing another ISP that doesn't host so much spammers or
using whitelisted.org.
--
kind regards
Marco
Send unsolicited bulk mail to
Am 30.04.2024 um 12:28:50 Uhr schrieb Stefan Bauer via mailop:
> Sender-Domain IP is in UCEPROTECTL3, however none of his sending
> systems. Bad thing is, that this is one of the cluster-ips from
> IONOS/1&1, so many of our senders, having their domains hosted at
> IONOS/1&1 are currently
Am 24.04.2024 um 10:08:53 Uhr schrieb Marco Davids via mailop:
> However, the IPv6-address in the error below resolves to two names:
>
> ;; ANSWER SECTION:
> 0.0.7.0.0.0.0.0.0.0.0.0.0.0.0.0.b.1.6.2.3.0.4.f.1.1.1.0.1.0.a.2.ip6.arpa.
> 3165 IN PTR
Am 22.04.2024 um 09:28:20 Uhr schrieb Paul Menzel via mailop:
> The SPF of molgen.mpg.de has `~all` (soft fail):
>
> $ dig txt molgen.mpg.de +short
> "v=spf1 ip4:141.14.0.0/16 ~all"
>
> and I would expect `~all` to result in Google Mail not rejecting the
> message, when another
Am 19.04.2024 um 12:21:47 Uhr schrieb Sebastian Arcus via mailop:
> I would have to look further into this, but I was under the
> impression that Exim uses the VRFY command for callout verification?
Most sites have disabled that, and implementations of Exim are known
that use RCPT TO. Stop using
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> On 18/04/2024 13:44, Marco Moock via mailop wrote:
> > Am 18.04.2024 schrieb Sebastian Arcus via mailop
> > :
> >> The mention of HELO is what threw me off - and I kept on thinking
> >> that it's not possi
Am 18.04.2024 schrieb Bill Cole via mailop :
> I can't say that Spamhaus lists IPs that engage in the abusive
> practice of remote sender verification but I would be happy to hear
> that they are doing so and CSS+XBL listing is a reasonable expression
> of that sort of world-hostile behavior.
If
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> The mention of HELO is what threw me off - and I kept on thinking
> that it's not possible, as port 25 is blocked. But I completely
> missed the point that even authenticated connections on 587 will use
> HELo - I think?
They require auth, so
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> However, if keeping outbound port 587 open turns out to be causing
> real headaches, I could take a look at revising the existing approach.
If that is an issue, they should inform your ISP about the abuse and
that should forward that to you,
Am 18.04.2024 schrieb Sebastian Arcus via mailop :
> A few days ago I started having issues with the public IPv4 address
> of one network I look after ending up on the Spamhaus XBL and CSS
> blacklists.
https://www.spamhaus.org/blocklists/exploits-blocklist/
Listings there are not related to
Am Wed, 10 Apr 2024 07:14:41 -0700
schrieb Russell Clemings via mailop :
> There was an outage starting Sunday on indra.net and although they
> say it's up again now, I'm still getting no response from their
> nameservers and mail for their users (or user, as I see only one) is
> still stacking
Am 22.03.2024 um 19:07:00 Uhr schrieb Michael Irvine via mailop:
> NOTE: IPs are dedicated from SendGrid
Sendgrid is a company that at least doesn't care about abuse from their
systems.
Assume that they are listed at various dnsbl or manually blocked by
postmasters.
--
Gruß
Marco
Send
Am 16.03.2024 um 17:44:09 Uhr schrieb John Levine:
> It appears that Marco Moock via mailop said:
> >> But who will follow 13 years old standard... ;-)
> >
> >When Google and Co. make DKIM mandatory, this will be hard, because
> >those messages are likely to
Am 16.03.2024 um 20:31:33 Uhr schrieb Slavko via mailop:
> Dňa 16. marca 2024 19:19:21 UTC používateľ John Levine via mailop
> napísal:
>
> >The DKIM RFC very clearly says that an invalid DKIM signature is
> >equivalent to no signature. I suppose there may be people who wrongly
> >misinterpret
Hello!
Since enabling DKIM outgoing and verify incoming, I notice the DKIM
fails (although, I don't reject).
One of them is this mailing list.
Is there a reason for changing the content of the mail AND keeping the
original DKIM signature?
Wouldn't it be better to remove that and add mailop's
Am 14.03.2024 um 11:58:24 Uhr schrieb Slavko via mailop:
> Dňa 14. 3. o 10:21 Andrew C Aitchison via mailop napísal(a):
>
> > Given that TLS encryption in SMTP is hop-by-hop rather than
> > end-to-end, I am not convinced that this is a significant reduction
> > in security.
>
> Of course,
Am 16.03.2024 um 13:08:52 Uhr schrieb Benny Pedersen via mailop:
> Marco Moock via mailop skrev den 2024-03-16 12:46:
> > Am 14.03.2024 um 10:28:13 Uhr schrieb Julian Bradfield via mailop:
> >
> >> Their latest daftness (latest in my noticing it, anyway) is
> &g
Am 14.03.2024 um 10:28:13 Uhr schrieb Julian Bradfield via mailop:
> Their latest daftness (latest in my noticing it, anyway) is
> rate-limiting on the basis of too many recipients for a single
> message-id, where "too many" varies from 6 to 30. You'd think they'd
> never heard of organization
Am Thu, 14 Mar 2024 10:04:42 +0100
schrieb Marco Moock via mailop :
> Although, I send only a very small amount of mail to Google. Do they
> use that to calculate the rate?
I got that error again. I participated in some mailing lists with
gmail subscribers.
One of those subscribers has a f
Am 14.03.2024 um 16:15:11 Uhr schrieb ml+mailop--- via mailop:
> Looks like there is no default (maybe your OS uses some startup
> command with a "default" retry time).
That is the case.
It is a cronjob that runs every 20 minutes.
That applies to Debian and most likely to Ubuntu too.
--
kind
Am 14.03.2024 schrieb Julian Bradfield via mailop :
> On 2024-03-14, Marco Moock via mailop wrote:
> > sendmail tried to deliver it 20 times during the night - this
> > morning I deleted the mail from mqueue.
>
> That's a fairly aggressive retry strategy.
That is th
Am 14.03.2024 schrieb Julian Bradfield via mailop :
> They don't reject with 5xx because they're not rejecting that message,
> they are rate-limiting you or the network you're on.
> I get this often, because one user forwards their mail to
> gmail, including all the spam. Google rejects the spam,
Am 14.03.2024 schrieb Stefano Bagnara via mailop :
> On Thu, 14 Mar 2024 at 10:09, Marco Moock via mailop
> wrote:
> > Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
> > to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp,
> > pri=5370980, relay=alt4.gmail-sm
Hello!
Yesterday I replied somebody directly on debian-users (he uses a crappy
mailer and sends to the author and the mailing list...).
Gmail doesn't like this mail, but rejects it with a tempfail. I've now
deleted it from mqueue.
Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
to=,
Am 14.03.2024 schrieb Cyril - ImprovMX via mailop :
> But in my opinion, moving the needle upward by not accepting
> deprecated versions would force those users to be compliant and
> improve the general security.
Most of them will simply fall back to no encryption. That is the
default setting
Am 13.03.2024 um 17:06:03 Uhr schrieb Johann Klasek via mailop:
> Is it not condescending to question to reason why someone has not
> already the opportunity to switch to TLS 1.2?
Can you name some reasons?
I currently don't know one.
--
Gruß
Marco
Send spam to 1710345963mu...@cartoonies.org
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
> Without one, disabling them is a cargo-cult praxis that is worse than
> any false sense of security provided to oblivious peers who can't do
> TLSv1.2 or better.
What are legitimate reasons today not to use TLS 1.2 or 1.3?
--
Gruß
Am 13.03.2024 um 10:43:27 Uhr schrieb Bill Cole via mailop:
> Without one, disabling them is a cargo-cult praxis that is worse than
> any false sense of security provided to oblivious peers who can't do
> TLSv1.2 or better.
What are legitimate reasons today not to use TLS 1.2 or 1.3?
--
Gruß
Am 13.03.2024 um 08:39:33 Uhr schrieb Michael Orlitzky via mailop:
> Whose sense of security is improved by sending those messages in
> plaintext?
None. If you want to transfer something making eavesdropping possible,
encrypt the content end to end. Everything else must be considered as
Am 13.03.2024 um 11:28:18 Uhr schrieb L. Mark Stone via mailop:
> FWIW, our view is that poor encryption can be worse than no
> encryption, as it can give the participants a false sense of
> security. This seems like a good move to us.
>
> We have configured Postfix in our Zimbra MTA servers to
Am 13.03.2024 um 12:04:22 Uhr schrieb Matus UHLAR - fantomas via mailop:
> Iirc sendmail honored these settings, postfix hasn't.
8.18.1/8.18.1 2024/01/31
OpenSSL version 3.0.x is supported. Note: OpenSSL 3 loads by
default an openssl.cnf file from a location specified
Am 13.03.2024 um 08:39:17 Uhr schrieb Tobias Fiebig:
> Which is part of the reason for this mail; Are there any best
> practices beyond what i did above for preventing this form of abuse
> (apart from 'wanna do "Captcha & Cloudflare" tonight' ?
Create a random generated mail address that the
Am 12.03.2024 um 19:19:50 Uhr schrieb Tobias Fiebig via mailop:
> over the past 2-3 weeks, I saw a slightly more filled queue for email-
> security-scans.org; A lot of users seemed to start tests, but never
> received the corresponding test mails; In most cases, the ESP hat
> shutdown delivery to
Hello!
We had the situation that we got mail that wasn't RFC-compliant and our
listserv rejected it.
MAIL From:
Listserv replies to the From: header and not to the Return-Path.
It doesn't see MAIL FROM because the mail is being piped to the
application, but it could use Return-Path.
MAIL FROM:
Am 08.03.2024 schrieb Paul Gregg via mailop :
> They do claim to use RBLs, but my OVH IP isn't on any RBLs (not even
> uceprotect-L3 amazingly right now) - and based on my home 'DUL' IP not
> being able to connect, they're certainly using RBLs on port 25.
Can you test 53/udp and 53/tcp on their
Am 08.03.2024 schrieb Stefano Bagnara via mailop :
> I can't even lookup the domain as I cannot reach their NS, but the
> same happens even if I try to ping their email server IP address:
I can reach them properly from AS8820.
Do you get any ICMP messages back?
tcptraceroute 194.97.8.138 53
Am 04.03.2024 um 02:25:08 Uhr schrieb Gareth Evans via mailop:
> From
>
> https://www.mailop.org/best-practices
>
> "Having SPF for your own domains is usually considered a weak signal
> ..."
>
> Eh?
That sounds completely wrong. SPF makes forging the MAIL FROM: address
much harder. Some
Am Sun, 03 Mar 2024 17:23:22 +
schrieb Gareth Evans via mailop :
> I am curious about the exact mechanism of PTR checks, and couldn't
> find it in RFC5321 so presume it's not actually part of SMTP.
Most server require that the PTR points to a domain name like
mail.example.org and that has
Am Tue, 27 Feb 2024 16:54:31 -0600
schrieb Jarland Donnell via mailop :
> Is it plausible that Google had a temporary issue reaching your DNS
> servers?
If so they should give an error message that says that.
___
mailop mailing list
mailop@mailop.org
Am Fri, 23 Feb 2024 13:39:46 -0800
schrieb Mark Fletcher via mailop :
> My question to you all is, do you think that the
> List-Unsubscribe=One-Click header is supported well enough these days
> such that I can replace the one-click unsub link in the message
> bodies with a link that requires
Am Fri, 16 Feb 2024 14:49:12 -0600
schrieb Jesse Hathaway via mailop :
> Does probing for recipients work these days, is it considered abusive?
Use the VRFY SMTP command for that. If the remote site doesn't provide
it, they don't want that somebody probes for the mailboxes.
Some dnsbl (e.g.
Am 12.02.2024 um 15:35:30 Uhr schrieb Sebastian Nielsen:
> >>If you forward spam (automatic forwarding), you will be listed as
> >>the spammer because even DKIM is valid.
> That’s why you do spam filtering in the forwarding server.
There is no 100% solution for that and even a small amount of
Am 09.02.2024 um 13:59:57 Uhr schrieb Andy Smith via mailop:
> When these people are your paying customers, or you are being paid
> to get email to these people, there is limited up side in berating
> people about their choice of mail service. A fact which of course is
> used and abused by the
Am 09.02.2024 um 22:06:05 Uhr schrieb Sebastian Nielsen via mailop:
> Or people could stop forwarding emails in idiotic ways, because when
> you forward an email, you are actually forging the original sender.
>
>
> Ergo, if you forward a email from genuineu...@genuineserver.com to
>
Am 10.02.2024 um 15:52:22 Uhr schrieb Andre van Eyssen:
> On Fri, 9 Feb 2024, Marco Moock via mailop wrote:
>
> > Outlook supports that and knowing about it is a question of
> > training.
>
> I'd like to suggest that understanding of email is declining in the
> ge
Am Fri, 09 Feb 2024 22:09:45 -0800
schrieb Hal Murray via mailop :
> I expect that there would be a protocol to handle it. I can't be the
> only one who has thought of this. After a handshke to set things up,
> the sender adds a forwarding header and the receiver verifies that a
> forwarded
Am 09.02.2024 um 18:06:41 Uhr schrieb Slavko via mailop:
> Hmm, and are you sure that regular users know what S/MIME is and
> are able to reliable distinguish email with and without it? I don't
> think so...
Outlook supports that and knowing about it is a question of training.
At our university,
Am 09.02.2024 um 08:50:52 Uhr schrieb Scott Mutter via mailop:
> This is part of the issue I have with all of these band-aid solutions
> when it comes to "fixing" the spam problem with email. You're going
> to continue to have these issues with email until people realize that
> they are going to
Am 09.02.2024 schrieb Jaroslaw Rafa via mailop :
> Dnia 9.02.2024 o godz. 07:13:31 Marco Moock via mailop pisze:
> > S/MIME exists and I really don't understand why banks and online
> > shops don't consequently use it.
>
> I must say that my bank is and always was using
Am 09.02.2024 schrieb Julian Bradfield via mailop :
> On 2024-02-09, Marco Moock via mailop wrote:
> > I don't know if any MTA out there supports [DKIM] directly or
> > supports Milter.
>
> Exim supports it, even in the rather old version in Debian 10 that I
> use.
Am 09.02.2024 schrieb Matus UHLAR - fantomas via mailop
:
> It was noted that not using DKIM can be used for preventing of
> forwarding because of legal requirements.
A rather bad solution for that because it depends on the checks of the
receiver of the forwarded message.
Am Fri, 09 Feb 2024 13:17:48 +1100 (AEDT)
schrieb Andre van Eyssen via mailop :
> The bulk of problematic email now -- I see phishing as the concern
> rather than spam that gets easily tagged -- comes with valid SPF and
> is signed with DKIM.
S/MIME exists and I really don't understand why banks
Am Thu, 8 Feb 2024 10:46:51 -0800
schrieb Michael Peddemors via mailop :
> The only way this will stop, is when the network operators are forced
> to be accountable for outbound traffic
dnsbl exists and some lists (e.g. uceprotect L3) entirely list ISPs
that have a huge amount of spammers in
Am Thu, 08 Feb 2024 10:20:50 -0800
schrieb "Randolf Richardson, Postmaster via mailop" :
> > Am 08.02.2024 schrieb Cyril - ImprovMX via mailop
> > :
> > > But forwarding an email from a domain that have DMARC enabled
> > > (with a policy different than "none") could still work if the
> > >
Am Thu, 8 Feb 2024 17:10:57 +
schrieb Andy Smith via mailop :
> Last month there was a complaint on the NANOG (North American
> Network Operator's Group) that changing the subject line of an email
> mid-thread disrupted the way emails are grouped, the implication
> being that the way gmail
Am Thu, 8 Feb 2024 16:33:58 -0500
schrieb Stephen Frost via mailop :
> Agreed- this is an issue and we've seen it too. I've ended up having
> to suggest to some that they remove their SPF DNS entries as that
> actually ends up helping with deliverability, which seems odd but is,
> in fact, true.
Am 8 Feb 2024 21:06:27 -
schrieb John Levine via mailop :
> It is not hard to deliver the mail locally and tell Gmail to poll that
> mailbox and show it with your Gmail, optionally with a tag. You can
> also arrange to send mail from Gmail with your other address and Gmail
> will submit it
Am 08.02.2024 schrieb Jaroslaw Rafa via mailop :
> Dnia 7.02.2024 o godz. 20:51:15 Jarland Donnell via mailop pisze:
> > Nearly 100% of
> > users who forward email do so because they want it in Gmail.
>
> I am always wondering - as Gmail gives so many problems that have been
> discussed
Am 08.02.2024 schrieb Cyril - ImprovMX via mailop :
> But forwarding an email from a domain that have DMARC enabled (with a
> policy different than "none") could still work if the sender signed
> their email with DKIM. Isn't it correct?
That is true. But not all domains have DKIM.
> In order
Am Wed, 07 Feb 2024 20:51:15 -0600
schrieb Jarland Donnell via mailop :
> Is it time to throw in the towel on email forwarding?
I think so.
Every mechanism has its own disadvantages.
> Nearly 100% of users who forward email do so because they want it in
> Gmail.
Which type of users?
Due to
Am 06.02.2024 um 23:50:14 Uhr schrieb Odhiambo Washington via mailop:
> Today morning I woke up to all emails being rejected as I was using
> zen.spamhaus.org in my dnslists.
> Almost all incoming emails - even from gmail.com - were being
> rejected. Did I maybe miss something?
Most likely your
Am 29.01.2024 um 14:05:30 Uhr schrieb Michael Peddemors via mailop:
> And of course, this 'could' be caused by backscatter on their
> servers, if the emails originated from your server ;)
>
> Ensure your domains have SPF records of course, but we need more
> information on the list to determine
Am 27.01.2024 um 13:46:34 Uhr schrieb Gellner, Oliver via mailop:
> If I as a customer or business partner would receive emails which are
> coming from apa...@webserver1.company.tld then I‘d be under the
> impression that this company lost control of their infrastructure.
> But maybe that’s just
Randolf Richardson, Postmaster via mailop schrieb:
Have you inspected the SMTP headers and grepped mail server logs?
Of course.
It comes from the ebay servers and the RCPT TO is root@our.domain.
___
mailop mailing list
mailop@mailop.org
Hello!
Does anybody of ebay reads here?
At work we receive mails from ebay (SPF valid) to an address that isn't
assigned to an account and can't be registered by the ebay user because
he can't access the inbox, it is root@our.domain.
I already called their customer service and they said the
Hello!
At work we are currently deploying DKIM.
Do people here have experience with messages from sub.example.org
signed with d=example.org?
That way is much easier to handle for us because we have a lot of
domains (machines sending with r...@hostname.example.org etc.).
Will Google accept such
Am 24.01.2024 um 21:48:39 Uhr schrieb Grant Taylor via mailop:
> I knew that Google was going to start requiring SPF or DKIM (in
> addition to other sender guidelines [1]. But I thought they were
> starting February 1st, per their own sender guidelines.
IIRC Google starts to require DKIM for
Am 17.01.2024 um 01:47:20 Uhr schrieb Jarland Donnell via mailop:
> 450 Error connecting to 17.57.156.30. Unexpected socket close
m@ryz:~$ telnet 17.57.156.30 25
Trying 17.57.156.30...
Connected to 17.57.156.30.
Escape character is '^]'.
Connection closed by foreign host.
m@ryz:~$
Same here.
Am 09.01.2024 um 12:02:52 Uhr schrieb Paul Menzel via mailop:
> Since a while we noticed unsolicited messages from cloudfilter.net.
Did you contact their abuse desk?
Proofpoint is maybe just selling those servers to customers (that may
have hacked accounts/systems) and doesn't know about the
Am 02.01.2024 um 06:34:27 Uhr schrieb Michael via mailop:
> blocking AUTH from cloud providers that don't quickly respond to
> abuse complaints, is the way to go
Blocking SMTP generally from such providers is considerable if they let
abusers continue to abuse their services. :-)
1 - 100 of 122 matches
Mail list logo