Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI
The mailauth command can detect these signatures https://github.com/postalsys/mailauth/blob/master/cli.md For example $ mailauth report path-to-email.eml "canonBodyLength": 87122, "canonBodyLengthTotal": 87563, "canonBodyLengthLimited": true, "canonBodyLengthLimit": 87122, "mimeStructureStart": 87076, This signature uses the l-tag (canonBodyLengthLimited is true). 87122 bytes of canonicalized body were used for the signature hash (canonBodyLength), while the actual canonicalized body length was 87563 bytes (canonBodyLengthTotal) and the first byte of the actual mime tree (the first byte of the first boundary in the canonicalized body) was at 87076 bytes (mimeStructureStart) which means that only 46 bytes of the mime structure were covered by the signature and 441 bytes were not signed at all. So, this message content is most likely forged, and the BIMI logo should not be displayed even though the signature is "valid". Best regards, Andris Reinman Kontakt Gellner, Oliver via mailop () kirjutas kuupäeval R, 17. mai 2024 kell 21:42: > > > On 17.05.2024 at 16:24 Taavi Eomäe via mailop wrote: > > > > Although some of these dangers have been known for a while (some parts > are even described in the RFC itself), things like the threat landscape, > our approach and the extent to which this can be abused have changed. In > our opinion previously suggested and (rarely) implemented mitigations do > not reduce these risks sufficiently. > > > > We hope that with some cooperation from mail operators improved defense > measures can be implemented to strengthen DKIM for everyone. > > > > > > A longer description with images is available here: > https://www.zone.eu/blog/2024/05/17/bimi-and-dmarc-cant-save-you/ > > While it’s not new information that the length attribute of DKIM poses a > security risk, it’s still worthwhile to draw attention to it every once in > a while and the usual suspects who keep on using it. > > What would be interesting is a list of software that is able to ignore > DKIM signatures which contain a length attribute and how to configure this > behavior. > > — > 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<mailto:dmt...@dm.de> * www.dmTECH.de<http://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< > https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832 > >. > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] verifier.port25.com
Sorry for the shameless plug, but my product, EmailEngine.app has this built-in and also supports running these tests automatically with an API call. See here for a fast demo (I use EmailEngine to send out an email from an SMTP account and get SPF, DKIM and DMARC info in return): https://www.youtube.com/watch?v=OWeZn6asVH8 Best regards, Andris Reinman Kontakt Blake Hudson via mailop () kirjutas kuupäeval T, 23. mai 2023 kell 21:39: > Looks like the email verification application at verifier.port25.com > described in this > ( > https://postmarkapp.com/blog/port25s-authentication-and-spam-assassin-tool) > > article may have been shut down. > > Anyone have any insight into this or alternative tools for testing DKIM, > SPF, and similar in one go? > > --Blake > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM signing with ed25519 keys - leap of faith
mailauth tool (shameless plug, built by myself) is also able to both sign and verify ed25519 dkim keys. https://github.com/postalsys/mailauth/blob/master/cli.md Best regards, Andris Reinman Kontakt Slavko via mailop () kirjutas kuupäeval T, 12. oktoober 2021 kell 13:40: > Dňa 12. 10. o 11:02 Sidsel Jensen via mailop napísal(a): > > My question to you: What are your thoughts on starting to sign with > ed25519 keys and what is currently holdning you back? > > I am using dual sign with ed25519 keys for some months already (i do not > remember exactly without checking config, sorry), because i think, that > it is way to go in future. Recently i enabled DMARC rua eports to see > results, but i am not sending a lot of emails. > > Most of reports simple miss ed25519 DKIM in its reports, thus i guess, > that they applied to ignore unknown signature algo. The only reports > with included ed25519 is from google, but it always failed, eg.: > > > > slavino.sk > pass > r2021 > > > slavino.sk > fail > e2021 > > > slavino.sk > pass > > > > Or failed without mention selector: > > > > slavino.sk > pass > r2021 > > > slavino.sk > fail > > > > slavino.sk > pass > > > > Both examples are from my IP and i am not sure how to interpret them. > > > One thing I did find was that a number of the DKIM checker tools does > not yet support the new keys. I’ve reached out to EasyDMARC and I know > their developers are currently looking at it, but I could use the help of > the mail community to reach out to some of the other DKIM checker tools to > get them up to date as well, if you have any contacts there. > > The rspamd is able to verify/sign ed25519 keys, thus if you can send > email to site which is using it and will add results headers, you can > verify it. > > The biggest troubles with ed25519 key is lack of tools to generate > ed25519 keys tends to use different formats for private keys, thus they > cannot be used universally (generate in one and use in another). > > Recently i did own tool to generate (both RSA & ED) keys in form for > exim MTA and for DNS, but it not finished yet... > > Slavko > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] open source mtas?
Thanks for the mention! I'm the main developer of ZoneMTA and I originally built it to replace a specific Postfix instance where we needed more flexible/dynamic routing options than Postfix was able to provide. Best regards, Andris Reinman > On 30. Jul 2021, at 19:44, Jarland Donnell via mailop > wrote: > > https://github.com/zone-eu/zone-mta <https://github.com/zone-eu/zone-mta> > > This project is amazing, and it's everything you'd want it to be. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Haraka status? Exim the only choice? (v Postfix)
Hi, In the WildDuck email server (https://wildduck.email/ <https://wildduck.email/>) Haraka handles the MX part. I would say that Haraka is not exactly a server software but a framework. For example in the WildDuck setup it does not handle any queueing. Instead Haraka performs all of it's checks (eg gets spam score from Rspamd, verifies DKIM/SPF/DMARC etc) and then hands the message over to the WildDuck plugin that parses the message and stores it directly into database (WildDuck uses sharded MongoDB as the mail store). In our setup it processes about 1M incoming emails per day, peaks around 100k emails per hour, without any problems. I have not used Haraka for outbound emails though. Mostly because the queueing mechanism that Haraka has does not play well with how WildDuck manages emails. Best regards, Andris Reinman > On 1. May 2021, at 06:18, MRob via mailop wrote: > > Hi -- > I used Postfix along time but my experience is that it is incredible > difficult to implement custom logic especially across the different > binaries/processes it uses to fulfil a mail delivery transaction. Its > designed in the "unix philosophy" and has good performance - great but > Postfix devs normally react hostile if asked for advanced features that > require tracking meta-information about messages across Postfix processes. > Its only the RFC compliant mail message state that persisting through the > entire transaction, nothing more. Milters can be injected but have > limitations and I get headaches from the configuration system. I shouldn't > complain too hard tho, because I'm grateful for how solid and secure and > bulletproof it has been. Thank you team Postfix. > > But I want more power and customization not only generic mailserver. > > I heard of Haraka a time ago and I see it is still maintained, but there > seems no public archive of mailing list (website for years now has said "We > are working on providing list archives") and when I last tried to subscribe, > list was broken!!! I asked on irc and they said approx "oh it's broken? meh, > thats not so important, cuz Haraka just works, if it doesn't just ask on irc. > we update Haraka once in a while when we find something wrong". Obviously > this was a red flag. > > Anyone using Haraka? Anyone trust Haraka? > > That mean Exim is the only real choice? It was a good laughing from this > recent mailop post about Exim vulnerability and I see Exim gets regular > vulnerabilities. > https://www.mail-archive.com/mailop@mailop.org/msg12993.html > > But it look like Exim have infinite customization possibility which should > help me. I guessing that one must accept more vulnerabilities for having more > power flexibility that Exim gives. > > Can I ask what are mailop's opinions about Exim? Thanks you! > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] DKIM: ed22519 experiences anyone?
mailauth (https://github.com/andris9/mailauth) library and cli utility can also be used to both verify and sign using Ed25519 DKIM keys. Can't see those keys to become mainstream any time soon though. RSA signature already verifies the message so double signing is basically just for testing purposes but has no practical effect. Probably happens once 2048bit keys are considered too weak and 4096bit keys are just too long for DNS. Regards, Andris Reinman Kontakt Patrick Ben Koetter via mailop () kirjutas kuupäeval T, 16. veebruar 2021 kell 09:50: > Hey Vsevolod! > > * Vsevolod Stakhov via mailop : > > On 15/02/2021 21:02, John Levine via mailop wrote: > > > In article <20210215085929.76srgtpbaqbms...@sys4.de> you write: > > >> Greetings, > > >> > > >> is anyone using ed22519 for DKIM signatures yet and what do you see? > Any > > >> interop problems? > > > > > > Aside from the fact that approximately nobody can validate them yet, > they're fine. > > > > > > So long as you don't try to use the same selector you use with RSA > signatures > > > they shouldn't cause any problems. > > ACK! After some consideration we agreed not to use subdomains of > _domainkey.$DOMAIN.$TLD, but add the algo name as suffix to the selector. > > > > Well, Rspamd can validate them, but I'd suggest to use dual signatures > > for now (RSA + ed25519) when signing - it is also supported by Rspamd > > dkim_signing module, even for the keys rotation scenario. > > I agree! Another standard withou a mechanism to tell feature sets apart. > We'll > have to live with two signatures for an undefined period, until someone > steps > up and forces senders to implement the "replacing feature", because the old > one will fall away on the receiving end. > > p@rick > > -- > [*] sys4 AG > > https://sys4.de, +49 (89) 30 90 46 64 > Schleißheimer Straße 26/MG,80333 München > > Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 > Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief > Aufsichtsratsvorsitzender: Florian Kirstein > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Test software for ARC?
You can validate DKIM and ARC of an email message with mailauth https://github.com/andris9/mailauth#command-line-usage (developed by myself) Regards, Andris Reinman > On 1. Dec 2020, at 18:55, Eric Tykwinski via mailop wrote: > > > I’m trying to troubleshoot a DKIM issue which is also ARC signed, so I’m not > positive if alignment is an issue or not. > > Basically, routing is a mess. > Office365 -> Office365 -> Office365 -> Barracuda filter -> Onsite Exchange -> > Our server. > > Hoping there is a program to throw in raw emails and let me know, but I > didn’t really see anything. > > Sincerely, > > Eric Tykwinski > TrueNet, Inc. > P: 610-429-8300 > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Anyone from mixmax.com on here?
Do you have a sample? I’m not from Mixmax but I think they are using an email library built by me (Nodemailer) so I would be able to fix it if it really misbehaves. Regards, Andris Reinman > On 30. Sep 2020, at 20:33, Mark Fletcher via mailop wrote: > > > Hello, > > Long shot, but is anyone from mixmax.com on here? It appears they are > generating emails with incorrectly escaped Content-Type headers for > attachments with quotes in their file names, which is causing us to reject > their (otherwise valid) messages. > > Thanks, > Mark > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] These guys are doing it right!
I guess it all comes down to cost. Easier and probably cheaper to find developers building what basically is a web client or React native or such than to hire "actual" mobile developers. So instead of making mobile mail apps more efficient and faster they can skip all that and concentrate on UX/UI features and also things that are much harder in a traditional setup like snoozing emails - no use of snoozing an email in one client if it does not reappear in your other client. And it pays off - Accompli (now mobile Outlook) was sold to MS, Mailbox was sold to Dropbox, etc. These apps were not bough because they had efficient IMAP handling built in but because of the features. Regards, Andris On Wed, Mar 11, 2020 at 2:55 PM Jaroslaw Rafa via mailop wrote: > Dnia 10.03.2020 o godz. 13:47:44 Andris Reinman via mailop pisze: > > This behaviour is pretty common, not just Mail.ru – instead of building > > actual IMAP and MIME capability into a phone app, client developers push > > all IMAP connection handling and MIME processing to their servers and > > expose HTTP based API to the mobile client. > > It's strange how in the old days of "dumb" mobile phones, email > applications > (Java midlets) runing on those phones used actual POP/IMAP and nobody ever > thought about setting up an intermediate server converting this to HTTP > requests, and now programmers who have much more computing power and much > better programming tools at their disposal (compare any smartphone to eg. > Siemens C60 - which I used for many years - in terms of available > resources) > are using such lame solution. Strange, indeed... > -- > 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] These guys are doing it right!
This behaviour is pretty common, not just Mail.ru – instead of building actual IMAP and MIME capability into a phone app, client developers push all IMAP connection handling and MIME processing to their servers and expose HTTP based API to the mobile client. This way the app developers can build UI/UX stuff and ignore email protocol complexity, it also allows to use native push channels more easily. Downside obviously is that all email is going through a 3rd party provider but considering how widely this technique is used, not many seem care about it. Best regards, Andris > On 10. Mar 2020, at 13:26, Frido Otten via mailop wrote: > > What about mail.ru with their mobile apps? I see a relative high number > of IMAP connections coming from mail.ru IP addresses. These are mainly > clients who have the mail.ru app installed on their mobile phone or > tablet, not realising that it's actually transferring email to their > phones via Russian servers, giving them the ability to store and read > your mail. So maybe some things are done right, but others aren't. > > Regards, > Frido > > Op 06-03-2020 om 16:34 schreef Jaroslaw Rafa via mailop: >> Hello all, >> once in a while a topic of e-mails from small senders being mis-classified >> as spam returns on this list. Some time ago I was complaining (and not only >> me, there were more people who experienced the same thing) about Google >> putting my messages into users' Spam folder without me or them knowing it >> (them, because they usually don't look into their Spam folder unless told >> to). >> >> Today I want to show you a good example how these issues can be handled. I >> tried to send a message to a user on Mail.ru service and I got a 550 >> rejection telling me that my message was detected as spam. But not only >> that! >> >> That's what the rejection message said: >> >> 550 spam message rejected. Please visit >> http://help.mail.ru/notspam-support/id?c=XXX >>or report details to ab...@corp.mail.ru. Error code: >>Y . ID: Z >> >> As you can see, for every message rejected as spam, their system prepares >> special codes for the sender, which you can use to easily submit a >> complaint. If you go to their help page without specifying a parameter (here >> it is: https://help.mail.ru/notspam-support/errors , click on "550 spam >> message discarded/rejected") you'll see that they even have a small graphics >> there showing you exactly where you should look for these codes in the >> rejection message you got. (You have to know a bit Russian however :)). >> >> From what is written in the form I understand that the messages rejected as >> spam are actually quarantined somewhere on their system (it's possible as >> they are rejected after the DATA phase) and they look at these messages once >> you submit the form. >> >> I submitted the form, got the ticket confirmation. It took them two days to >> resolve it, so I'm not fully satisfied with reaction time, but they finally >> fixed it. Not for the first time however :). When I got first message from >> them that the issue has been fixed, I tried to send mail again and still got >> a 550. But after I replied to their message that it still doesn't work, they >> fixed it in minutes! >> >> I'm absolutely positively impressed that such a big mail service (I think >> that Mail.ru may be comparable to Yahoo in size, although probably not >> comparable to Google) can have so user-friendly and actually working >> policy towards false positive spam classifications. You know that your >> message has been mis-classified as spam; you know exactly what to do to >> have the situation fixed; and what's most important, it actually works! >> These Russian guys are definitely doing the good job. Keep it that way! > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] G-Suite removing LSA functionality
It is not that you could just somehow easily add OAuth support to things. To get valid client ids for the OAuth to work you have to go through excessive verification process first as IMAP scope is something that Gmail considers restricted. Regards, Andris > On 17. Dec 2019, at 11:40, Philip Paeps via mailop wrote: > > On 2019-12-17 03:20:04 (+0800), Al Iverson via mailop wrote: >> Google is announcing that in the future, G-Suite accounts will not support >> LSA (Less Secure Access) account connection functionality. This will put an >> end to accessing your Gmail account via POP3 or old school IMAP, unless your >> email client supports OAuth. > > So someone will have to implement OATH support in fetchmail or I will lose > access to customer email addresses on G-Suite. > > (Sure, I could fetch the email using Mailmate but 1. I don't want Google to > follow my laptop around the world - that's creepy - and 2. I have my > mailserver fetch my mail so it's more easily backed up.) > >> 2. February 15, 2021 - Access to LSAs will be turned off for all G Suite >> accounts. > > Clear deadline at least. > >> This isn't a bad thing, of course. > > I'm not sure I share that particular view... > > Philip > > -- > Philip Paeps > Senior Reality Engineer > Alternative Enterprises > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Can someone write me a prescription for a sane MTA? I'm allergic to Postfix.
When I evaluated available email software for a medium size installation a
few years ago I did not find anything that would cater all our needs, so I
wrote my own stack (MTA + MX + IMAP/POP3). Currently it runs in high
availability (any server can go down any time without affecting access to
stored mail) cluster of 20 servers (most being used in a sharded and
replicated db cluster). There are not so many users, slightly over 10k and
5+TB of emails, so there's a lot more room to grow. Even though the current
setup is much larger then it all started from not finding a suitable MTA
and once I'd built my own it kind ow grew from that.
The problems I had were mostly related to IP blocking. If you have lots of
users then some of the accounts get taken over from time to time and start
blasting out spam. Once you detect and block these users you already might
be listed in some DNSBL. You can ask for a delisting but it is going to
take some time and during that window your mail might not be accepted. So
the MTA we built uses similar IP rotation techniques, like for example,
PowerMTA. You assign a list of IPs to a server, set weights for each IP and
set up zones for different rules. When it is detected that an IP starts
getting DNSBL error responses from MXs, then this IP is temporarily removed
from the IP pool and a flag is raised for admins who can then start
evaluating the situation. As everything is automatic and you still have IPs
left that are not blacklisted (yet), then there is time for the admins to
react. Ie. if an IP gets listed in the middle of the night, then the admins
to not have to get up (assuming though that the account responsible was
also suspended on our side, otherwise your other IPs end up in lists as
well).
Anyway, the MTA is open source and available here:
https://github.com/zone-eu/zone-mta
And the rest of the mail stack here: https://github.com/nodemailer/wildduck
Regards,
Andris
On Mon, Dec 9, 2019 at 3:24 PM Jaroslaw Rafa via mailop
wrote:
> Dnia 9.12.2019 o godz. 12:29:56 Steven Champeon via mailop pisze:
> >
> > I'm still running most of the 14K lines of custom m4 sendmail rulesets I
> > wrote back before I knew any better, mostly to deal with specific
> > ratware signatures.
> [...]
> > # f.last_
> > # e.g. "First M. Last"
> > # e.g. "First Last"
> > KEL_FirstMLastZZ05 regex -f -a_SPAMSIGN_ "[A-Z]([a-z]+)\ [A-Z]*\.*\
> *[A-Z]([a-z
> > \-]+[A-Z]*[a-z]*)"\ <[a-z].[a-z]\2_[a-z]{2}@
>
> Well... I'd rather do such things in procmail (and in fact I did and still
> do - while today I'm using SpamAssassin, a custom procmail rule set is
> called afterwards, which does the final decision - it's probably as old as
> your sendmail rules).
>
> I did it in procmail just because it was the first tool I learned to use
> for
> mail filtering, and because (after many modifications of course) it still
> works, I keep it :)
>
> Now my procmail runs at mail delivery stage, but while I was still using
> sendmail, I was using this procmail rule set as a filter "inside" sendmail
> (setup similar to after-queue filtering in Postfix, ie. message is
> delivered
> to procmail filter and if it passes through, /usr/sbin/sendmail is called
> to
> re-inject it into the queue - although sendmail does not support this setup
> directly as Postfix does, and it requires some rule tweaking to avoid
> getting stuck in the loop with procmail being called over and over again
> ;))
>
> But the point is, there are probably quite a lot of us who still run old
> custom made hacks in their mail systems :)
> --
> 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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] G-suite postmaster group
Yes, I’ve had the same thing. When trying to create a group for postmaster or abuse the form just gives you an error and does not let you continue. See screenshot here: https://cloudup.com/cWuhIKe_2QE <https://cloudup.com/cWuhIKe_2QE> Using any other name makes the error message to disappear and “next” button active. I’m pretty sure this used to work a while ago. Best regards, Andris Reinman > On 21 Mar 2019, at 23:09, Thiago Rodrigo F. Rodrigues via mailop > wrote: > > Hello folks, > > Anyone having problems to create the abuse and postmaster group at the Admin > Console ? > > We already habe been contacted by two clients that could not create a group > named psotmaster to receive the Yahoo CBL confirmation code. > > Would be nice hear if anyone saw the same behavior. > > Regards. > > -- > > > Thiago Rodrigues > Coordenador de Qualidade > Telefone: 11 3544-0513 - 11 3544-0562 > E-mail: trodrig...@allin.com.br <mailto:trodrig...@allin.com.br> > Skype: thiago.rfr > www.AlliN.com.br <http://www.allin.com.br/> > > <http://br.linkedin.com/in/trfrodrigues/> > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop signature.asc Description: Message signed with OpenPGP ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Rambler.ru 20 seconds connection delay
Hi, On our case I think we have always had a 20 sec delay between *every* SMTP command when sending to Rambler, so every message takes at least 60 seconds to deliver. Haven't been a problem, even though messages to Rambler might pile up temporarily if there's lot of trafic to this destination. Not enough traffic that anyone would complain, enough for us to notice. Regards, Andris Reinman Zone Media LLC https://www.zone.ee/en/ 2018-04-09 10:50 GMT+03:00 Dan Malm <d...@one.com>: > On 04/09/2018 04:23 AM, John Levine wrote: > > Simple theory: there are similar delays after EHLO and MAIL FROM, so > > they seem to be severly overloaded. Don't take it personally. That's > > why your mail server can do a zillion connections at once. > > As I saw a bunch of joomla sites with unprotected (or poorly protected) > account registration pages being abused to try and bomb rambler.ru > addresses this morning this theory sounds valid... > > -- > BR/Mvh. Dan Malm, Systems Engineer, One.com > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Mail Transfer Agent Alternatives
Hi, As the thread covers some open source MTAs then I'd like to mention our MTA as well – ZoneMTA https://github.com/zone-eu/zone-mta ZoneMTA can be deployed in a clustered setup (queue is stored in replicated MongoDB), it is able to handle blacklisting (if blacklisting is detected, then the current IP is disabled for that host for some period and other IPs are used), and has been running on production for over a year for us delivering ~100 msg/sec (single server) on peak times of the day. It also has built-in support for Prometheus monitoring https://github.com/zone-eu/zone-mta#metrics-for-prometheus Regards, Andris Reinman ZoneMTA 2018-02-05 20:03 GMT+02:00 Steve Atkins <st...@blighty.com>: > > > On Feb 5, 2018, at 9:27 AM, Marc Goldman via mailop <mailop@mailop.org> > wrote: > > > > > > I agree with sticking to facts so lets cover a few here: > > > > 1. PMTA (formerly Port25 now Message Systems) is the 800 lb gorilla in > the MTA world. > > > > 2. I own 2 enterprise licenses for PMTA 4.0 and paid support for a > number of years (up to r11). I found the support to be very helpful at > first but over the years it produced diminishing returns and more and more > I felt deferred to the forum and to our own engineers to sort out issues > and uncover abilities so I stopped paying for support and subsequently was > unable to receive new releases including the major one to 4.5 > > > > 3. Recently (about a year after Message Systems purchased) I reached out > to the team to find out how I can begin paying for software updates again > so I could upgrade to 4.5. > > > > I received an email telling me I would need to pay RETROACTIVELY for the > years I did NOT receive support in order to upgrade. > > > > Has anyone ever heard of a policy like that? > > Yes, it's pretty much normal. It dissuades people from only paying for > support every few years when they need support or want an updated version, > while not paying the ongoing fees that pay for development of that updated > version. > > > > > Regardless, it made me not the slightest bit interested in continuing > with PMTA again. > > > > We also have multiple Green Arrow installs. It is a great MTA and the > support is excellent and I find their pricing model is really quite fair. > > > > With that said, it isn’t perfect. They control the Postgres DB and only > grant read access. Their API however is robust and allows you to do pretty > much whatever you need. > > > > We have used a few open source MTAs over the years including Qmail, > Postfix, Haraka and recently dabbling in Postal. > > > > We have considered building our own MTA but the costs and time involved > make it somewhat prohibitive. > > > > However, I can definitely say that having ones own MTA solves all the > issues mentioned herein and until one makes that step (or invests heavily > in a team and technologies to manage Open Source MTAs), the 3rd parties > will retain a strong position that holds many of us hostage in a sense and > does not satisfy each ESPs individual needs. > > None of the open source MTAs seem to offer anywhere near the tuning, > configurability and monitoring that's really needed to run a modern ESP. > Not surprising, large ESPs aren't a huge market and large ESPs that aren't > already committed to one or the other of the commercial product lines are > an even smaller one. > > As spam filters get more selective, especially about grey mail, the need > for high quality infrastructure (and staff!) is moving down to the smaller > end of the market too, but I doubt that's enough of an organized revenue > source to drive developing ESP-grade instrumentation for, e.g., Haraka, any > time soon. > > Cheers, > Steve > > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Gmail forwarding blowback
We at Zone.ee handle redirects to Gmail (or to any target actually) in 3 steps: 1. If the message does not get any spam points (we use Rspamd) then we forward the message through our normal redirect IP range (3 IPs that equally share the messages) 2. If the message gets spam points but not enough to discard it, then we route this message through a dedicated spam IP, the rDNS name for it even includes "spam" in it. if this IP gets blocked then we do not care too much about it. 3. If the redirected message gets a lot of spam points then we just discard it with no action (no bounce messages etc.) Regards, Andris Reinman 2017-11-08 21:46 GMT+02:00 Brandon Long via mailop <mailop@mailop.org>: > Yes, forwarding spam to us is generally a really poor idea, especially > over ipv6 [image: ]. > > The 18 is more of a source code, ie the source of the rejection, not > really a specific error code. They're not generally useful to end users. > > We've discussed before that one thing that may work best is to forward the > non-spam, and have the user use pop3 to fetch the spam. > > GSuite users can also denote a host as an inbound gateway to get around > this problem, but I was never able to get the resources to have gmail users > have the same ability. It's possible this is something we could use arc > for. > > Brandon > > > On Wed, Nov 8, 2017 at 11:41 AM Alan Hodgson <ahodg...@lists.simkin.ca> > wrote: > >> On Wed, 2017-11-08 at 12:20 -0700, Warren Volz wrote: >> >> All, >> >> One of my users has their account setup to forward mail to Gmail. >> Recently I've started to see lots of rejects that look like the following: >> >> <us...@gmail.com> (expanded from <us...@somelocaldomain.net>): host >> gmail-smtp-in.l.google.com[2607:f8b0:400e:c04::1a] said: 550-5.7.1 >> [ipv6 address 18] Our system has detected that >> 550-5.7.1 this message is likely suspicious due to the very low reputation >> of 550-5.7.1 the sending IP address. To best protect our users from spam, >> the 550-5.7.1 message has been blocked. Please visit 550 5.7.1 >> https://support.google.com/mail/answer/188131 for more information. >> p26si2014836pli.781 - gsmtp (in reply to end of DATA command) >> >> I've looked over the forwarding best practices provided by google and we >> are not modifying the envelope sender. I'd rather not start throwing away >> what our filter marks as spam since I leave that up to the user, but is >> that the only way to stop the bounces? Also, is the "18]" an artifact or >> some kind of error? >> >> Thanks for the help. >> >> >> IMO, you really can't forward mail to Gmail; they will block you if you >> forward any spam at all. >> >> Gmail accounts can be setup to pull mail in via POP-3, that's a far >> better way for them to get their mail. >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Slow botnet IMAP scans?
Hey, that's awesome, thanks for the PLAIN-CLIENTTOKEN description! I was finally able to add basic support to my own mail server (can be tested at https://ethereal.email): $ openssl s_client -crlf -connect imap.ethereal.email:993 * OK Ethereal Email IMAP Server ready A CAPABILITY * CAPABILITY IMAP4rev1 AUTH=PLAIN AUTH=PLAIN-CLIENTTOKEN ENABLE ID SASL-IR A OK CAPABILITY completed A AUTHENTICATE PLAIN-CLIENTTOKEN "AHo0YzJkbWcycWU2ZGdid2hAZXRoZXJlYWwuZW1haWwAQXJqZVVBNWsyd1lqWWo0eWJKAHRlc3Q=" A OK z4c2dmg2qe6dgbwh@ethereal.email authenticated I didn't manage to get any real mail clients to pick this authentication scheme though, all the clients I tested went with the regular "AUTHENTICATE PLAIN". Regards, Andris 2017-10-07 1:18 GMT+03:00 Brandon Long <bl...@google.com>: > We didn't release any, since we changed focus. The simple answer is, > instead of PLAIN which has a sasl format of (taking the abnf from RFC 4616): > message = [authzid] UTF8NUL authcid UTF8NUL passwd > it includes a client-token: > message = [authzid] UTF8NUL authcid UTF8NUL passwd UTF8NUL client-token > > I also wouldn't recommend using the MAC address as in Michael's proposal, > as that as privacy implications. It should either use a device specific > API to request a unique id and store it in the client, or just have the > client create one and keep it. The point is, that always a user to wipe a > device and give it to someone else, or even just wipe and replace, without > being able to track the user in other ways. > > The benefits are the same, if you've never seen a client-token before, you > need to be more careful with it, but if you have seen it before, then it's > less likely that the login attempt is a hijacking or dictionary attack. > > It can also aid in using say geohop stats. Ie, one easy way to try to > detect hijacking is to geoloc the accessing IP, and see how close it was to > the last access, or keep track of where the user is accessing from. This > has obvious issues if your users travel. If a user with a phone that > supports it goes somewhere else, chances are they'll access from the phone > first, even if their desktop client doesn't support client-token, so you > have a strong signal that they traveled somewhere else. > > All of this requires per-user login permission systems, nothing as simple > as say banning AWS or China, its' knowing whether a given user ever uses > your service from those locations. A first access from that location may > be blocked, requiring the user to go to a web page and verify the access > attempt (web access gives you a lot more signals, so doing login permission > detection there is often easier). > > Anyways, the massive service providers have been having to do this stuff > for almost a decade, it's always been a matter of time til it filters down > to the larger or medium size providers. > > Anyways, that's the reason we moved to requiring OAUTH by default, and > requiring users to jump through hoops to enable "less secure apps" (ie, > password based auth). > > Brandon > > On Fri, Oct 6, 2017 at 11:57 AM, <andris.rein...@gmail.com> wrote: > >> Is there any documentation available about PLAIN-CLIENTTOKEN? All I can >> find are SMTP transcripts about connecting to Gmail. >> >> Best regards, >> Andris Reinman >> >> On 6 Oct 2017, at 21:24, Brandon Long via mailop <mailop@mailop.org> >> wrote: >> >> I still prefer our sasl extension, PLAIN-CLIENTTOKEN instead, since you >> can then use it for imap/pop/smtp simply. >> >> Or focus on oauth... >> >> On Oct 6, 2017 7:57 AM, "Michael Peddemors" <mich...@linuxmagic.com> >> wrote: >> >> SMTP Auth Scanners are easier to stop, which is why there are more IMAP >> scanners being seen in the wild. >> >> But that is why we are pushing forward on our CID implementations.. >> >> https://datatracker.ietf.org/doc/draft-storey-smtp-client-id/ >> >> Can't really block AUTH attempts strictly by 'firewall' or IP rules, as a >> bot could be operating out of shared or dynamic space, which would mean >> that you effectively block legitimate users from accessing email. >> >> We actually have a RATS-AUTH list designed to report on IP(s) used for >> AUTH attacks, the broken bots are easier to pick up. >> >> But this isn't a 'Chinese' thing only, we see lot's of these attacks >> coming from everywhere, including Amazon AWS etc.. >> >> >> On 17-10-06 05:30 AM, Tim Bray wrote: >> >>> On 06/10/17 10:51, Otto J. Makela wrote: >>> >>>> Are you keeping an eye out for (mostly Chinese) botnets doing slow IMAP >&
Re: [mailop] Message Store on NFS in a high available setup
It’s not exactly NFS, we’re experimenting with a custom built mail server that uses clustered (sharded+replicated) MongoDB for mail store. Emails are stored in a custom MongoDB optmized format which allows for example to deduplicate and decode attachments to save storage space. In the end we want to migrate ~30TB of messages from our existing Courier based system to this new one we’re building but for now the largest test system deployed handles around 800GB, so it’s not too well tested yet to be suitable for actual large scale production, hopefully we get there in a year or so. For smaller installs it should be in a good enough state already. You can find the sources here: https://github.com/nodemailer/wildduck Best regards, Andris Reinman > On 28 Sep 2017, at 01:33, Rolf E. Sonneveld <r.e.sonnev...@sonnection.nl> > wrote: > > Hi, > > is there anyone working in a larger/'more demanding' environment, using NFS > for his/her message store, where there is a business requirement of High > Availability? If so, what commercial or open source storage solution is used? > I have a similar requirement for a project and am looking for > suggestions/options for what storage to use. > > Regards, > /rolf > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] RFC question on smtp replies...
In ZoneMTA when encountering a multiline response I remove response codes from all lines beside the first one and join resulting lines with spaces. So a bounce email sent to the return path might look like this: — Delivery to the following recipient failed permanently: andris.rein...@gmail.com <mailto:andris.rein...@gmail.com> Technical details of permanent failure: 550-5.7.1 [217.146.68.196 11] Our system has detected that this message is not RFC 5322 compliant: 'From' header is missing. To reduce the amount of spam sent to Gmail, this message has been blocked. Please visit https://support.google.com/mail/?p=RfcMessageNonCompliant <https://support.google.com/mail/?p=RfcMessageNonCompliant> and review RFC 5322 specifications for more information. a6si2605892lfk.371 - gsmtp — Andris Reinman ZoneMTA / WildDuck IMAP https://github.com/zone-eu/zone-mta <https://github.com/zone-eu/zone-mta> https://github.com/wildduck-email/wildduck <https://github.com/wildduck-email/wildduck> > On 10. juuli 2017, at 22:10, Brandon Long via mailop <mailop@mailop.org> > wrote: > > Humans also don't universally understand English, much less technical > responses. And the smtp reply codes and extended status codes don't do a > great job of mapping to what an end user can actually do about the bounce. > We currently classify the bounce into about 10 different categories based > largely on the most common "human" responses we see, and translate that into > a couple dozen languages, and its still not clear that its that much more > helpful than "your recipient didn't get the mail, sorry". > > And removing the prefix from the following lines when showing the error to > humans makes a lot of sense. Assuming the person reading it is doing so in a > fixed width font is pretty silly in this day. > > We went back and forth with Apple about how are errors should be formatted, > mostly for MSA which is often shown directly to humans in their mail client. > We ended up always including a space after any line break to ensure that it > works whether the client replaces newlines with spaces or not. Ditto for > including spaces around URLs so they're easier to extract and make clickable. > > So, yes, to the original poster, the RFCs are not clear on how to handle > unwrapping, there is no consistency. To the responders, yes the RFC doesn't > talk about unwrapping at all, but there are many cases where unwrapping makes > it much easier to read for end users. Replacing newlines with space is > probably the best you can do, or space collapse and then add a space. > > Brandon > > On Mon, Jul 10, 2017 at 12:58 AM, David Hofstee <opentext.dhofs...@gmail.com > <mailto:opentext.dhofs...@gmail.com>> wrote: > > How is https://tools.ietf.org/html/rfc5321#section-4.2 > > <https://tools.ietf.org/html/rfc5321#section-4.2> ambiguous? > - The handling for the SMTP server is NOT ambiguous. > - The handling for the human is NOT ambiguous. Just read the text. However, > most humans do not read from the wire. They use log files or other methods. > Which leads to #3. > - The handling for automated systems, forwarding the 'text' to another > system, is ambiguous. Should it include newlines and/or codes? The creation > of a DSN is one example. A logfile a second (should there be a newline in the > logfile, breaking simple parsing scripts?). An automated bounce handler is a > third example. > > I would actually say that, since the reply text can be included in a DSN, it > should be clearer. It is not just humans that this is intended for. > > Yours, > > > David > > > On 7 July 2017 at 18:44, Bill Cole <mailop-20160...@billmail.scconsult.com > <mailto:mailop-20160...@billmail.scconsult.com>> wrote: > On 7 Jul 2017, at 6:28, David Hofstee wrote: > > But it is a bit weird to say the human-readable text is for humans only. > > We appear to use conflicting definitions of the word "weird." > > Since it is transferred via SMTP, the RFC should define how to handle it. > > No. Message headers & body data are also transferred via SMTP, and the SMTP > RFC series does not define how those are handled either. This is by > intentional design. > > And it is ambiguous. I would like option 1 best. > > How is https://tools.ietf.org/html/rfc5321#section-4.2 > <https://tools.ietf.org/html/rfc5321#section-4.2> ambiguous? > > > ___ > mailop mailing list > mailop@mailop.org <mailto:mailop@mailop.org> > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > <https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop> >
Re: [mailop] SORBS help
Getting blacklisted too easily by Sorbs et al. was one of the reasons why I built a custom MTA instead of using Postfix to deliver mail. We have lots of accounts to serve and from time to time someone gets hacked and their account credentials are used to send spam. We try to catch outbound spam but it gets really tricky because dropping suspicious mail immediately breaks automated messages that usually have very poor quality in regards of formatting and tend to trigger spam points (eg. your home NAS using your SMTP credentials sends a warning message that space is running out on the hard drive). Anyhow we now use home-brewed MTA (open sourced here: https://github.com/zone-eu/zone-mta <https://github.com/zone-eu/zone-mta> ) to get past the blacklist blockings - the software is able to use multiple IP addresses for sending and if it detects that some host has blacklisted currently used sending IP then this IP is temporarily disabled for that destination, a warning is raised and the message is routed through some other IP as in most cases the message that was blocked had nothing to do with the spam that triggered blacklisting. This gives enough time to get delisted while not blocking the sending of new messages. Best regards, Andris Reinman > On 4. jaan 2017, at 15:49, Vick Khera <vi...@khera.org> wrote: > > > On Tue, Jan 3, 2017 at 8:13 PM, Bryan Vest <murli...@gmail.com > <mailto:murli...@gmail.com>> wrote: > If someone from SORBS could contact me off list or on list I don't care, > either way we need to get this block removed. > > How much trouble is it causing you? I find it doesn't cause all that much > trouble in terms of mail being blocked. SORBS does not seem interested in > solving problems, but in punishing people. > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] gmail doesn't accept (incorrectly) SRS hashes with dots inside
I would bet Gmail is behaving correctly
From RFC5321:
Mailbox = Local-part "@" ( Domain / address-literal )
Local-part = Dot-string / Quoted-string
Dot-string = Atom *("." Atom)
Atom= 1*atext
From RFC5322 (as atext is not defined in RFC5321):
atext = ALPHA / DIGIT /; Printable US-ASCII
"!" / "#" /; characters not including
"$" / "%" /; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
"~"
As you can see then you can use dots to separate atoms which in turn are not
allowed to include dots. There must be at least a single atom character after
dot.
Best regards,
Andris Reinman
> On 20. dets 2016, at 16:58, Arkadiusz Miśkiewicz <ar...@maven.pl> wrote:
>
>
> libsrs_alt library (used by exim to generate SRS addresses for example;
> copy on https://github.com/LynxChaus/libsrs-alt) has an option:
>
> "
> --with-base64compat
>
> This option alters the behaviour of the base64 encoder built
> in to libsrs_alt to use the non-standard characters '_' and
> '.' instead of '+' and '/'. This move vastly improves the
> compatibility of SRS with MTAs. The option comes highly
> recommended.
> "
>
> which producess addresses like this:
>
> $ srs --alias=example.com --secret=1386 --forward t...@test.pl
> SRS0=GW..5e=YD=test.pl=t...@example.com
>
> (note two dots instead of two slashes; without base64compat option that would
> be
> SRS0=GW//5e=YD=test.pl=t...@example.com)
>
> but google refuses these claiming that it violates RFC-5321
> (which IMO isn't true as this is valid RFC5321 address)
>
> $ telnet aspmx.l.google.com 25
> Trying 2a00:1450:400c:c0c::1a.25...
> Connected to wr-in-x1a.1e100.net.
> Escape character is '^]'.
> 220 mx.google.com ESMTP ue16si22842569wjb.138 - gsmtp
> ehlo test
> 250-mx.google.com at your service, [2001:67c:267c:1:3::2]
> 250-SIZE 157286400
> 250-8BITMIME
> 250-STARTTLS
> 250-ENHANCEDSTATUSCODES
> 250-PIPELINING
> 250-CHUNKING
> 250 SMTPUTF8
> mail from:
