smtpd.comf: '... reject "message"' fails
My reading of smtpd.conf says that any reject action should be able to take a message parameter. Yet the following line is rejected with a syntax error message: match mail-from rdns regex "\.t-online\.de$" reject "550 5.7.1 you don't accept our mail, so we don't accept yours." Yet the same line without the string after the reject keyword works. I spent some time digging in the grammar, but yacc just gives me migraines. Should this in fact work? Or is the manpage wrong. --lyndon
Re: smtpd.comf: '... reject "message"' fails
On 2022-10-20 21:38 -07, "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: > My reading of smtpd.conf says that any reject action should be able > to take a message parameter. Yet the following line is rejected > with a syntax error message: > > match mail-from rdns regex "\.t-online\.de$" reject "550 5.7.1 you don't > accept our mail, so we don't accept yours." > > Yet the same line without the string after the reject keyword works. > > I spent some time digging in the grammar, but yacc just gives > me migraines. Should this in fact work? Or is the manpage > wrong. There are two kinds of matches, you are using this: match options reject Reject the incoming message during the SMTP dialogue. The same options are supported as for the match action directive. You need this one: filter filter-name phase phase-name match conditions decision Register a filter filter-name. A decision about what to do with the mail is taken at phase phase-name when matching conditions. Phases, matching conditions, and decisions are described in MAIL FILTERING, below. i.e. filter dtag phase mail-from match rdns regex "\.t-online\.de$" reject "550 5.7.1 you don't accept our mail, so we don't accept yours." listen on egress filter dtag No, I don't know why things are the way they are. > > --lyndon > -- I'm not entirely sure you are real.
Re: smtpd.comf: '... reject "message"' fails
On 2022-10-21, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > My reading of smtpd.conf says that any reject action should be able > to take a message parameter. Yet the following line is rejected > with a syntax error message: > > match mail-from rdns regex "\.t-online\.de$" reject "550 5.7.1 you don't > accept our mail, so we don't accept yours." You didn't want to publish an impressum on a website associated with your mail server's domain then? ;) (For those that don't know, it seems that T-Online.de block incoming email from most IPs by default and anyone wanting to send them mail has to explicitly contact them to ask permissions, and they make you jump through hoops before they'll grant that - see recent posts on the mailop list for more. It is quite astonishing.)
Re: smtpd.comf: '... reject "message"' fails
On Fri, 21 Oct 2022 15:58:54 -, Stuart Henderson wrote: > (For those that don't know, it seems that T-Online.de block incoming > email from most IPs by default and anyone wanting to send them mail > has to explicitly contact them to ask permissions, and they make you > jump through hoops before they'll grant that - see recent posts on > the mailop list for more. It is quite astonishing.) At least they provide a way to contact them, unlike Google which just rejects my mail with no way to contact a human being. - todd
Re: smtpd.comf: '... reject "message"' fails
Florian Obser writes: > > You need this one: > > filter filter-name phase phase-name match conditions decision > Register a filter filter-name. A decision about what to do with > the mail is taken at phase phase-name when matching conditions. > Phases, matching conditions, and decisions are described in MAIL > FILTERING, below. > > i.e. > > filter dtag phase mail-from match rdns regex "\.t-online\.de$" reject "550 > 5.7.1 you don't accept our mail, so we don't accept yours." > listen on egress filter dtag Thanks Florian, that clears up a lot for me. So my reading of the grammar was right -- the form of reject I was using doesn't accept a following string. I got compleetely lost when I tried to parse the other reject forms in the grammar, and missed the other syntax you desribed above. Now that I have that clear, it seems pretty straight forward to modify the grammar to allow a string in the other reject cases. I think I'll give that a go over the weekend. Thanks for the help! --lyndon