IDN support in SMTP?!
Hello, I run one of the famous new IDN domains - those domains that contains evil utf-8 characters, like german umlaute or japanese chars. IDN is around for some years now and more of less supported in all browsers at least for HTTP. I was wondering if someone knows the status of IDN support for SMTP? Are there plans to add this into common smtpd's like sendmail, qmail, postfix, exim, etc? Or is this already implemented and I am just not aware of it? Nevertheless, I wrote a IDN plug-in for qpsmtpd: http://wiki.qpsmtpd.org/plugins:other:idn It's not heavily been tested yet and marked as alpha release. Please feel free to play around with it and contribute your code/patches. Here is what it does: This plugin checks if the domain part of a sender or recipient contains utf-8 chars and converts it into ACE using Puyncode. See http://en.wikipedia.org/wiki/Internationalized_domain_name This is an ALPHA TESTVERSION! It has not intensively been tested yet. Please feel free to play around with it. To install the module, put a copy of this code into a file called "plugins/IDN" and add a line that says "IDN" into your "config/plugins" file - somewhere at the top of the file. All outgoing emails will be checked if the recipient domain-part contains non plain 7bit ASCII charcters and will be converted into ACE using punycode. The Perl module IDNA::Punycode is required to run this plug-in. Get it via "perl -MCPAN -e shell".
Re: IDN support in SMTP?!
> What are the two patches that need to be appied? (I don't see them in
> the plugins documentation).
I've updated the documentation in the Wiki:
Right now, this plug-in always returns DECLINED because recipient-
>host and sender->host are always empty
when a email address with IDN arrives into qpsmtpd. A simple patch is
needed for Qpsmtpd::Address method canonify(), like
replacing this line:
my $subdomain = '(?:[a-zA-Z0-9](?:[-a-zA-Z0-9]*[a-zA-Z0-9])?)';
with this line:
my $subdomain = '([^\.]{2,})?';
Also, the method Qpsmtpd::Address method host() need to be patched in
order to allow overwriting of the host:
sub host {
my ($self, $host) = @_;
if ($host) { $self->{_host} = $host; } else { return $self-
>{_host}; }
}
To apply this two modifications, simply edit lib/Qpsmtpd/Address.pm
and search for the lines, comment them out and replace them with the
new ones.
Regards, Marc
Re: IDN support in SMTP?!
On Dec 4, 4:44 pm, [EMAIL PROTECTED] (Peter J. Holzer) wrote:
> As far as I can tell, this is not an issue for SMTP. The MUA is supposed
> to convert the domain name into ACE format (just like the browser
> is supposed to convert the domain name before sending an HTTP request).
> So MTAs always only deal with "ordinary" domain names and never need to
> know that the domain is "really" an IDN.
Ok, understand. I read RFC 3490 which says that IDN should be
implemented on client side; which is also my opinion. On the over
hand, IDN support has not been build in into many mail clients for
years now. The only mail app that supports IDN that I know is Apple
Mail in the newest version that comes with OS X 10.5. That why I
thought that its time to do something and do it the most simple and
flexible way - like the philosophy of qpsmtpd - and implement it into
the server side. This way almost any mail client is supported from one
second to another.
> This may be useful in an MSA for MUAs which don't deal correctly with
> IDNs. However, such a client probably has other problems with IDNs, too,
> so I'm not sure if this enough enable them to use IDNs. Which MUAs did
> you test this with?
I tested it with swaks.pl (http://www.jetmore.org/john/code/#swaks)
and it sends the "mail from" and "rcpt to" unmodified over the line. I
improved my IDN plug-in a bit and it works quite well right now in my
environment. Nevertheless, two patches need to be applied to lib/
Qpsmtpd/Address.pm in order to handle subdomain parts that contain non
7bit ASCII and to allow overwriting of $self->{_host}. Those patches
will never be part of the official qpsmtpd for sure, but for anyone
who wants IDN support it's easy to do it.
Regards, Marc
Announcing a new plug-in: autowhitelist_captcha
autowhitelist_captcha http://wiki.qpsmtpd.org/plugins:spam:autowhitelist_captcha This plug-in is a whitelist which automatically maintains itself based on well known and widely used Captcha authentication where a user must identify characters within an image. You can define one ore more mail- domains or single email-addresses that will be protected by this auto- whitelist plugin. If the sender of an email is not whitelisted, he will get an automatic reply-mail which includes a Captcha image which he can solve in his answer-mail. If the Captcha-string is correct, he will be automatically added to the whitelist, otherwise he gets a new Captcha via email until he succeed or failed for 5 times (then he will be blacklisted). Use this plug-in to efficiently protect your emails against Spam, because Spam-senders will never receive the Captcha mail (because they use faked email addresses) or if they do, they will never answer it. Your business contacts, friends and family will solve the Captcha because it's easy and they really want to get in contact with you. If you add all of your friends emails to the whitelist up-front, they will never need to solve the Captcha anyway. I recommend to download the plug-in from one of the CPAN mirrors: http://search.cpan.org/~mpelzer/ The archive contains not only the plug-in, but also the config-file and some nice MIME email-templates in german and english! It will take some time until the archive will appear on the mirrors.
Re: Announcing a new plug-in: autowhitelist_captcha
On Dec 7, 3:58 pm, [EMAIL PROTECTED] (M. Allan Noah) wrote: > does this not turn your host into a backscatter joe-job spam zombie? > > allan of course you should run all common qpsmtpd anti-spam plug-ins up- front, like: no_dialup, geo_blacklist_whitelist, check_earlytalker, and so on. Captcha response mails are only being send to senders whose mails have passed those plug-ins. I'm happy to receive new ideas how to improve this plug-in and to make it more fail-safe. Marc
Re: Announcing a new plug-in: autowhitelist_captcha
> we mis-communicate i believe. i suggested that you include the url in > the smtp error message you send when you reject the initial email. > then you do not generate any backscatter spam. however, it does > require that the origin MTA send the text of the message back to the > sender. my basic rule is this- never accept mail you do not intend to > deliver. ok, understand - good idea! Marc
Re: Announcing a new plug-in: autowhitelist_captcha
> This plugin might be able to reject unwanted mail during the original > smtp transaction if it sent a URL back at that time. The origin MTA > would have to pass that on to the user, but then you would not even > need the captcha at that point. Visiting the page could be enough to > enable the mail. This would also be much more friendly for my visually > impaired friends. Thats the plan. I will work on a autowhitelist_click in the next days which will have a URL inside the auto-reponse email which whitelists the sender with a click. A webserver with CGI is needed on the mailserver then; thats not always the case. Marc
HashCash reloaded
Hi list, I've written a HashCash plug-in that uses Digest::HashCash and is a bit more cleaned-up than the existing one. http://wiki.qpsmtpd.org/plugins:spam:hashcash Has anyone an idea how a plug-in can find out if the mail it currently handles is a incoming (local delivery) or outgoing (routed to the world) mail? Right now, I solved this by setting a connection-note in another plug-in that check if the remote IP is a relay client. But I think it's a good idea to have a more generic solution for this within another plugin. Regards, Marc
Re: HashCash reloaded
On Dec 10, 3:15 pm, [EMAIL PROTECTED] (Johan Almqvist) wrote: > As you can see from my plugin, I based the decision on whether the mail > is sent by an authenticated user... Hi Johan, I cant find any plug-in or library in lib/Qpsmtpd that sets this "authuser" note. It seems not to be set within a standard plug-in that comes with qpsmtpd. Maybe I'm missing something ... Regards, Marc
Re: HashCash reloaded
On 10 Dez., 17:42, [EMAIL PROTECTED] (Peter J. Holzer) wrote:
> Why set an additional connection-note and not use relay_client()
> directly? I think that's what it is for.
>
> (not really "incoming" vs. "outgoing" but "authorized to send mail to
> anybody" vs. "not authorized to send mail to anybody")
Great! I've changed the line to
if ($self->qp->connection->relay_client || $self->qp->connection-
>notes('is_outgoing_mail')) {
So both is supported. Not anyone uses SMTP auth (like me), but instead
dynamic or static
lists with IPs of allowed relay clients/networks.
Marc
Re: Announcing a new plug-in: autowhitelist_captcha
> It would be perfect to combine this with some of the features of TMDA > (http://tmda.sourceforge.net/) like dated and keyword addresses. Hi Werner, thanks for pointing me to this. I never heard about it - seems to be pretty interesting though. I'll think about adding the temporary address stuff - should not be to hard to implement. Maybe I put it into a separate plug-in for those who do not wish to use the Captcha stuff... Marc
