Re: Bounces without Bodies
Hello backscatterers (:-), jab...@serversave.us (Jason Barbier), 2014.03.03 (Mon) 18:47 (CET): So reading this also this type of spam bounce has a common name, its called backscattering (https://en.wikipedia.org/wiki/Backscatter_%28email%29). as I read this (thanks for the link) there is no real solution to the problem. Under Reducing the problem it says: Checking bounce recipients Mail servers sending email bounce messages can use a range of measures to judge whether a return address has been forged. Which range of measures is this referring to?! What I want to stress is that this discussion is about working around a problem some mail providers pose. Where is this going to end? I have a nationwide mail provider here in austria that throttles inbound mail after some number of messages. Could we work around this as well, please? BTW, the proposed workaround of bouncing without content is not suggested in the above link. Bye, Marcus There is actually a blacklist for this and quite a few companies use it, as well as greylisting software will check for it. We for sure want to make sure that we are able to turn off backscatter and have it off by default. Honestly users should beable to turn this on and off based on the direction of the mail. internally it is useful to have it spit back the message, headers, and the raw error that the MTA returned. Externally we should just spit back at most headers but honestly what is internal and external needs to be set by the user since there is no good way to determine this on its own and the MTA honestly should handle this all as part of doing the bounce. It makes no sense to make a filter or have a second function handle it since we already have a function to handle bounces. On 03/03/14 09:16, Jason A. Donenfeld wrote: Hi folks, Spammers have an easy trick against OpenSMTPD: they send a message that bounces for some reason (say, it's forwarded to another MTA that rejects it on on the basis of it being spam), and the bounce message then contains the original spam message. Egress spam filters on various hosting networks -- such as OVH -- then will spot that bounce message as spam, and block the IP on the basis of it being the spammer. The solution is obvious, and other MTAs have incorporated this: for networks with egress filters like this, opensmtpd should have a configuration option to only send headers, not bodies, in bounce messages. This has the additional benefit too of lowering bandwidth usage. For the same reason that mask-source was added as a config flag, not sending bodies in bounce messages should also be added as a config flag: opensmtpd generates this data in a very unstructured way (random text in a message body that's then queued like other messages), and then ships it off. It would be wasteful implement this as a filter using the filter api, which would parse an unstructured format, and remove bits of data based on a buggy heuristic, when opensmtpd is the one adding it in the first place. The obvious solution is to simply add a flag so that this information doesn't get added in the first place. Thus, I propose a configuration flag for not adding bodies to bounce messages. Thanks Jason -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org !DSPAM:5314c03b8723225549481! -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: examples to setup mlmmj and dovecot?
Am 04.03.2014 09:59, schrieb Marcus MERIGHI:
beno...@apache.org (benoitc), 2014.03.04 (Tue) 09:41 (CET):
I am looking for some examples or guidance on how to configure =
opensmtpd and dovecot with mlmmj. Possibly using virtual hosting ( i =
have different domain to host with the users maintained in simple =
files). Is there any howto somewhere about it?
this is misc@opensmtpd.org so there is only the info how to get from
opensmtpd to mlmmj/dovecot.
opensmtpd - mlmmj:
1) Inbound mail to mailinglist (ML) gets redirected to a user via
aliases:
email username
foobar-info: foobar-info
2) That user has a .forward of following content:
|/usr/local/bin/mlmmj-recieve -L \
/path/to/home/directory/of/username
3) Do not forget the cronjob for username:
9 */2 * * * /usr/local/bin/mlmmj-maintd -F -L \
/path/to/home/directory/of/username
opensmtpd - dovecot:
opensmtpd can deliver to maildirs where dovecot picks it up
It's better to either deliver via LMTP to dovecot or via dovecot's
delivery binary because this will keep the indexes intact that dovecot
needs to work efficiently.
in smtpd.conf:
accept ... deliver to lmtp /var/run/dovecot/lmtp
in dovecot.conf:
protocols = lmtp imap
service lmtp {
unix_listener lmtp {
# user = _smtpd
# group = _smtpd
# mode = 0600
mode 0666
}
}
Note that I tried to explicitly set the UNIX domain permissions for
/var/run/dovecot/lmtp to _smtpd:_smtpd, but this doesn't work as it
shows smtpd: cound't establish connection: Permission denied. I am
not sure which user/group this should be!
Regards,
Michael
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Bounces without Bodies
Hi Marcus, At 00:44 04-03-2014, Marcus MERIGHI wrote: as I read this (thanks for the link) there is no real solution to the problem. Under Reducing the problem it says: Checking bounce recipients Mail servers sending email bounce messages can use a range of measures to judge whether a return address has been forged. Which range of measures is this referring to?! It is possible to mitigate the backscatter problem. There are various heuristics used. RFC 5321 discusses about the unwanted messages problem. Instead of trying to fix the backscatter problem it would be easier to find out what configuration options could be useful. Regards, -sm -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Bounces without Bodies
On Tue, Mar 04, 2014 at 12:25:58AM +0100, Jason A. Donenfeld wrote: [...] OpenSMTPD will generate bounces in lots of contexts. It doesn't make sense, for example, to add the flag to accept, since if you accept mail for @poolp.org, but ploop.org also points to the same IP, and someone sends a message to whate...@ploop.org, opensmtpd will generate a bounce. This bounce doesn't exist in the context of that 'accept' line, so it wouldn't really make sense to have the control there. OTOH, all messages necessarily go through a listen line, and exist in that context, so I think a flag would make more sense there. That's not an issue really, wether you handle this at the listen level or at the rule level, we know how to cope with contexts easily as this tricky problem has been solved already for cross rule aliases resolve. Let's ignore this and focus on what we want, context aside. The main reason for chosing one over the other is the granularity: if at the listen-level, we decide that it is not possible to have the mechanism apply to a specific domain, it applies to all domains that will be match on that interface. listen on lo0 bounce all-content listen on fxp0 bounce headers-only accept from any for domain poolp.org deliver to maildir accept from any for domain opensmtpd.org deliver to maildir in this case, mail to @opensmtpd.org will have a different bounce strategy depending on the interface used to connect, but once connected to a specific interface, the bounce strategy will be the same for all domains. if at the rule-level, we decide that we can apply this to a specific domain but not another, so more granularity ... listen on lo0 listen on fxp0 accept from any for domain poolp.org deliver to maildir bounce all-content accept from any for domain opensmtpd.org deliver to maildir bounce headers-only in this case, it is when an envelope matches a rule that we decide which strategy we want to use. two different domains accessed from the same interface may have different policies. I favor the second one because using tags we can achieve hybrid models: listen on lo0 tag LOCAL listen on fxp0 tag EXTERNAL accept tagged LOCAL from any for domain poolp.org deliver to maildir bounce all-content accept tagged EXTERNAL from any for domain poolp.org deliver to maildir bounce headers-only where a single domain can have different policies depending on the interface it accepted mail from. listen on lo ... [absence of no-bounce-bodies] listen on eth0 ... no-bounce-bodies or, to be 'safe' by default (which is arguably better): listen on lo ... bounce-bodies listen on eth ... [absence of bounce-bodies] Put this way, it would mean that when a local user queues up a message and sends it, and that message bounces, that local user receives the full body in his bounce. And contrarily, when an external host connects to send a message that bounces, the body is not sent, to prevent against this backscatter problem. as explained above, I think it can be achieved nicely at a rule level Or, maybe that's much too complex, and breaks with the pattern introduced by bounce-warn, which is a global config option. This would probably be much easier to grok. This would look like: listen on eth0... listen on lo... accept for ... bounce-warn 3m bounce-parts headers body or bounce-parts headers or bounce-parts body Even better, the two bounce options could be unified into one line with simpler grammer: bounce warn-wait 3d with-body with-headers Or something similar. actually what we could do is some kind of mix: bounce-warn bounce-parts as knobs for global default overrides, which can be overriden at the rule level, like we do for expire -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
postgres and ldap backends
Hi, We have just released a minor stable version and hopefully we should not see another minor release before OpenSMTPD 5.5.0 comes out several weeks from now. In the meantime, I'd like to stabilize table_ldap and table_postgres, so we could *maybe* stop shipping them as experimental with our next big release. If people willing to use ldap or postgres could get in touch with me, it would be nice ;-) -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Turn off DSN
On Wed, Mar 05, 2014 at 05:31:03AM +0100, Jason A. Donenfeld wrote: Apparently delivery status notification allows anybody to determine where a piece of mail is relayed, by requesting a success notification. OpenSMTPD happily creates a nice verbose message containing this information. Except I don't want to let the world know where the mail is relayed. Any way to turn this off? -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org Is DSN requested by your MUA? If not smtpd shouldn't be generating a DSN. If smtpd is used to relay a mail and DSN parameters were specified then it's bound to generate the DSN. I am confused whether you want to turn off DSN (which is generated only on request) or you want to suppress some of the content of the DSN. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
